Чек-лист на позицию QA [Много букв и спойлеров]

Базовые вопросы

Тестирование и его цели

Тестирование - это проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. В более широком смысле, тестирование - это одна из техник контроля качества, включающая в себя активности по планированию, тест дизайну, выполнению тестирования и анализу полученных результатов.
Если перейти к целям тестирования, их тоже выделяют 4:

1. Убедиться, что ПО соответствует требованиям (т.е. те, которые выявил заказчик)
2. Убедиться, или хотя бы повысить вероятность того, что ПО будет работать хорошо в любых условиях (будь то пропадание сети или, например, если пользователь прокликает какую-нибудь кнопку 10 раз)
3. Предоставить актуальную информацию о качестве продукте на текущий момент
4. Поиск дефектов

В чем разница между QA, QC и тестированием

1. QA — это процесс управления, направленный на предотвращение дефектов и улучшение процессов разработки продукта для обеспечения высокого уровня качества. Цель QA — не допустить появления дефектов на всех этапах разработки.

• Задачи QA: Разработка стандартов, процедур, и методологий для того, чтобы продукт соответствовал требованиям. QA включает такие методы, как аудит процессов, создание документации, а также контроль за выполнением стандартов.
• Пример: Внедрение agile-подходов или автоматизированного тестирования, чтобы снизить количество ошибок на стадии разработки.

1. QC — это процесс проверки, направленный на выявление дефектов в готовом продукте. QC занимается проверкой того, что продукт соответствует стандартам качества и требованиям.

• Задачи QC: Обнаружение дефектов через тестирование и их исправление.
• Пример: Проверка соответствия работы ПО его функциональным и нефункциональным требованиям, оценка производительности или безопасности приложения.

1. Тестирование — это часть QC, которая включает в себя практическую проверку программного обеспечения для выявления багов, дефектов или ошибок.

• Задачи тестирования: Проверка всех функциональных и нефункциональных аспектов ПО.
• Пример: Ручное тестирование интерфейса пользователя или автоматизированное тестирование API.

Отличия:

• QA фокусируется на процессах создания продукта и предотвращении дефектов на ранних этапах.
• QC концентрируется на проверке готового продукта и исправлении найденных проблем.
• Тестирование — это инструмент QC для выявления дефектов в продукте.

Таким образом, QA работает с процессами, QC проверяет результаты, а тестирование — это один из методов контроля качества продукта.

Зачем тестировать ПО

Во-первых, тестирование помогает выявить ошибки в приложении еще до его выхода в продакшен. Это помогает улучшить качество и надежность приложения, снизить риски при использовании, а также увеличить удовлетворенность конечных пользователей.
Во-вторых, тестирование помогает ускорить процесс разработки, т.к. обнаружение ошибок на ранних этапах позволяет снизить затраты на их исправление в будущем.
И в-третьих: тестирование помогает обнаружить варианты использования приложения и новые требования, которые не были предусмотрены при выявлении требований. Это может сильно улучшить качество ПО, так как именно эти требования могут быть критичными для конечного пользователя
В итоге, тестирование помогает создать более качественный и надежный продукт, который будет соответствовать ожиданиям пользователей и заказчиков, а также приносит выгоду разработчикам и всем, кто связан с использованием этого ПО.

Жизненный цикл тестирования или этапы тестирования

1. Анализ продукта: На этом этапе осуществляется изучение и понимание основных характеристик и функционала программного продукта.
2. Работа с требованиями: Здесь проводится детальный анализ требований к продукту для определения, какие аспекты будут подвергнуты тестированию.
3. Разработка стратегии тестирования: На этом этапе разрабатывается план действий для проведения тестирования, включая выбор методов и ресурсов.
4. Создание тестовой документации: Здесь подготавливаются все необходимые *********, такие как тест-кейсы, сценарии и планы тестирования.
5. Тестирование прототипа: Если применяется прототипирование, этот этап включает в себя проверку и оценку прототипа продукта.
6. Основное тестирование: Этот этап включает в себя выполнение тест-кейсов и сценариев для обнаружения дефектов и проверки функциональности.
7. Стабилизация: Здесь осуществляется устранение выявленных дефектов и подготовка продукта к финальной версии.
8. Эксплуатация: После успешного завершения тестирования продукт выпускается в эксплуатацию, где он доступен для конечных пользователей.

После выпуска продукта в продакшен тестирование не заканчивается, а продолжается в виде поддержки и обслуживания. В этот период тестирование включает в себя:

1. Контроль качества продукта: после выпуска продукта в продакшен необходимо отслеживать его работу и контролировать качество. Это помогает быстро реагировать на возможные проблемы и улучшать качество продукта.
2. Исправление ошибок и дефектов: если после выпуска продукта в продакшен обнаружатся ошибки или дефекты, необходимо их исправить. В этом случае проводится дополнительное тестирование, чтобы убедиться в том, что исправления были сделаны корректно и не привели к новым проблемам.
3. Обновление и модификация продукта: после выпуска программного продукта могут возникнуть новые требования или изменения, которые потребуют обновления или модификации ПО. Эти изменения также должны быть протестированы, чтобы убедиться в том, что они работают корректно и не нарушают функциональность программы.
4. Тестирование совместимости: после выпуска ПО могут появиться новые платформы, операционные системы, браузеры и другие приложения, которые могут повлиять на работу продукта. Поэтому необходимо периодически проводить тестирование совместимости, чтобы убедиться в том, что продукт работает корректно в различных средах.

Жизненный цикл разработки ПО

1. Идея
2. Разработка и сбор требований
3. Дизайн
4. Программирование
5. Тестирование
6. Ввод в эксплуатацию
7. Поддержка
8. Вывод из эксплуатации

Пирамида тестирования

1. Модульное тестирование: тестируется минимально-атомарный модуль программы, чаще всего это одна функция или метод. Таких тестов должно быть больше всего.
2. Интеграционное тестирование: несколько модулей программы тестируются вместе.
3. Системное тестирование: вся программа тестируется полностью.
4. Приемочное тестирование: проверка, выполняемая перед передачей программного обеспечения заказчику для подтверждения того, что система работает в соответствии с требованиями и спецификациями.

Принципы тестирования

1. Тестирование демонстрирует наличие дефектов. Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.
2. Исчерпывающее тестирование невозможно. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо (за исключением тривиальных случаев).
3. Раннее тестирование. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения.
4. Скопление дефектов. Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском и отвечает за большинство эксплуатационных отказов.
5. Парадокс пестицида. Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.
6. Тестирование зависит от контекста. Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
7. Заблуждение об отсутствии ошибок. Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Виды тестирования

1. Тестирование демонстрирует наличие дефектов. Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.
2. Исчерпывающее тестирование невозможно. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо (за исключением тривиальных случаев).
3. Раннее тестирование. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения.
4. Скопление дефектов. Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском и отвечает за большинство эксплуатационных отказов.
5. Парадокс пестицида. Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.
6. Тестирование зависит от контекста. Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
7. Заблуждение об отсутствии ошибок. Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Виды тестирования

Вообще, говоря о видах тестирования есть несколько классификаций.

1. Функциональные или нефункциональные виды требований
2. Связанные с изменениями
3. По доступу к системе

В функциональное тестирование входят:

1. Само по себе функциональное тестирование. Т.е. проверка соответствия функциональным требованиям

В нефункциональное тестирование входят:

1. Все виды тестирования производительности. То есть нагрузочное тестирование, объемное, стрессовое и тестирование стабильности и надежности
2. Тестирование удобства использования, т.е. юзабили тестирование
3. Тестирование на отказ и восстановление
4. Конфигурационное тестирование. Т.е. тестирование на разных конфигурациях устройств

В тестирование, связанное с изменениями входят:

1. Ретестинг. Его проводят, когда нужно проверить исправление какого-либо бага
2. Регрессионное тестирование. Его проводят, например, когда в систему добавили какой-нибудь новый модуль или залили изменения, и нужно проверить, что изменения не сломали другой функционал, который ранее работал исправно
3. Санити тестирование. Это когда мы проверяем работоспособность какого-то конкретного модуля после изменений
4. Смок тестирование. Это такой набор тестов, который позволяет убедиться в том, что основные функции приложения работают и мы можем продолжать делать какое-то другое тестирование, например, регресс

В тестирование, связанное с доступом к системе, входят:

1. Черный ящик. Это когда ничего не известно о том, как система устроена внутри и мы просто тестируем её как пользователь
2. Серый ящик. Это когда частично знаем, как устроена система. Например, можем посмотреть в ****
3. Белый ящик. Это когда полностью известно, как устроена система. Например, можем посмотреть код и в БД.

Помимо всего этого еще есть динамическое и статическое тестирование.
В статическое тестирование входит анализ кода, код ревью - этим обычно занимаются разработчики. Еще есть анализ документации - это уже задача тестировщика, как правило. Но в целом этим может заняться кто угодно - разработчик, менеджер или продукт овнер. А динамическое - это уже куча разных видов тестирования, при которых нужно запускать код, то есть приложение.

Регрессионное тестирование

Регрессионное тестирование — это тип тестирования, направленный на проверку того, что недавно внесённые изменения в код не вызвали появления новых дефектов в уже проверенной и работающей функциональности. Оно необходимо после исправлений багов, добавления нового функционала или рефакторинга, чтобы убедиться, что изменения не привели к сбоям или ошибкам в других частях системы. Основная цель — обеспечить стабильность системы после внедрения обновлений

Sanity тестирование

Sanity тестирование — это тип поверхностного тестирования, который проводится для проверки, работают ли основные функции приложения после внесения небольших изменений, таких как исправление бага или небольшое улучшение функциональности. Sanity тестирование фокусируется на определенных участках системы, затронутых изменениями, и помогает быстро убедиться, что приложение работает корректно перед проведением более детальных тестов, таких как регрессионное тестирование

Чем отличается Sanity тестирование от регриссионного

Sanity тестирование и регрессионное тестирование различаются по своей цели и объему. Sanity тестирование — это когда мы быстро проверяем, что конкретные изменения в коде не сломали основную функциональность приложения. То есть это что-то вроде поверхностной проверки, чтобы убедиться, что всё в порядке после мелких правок.
А вот регрессионное тестирование — это гораздо более глубокая проверка, которая охватывает всё приложение. Оно нужно для того, чтобы убедиться, что никакие изменения не нарушили другие, уже работающие части системы.
Так что если коротко, sanity тестирование — это про быструю проверку чего-то конкретного, а регрессионное — про уверенность в том, что всё приложение работает стабильно после обновлений.

Смок тестирование

Смок тестирование - это короткий цикл тестов, подтверждающий ( или отрицающий) факт того, что приложение выполняет свои основные функции и готово к более обширному тестированию (например, регресс). Проверки практически всегда одинаковы и редко претерпевают изменения. Поэтому удобнее их автоматизировать.

Исследовательское тестирование

Исследовательское тестирование - это метод тестирования, который основывается на знаниях и опыте тестировщика. Это тестирование осуществляется без подробного планирования тестовых сценариев и тест-кейсов.
В исследовательском тестировании, тестировщик работает в динамической среде, где тестирование происходит на лету. Тестировщик изучает продукт и его функциональность, одновременно проводя тестирование и делая выводы о его работоспособности, удобстве использования и соответствии требованиям.
Исследовательское тестирование может помочь выявить проблемы и дефекты, которые могут быть пропущены в более формальных методах тестирования. Этот метод также может быть эффективным в случаях, когда у продукта нет документации, или она недостаточна для проведения тестирования.

Тестирование производительности

Тестирование производительности - это метод тестирования, который используется для измерения производительности приложения или системы в различных условиях нагрузки. Целью является определение, как быстро и эффективно приложение работает при больших объемах данных, высокой нагрузке и в различных условиях использования.
Виды тестирования производительности:

1. Нагрузочное тестирование - это метод тестирования, который проверяет, как приложение работает при увеличении нагрузки на него, например, при использовании большого количества пользователей одновременно. В процессе Load Testing, тестировщик создает сценарии, которые имитируют поведение реальных пользователей и запускает тесты, чтобы определить, как быстро приложение может обрабатывать запросы в условиях высокой нагрузки.
2. Стресс тестирование - это метод тестирования, который проверяет, как приложение работает при экстремальных условиях нагрузки, таких как увеличение объема данных, увеличение количества пользователей или уменьшение ресурсов, доступных для приложения. Stress Testing позволяет выявить, как приложение справляется с неожиданными и экстремальными условиями.
3. Продолжительное тестирование/тестирование выносливости - это метод тестирования, который проверяет, как приложение работает при длительном использовании. Endurance Testing может помочь определить, есть ли проблемы с памятью или утечками ресурсов, которые могут привести к снижению производительности приложения.
4. Пиковое тестирование - это метод тестирования, который проверяет, как приложение работает при резком увеличении нагрузки на него. В процессе Spike Testing, тестировщик создает сценарии, которые имитируют резкий всплеск активности пользователей и запускает тесты, чтобы определить, как быстро приложение может адаптироваться к резкому увеличению нагрузки.

Техники тест-дизайна

1. Эквивалентное разбиение. Идея состоит в том, чтобы разделить все возможные входные данные на классы таким образом, чтобы все значения внутри одного класса считались эквивалентными, т.е. равнозначными.
2. Анализ граничных значений. Для тестирования граничного значения нужно взять граничное значение и значение рядом с ней. Например, если мы используем трехзначный анализ границ, и если граница - это 10, то мы берем 9, 10 и 11
3. Попарное тестирование. Это методика тестирования, при которой все возможные комбинации пар входных параметров тестируются хотя бы один раз. Вместо того чтобы тестировать каждую возможную комбинацию значений параметров, попарное тестирование ищет комбинации, которые покрывают все возможные пары значений параметров.
4. Таблица принятия решений — это таблица, в которой перечислены все возможные комбинации условий и соответствующие им действия или результаты. Она помогает визуализировать и организовать сложные логические условия и их последствия.
5. Предугадывание ошибок. Это когда, например, мы выбираем для тестирования те зоны, где, судя по опыту, наверняка должны быть ошибки

Дефект и жизненный цикл бага

Дефект - несоответствие фактического результата ожидаемому. Дефекты бывают трех типов:

1. Баг или же дефект: это какая-то ошибка, которая вызывает поведение, которое не соответствует требованиям
2. Ошибка пользователя. Т.е. это какое-то некорректное использование приложения. Например, когда пользователь кликает на какую-либо кнопку 15 раз. По факту, это не было описано в требованиях, но при этом она все еще является ошибкой
3. Отказ или краш (или же failure). Это уже результат какого-то бага . Это когда приложение или его часть полностью перестает работать

Обычно дефекты, или же баги, описываются в виде баг-репорта.

Валидация и верификация

Верификация - это процесс проверки соответствия ПО заданным требованиям. То есть, это проверка того, что система была правильно разработана и реализована в соответствии с требованиями.
Валидация, с другой стороны, - это процесс проверки того, что продукт или система соответствует потребностям и ожиданиям пользователей и решает их задачи. То есть, это проверка того, что система правильно решает поставленные задачи и соответствует бизнес-целям заказчика.
Таким образом, главная разница между верификацией и валидацией заключается в целях проверки. Верификация проверяет соответствие системы требованиям, в то время как валидация проверяет соответствие системы бизнес-целям и потребностям пользователей.

Баг репорт

Баг-репорт - это документ, который содержит в себе всю информацию, которая необходима для того, чтобы этот баг воспроизвести. баг-репорт обычно состоит из таких полей, как:

1. Саммари. Это такое краткое описание бага обычно примерно в одно предложение, которое составляется по принципу “Что, где, когда”
2. Шаги воспроизведения этого бага. Т.е. список шагов, которые нужны для того, чтобы этот баг можно было воспроизвести повторно
3. Ожидаемый результат. Это то, какое поведение ожидалось в результате воспроизведения шагов
4. Фактический результат. Это то, как в итоге работает
5. Северити и приорити. Северити - это то, как этот баг влияет на систему. Тут обычно 5 уровня - начиная с минор и заканчивая блокером. Приорити - это важность этого бага для бизнеса. И обычно это влияет на то, как быстро этот баг будет исправлен. То есть если у бага высокий приоритет, то его починят как можно скорее.

Помимо этого обязательно должно быть указано, кто создал этот баг, на кого назначен. Также часто стоит указать, на каком окружении был найден баг, а также приложить скриншот, скринкаст или может даже ****. Еще, если в проекте так устроено, то нужно будет проставить какие-либо теги к этому баг-репорту.

В чем разница между приоритетом и серьезностью

Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения. Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Если вкратце - серьезность относится к технической стороне вопроса, а приоритет – к менеджерской

Какая бывает тестовая документация

Для начала она бывает внутренняя и внешняя.
Внутренняя используется внутри команды тестирования и не будет передаваться заказчику или кому либо еще. К примеру, это тест-план, тест-кейс и чек-лист
Тест-план нужен для того, чтобы распланировать активность по тестированию в команде.
Тест-кейсы и чек-листы нужны для того, чтобы составить список проверок, на основе которым мы будем выполнять тестирование
Внешняя документация - это та, которую мы предоставляем кому-то. Например, это тест-репорты, баг-репорты. Еще есть матрица покрытия тестами, но этот документ не часто встречается на практике.

Тест план

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

1. ID тест плана (Test plan identifier);
2. Введение (Introduction);
3. Объект тестирования (Test items);
4. Функции, которые будут протестированы (Features to be tested;)
5. Функции, которые не будут протестированы (Features not to be tested);
6. Тестовые подходы (Approach);
7. Критерии прохождения тестирования (Item pass/fail criteria);
8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
9. Результаты тестирования (Test deliverables);
10. Задачи тестирования (Testing tasks);
11. Ресурсы системы (Environmental needs);
12. Обязанности (Responsibilities);
13. Роли и ответственность (Staffing and training needs);
14. Расписание (Schedule);
15. Оценка рисков (Risks and contingencies);
16. Согласования (Approvals).

Тест кейсы

Тест-кейсы (test cases) — это детально прописанные условия и шаги, предназначенные для проверки определённого аспекта работы ПО. Каждый тест-кейс призван проверить, правильно ли система или её часть выполняет заданную функцию в соответствии с требованиями. Помогают обеспечить, что ПО работает корректно и без ошибок в различных ситуациях и условиях.
Структура тест-кейса обычно включает:
1. Идентификатор (ID): Уникальный номер или код для идентификации.
2. Название (Title): Краткое описание цели.
3. Предусловия (Preconditions): Условия, которые должны быть выполнены до начала тестирования.
4. Шаги (Steps): Последовательность действий, которые необходимо выполнить для проведения теста.
5. Тестовые данные (Test Data): Конкретные значения или данные, используемые при тестировании.
6. Ожидаемый результат (Expected Result): Описание того, как система должна реагировать на выполнение тестовых шагов, если она работает корректно.
7. Фактический результат (Actual Result): Реальный результат выполнения теста, который заполняется во время тестирования.
8. Статус (Status): Отражает, прошёл тест успешно (Passed), не прошёл (Failed) или был пропущен (Skipped).
9. Комментарии (Comments): Дополнительная информация, наблюдения или проблемы, выявленные в ходе тестирования.
Зачем нужны тест-кейсы:

• Чёткость и структурированность: Позволяют систематизировать процесс тестирования, делая его предсказуемым и воспроизводимым.
• Повторное использование: Они могут использоваться повторно в различных циклах тестирования, включая регрессионное тестирование.
• Документация: Служат документацией процесса тестирования, что упрощает введение новых сотрудников в проект и обеспечивает прозрачность для всех заинтересованных сторон.
• Планирование и оценка: Они помогают в планировании тестирования и оценке трудозатрат, а также в управлении рисками, позволяя сфокусироваться на наиболее критичных аспектах системы.

Требования

Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Атрибуты требований:

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность — требование должно содержать однозначные формулировки.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость — в каждое требование можно внести изменение.
9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Чем тест кейс отличается от чек листа

Чек-лист — это список того, что нужно проверить. Например, можно составить чек-лист для проверки сайта или отдельного его компонента — скажем, личного кабинета или корзины.
Тест-кейс — ****это пошаговое описание того, как мы будем тестировать ту или функцию. Например, если это личный кабинет на сайте, в тест-кейсе будут прописаны конкретные действия: зайти на сайт фирмы «Рога и копыта», ввести логин и пароль, нажать кнопку «Войти» и так далее.

Вопросы из практики

Как часто следует проводить регрессионое тестирование

1. После каждого значимого изменения: Регрессионное тестирование следует проводить после внесения значительных изменений в код или функциональность продукта. Это включает в себя добавление новых функций, исправление критических дефектов и изменения, которые могут повлиять на существующий функционал.
2. По мере необходимости: В некоторых случаях, когда продукт стабилен и изменения редки, регрессионное тестирование может проводиться по мере необходимости, основываясь на анализе рисков и изменений.
3. Автоматизированное регрессионное тестирование: Если у вас есть возможность автоматизировать регрессионное тестирование, то оно может выполняться чаще, даже ежедневно, чтобы быстро обнаруживать дефекты после внесения изменений.

Примеры, когда следует провести такое тестирование:

• добавление новой функции или изменение старой;
• исправление багов, которые значительно влияли на систему, или же исправление большого количества багов;
• оптимизация исходного кода для повышения производительности;
• установка исправлений (патчей);
• изменения конфигурации.

Когда можно начинать тестирование

Тестирование может начинаться на разных этапах жизненного цикла разработки в зависимости от методологии разработки.
Водопадная модель предполагает последовательное выполнение фаз жизненного цикла, начиная с анализа требований, затем проектирования, разработки, тестирования, развертывания и поддержки. В этой модели тестирование начинается после завершения разработки.
В методологиях Agile, например Scrum, тестирование начинается как можно раньше, и происходит параллельно с другими этапами жизненного цикла разработки. Тестирование может проводиться на каждом этапе разработки, начиная с планирования, и продолжаться до конца проекта.

Когда можно заканчивать тестирование

Завершение тестирования зависит от конкретных требований проекта, стадии жизненного цикла разработки и целей тестирования. Ниже перечислены некоторые общие критерии, которые могут использоваться для завершения тестирования:

1. Успешное выполнение всех тестов
2. Достижение определенного уровня качества
3. Утверждение руководства
4. Исчерпание бюджета и времени
5. Запуск в производство

Важно учитывать, что тестирование является непрерывным процессом и может продолжаться на протяжении всего жизненного цикла продукта. Кроме того, после завершения тестирования могут проводиться дополнительные проверки и исправления, чтобы обеспечить качество продукта.

Зачем нужна автоматизация тестирования и когда ее нужно и не нужно применять

Из-за чего нужна автоматизация:

1. Эффективность и повторяемость: автотесты могут быть быстро и повторно выполнены на разных этапах разработки и после каждого изменения в коде. Это позволяет обнаруживать дефекты раньше и быстрее, сокращая время, необходимое для тестирования.
2. Охват тестирования: Автоматизация позволяет легко охватить большой объем тест-кейсов, что может быть трудно и затратно сделать вручную. Это особенно важно для проектов с частыми изменениями и большими требованиями.
3. Устойчивость к человеческой ошибке: Автоматические тесты выполняются без участия человека, что снижает риск человеческих ошибок при выполнении однотипных задач.
4. Скорость разработки: Автоматизация ускоряет процесс разработки, поскольку тесты могут быть запущены многократно в течение короткого времени, что способствует более быстрой разработке.
5. Экономия времени и ресурсов: Автоматизация снижает расходы на тестирование в долгосрочной перспективе, поскольку уменьшает необходимость в больших командах тестировщиков и позволяет сэкономить время.

Когда нужна автоматизация:

1. Частые релизы: Если проект часто обновляется, автоматизация помогает поддерживать высокий темп тестирования
2. Большой объем регрессионного тестирования: Автоматизация эффективно справляется с регрессионным тестированием после каждого изменения в коде
3. Долгосрочные проекты: Для проектов, которые будут разрабатываться или поддерживаться длительное время, автоматизация экономит ресурсы в будущем
4. Сложные и часто повторяемые тест-кейсы

Когда не нужна автоматизация:
Автотесты не являются подходящей альтернативой, если сценарии тестов новые и не тестировались вручную, если тесты требуют постоянных изменений и в случае, если запустить сценарий тестирования нужно только один раз.

Откуда брать требования, если нет документации

1. Общение с заинтересованными сторонами (stakeholders): Это могут быть разработчики, аналитики, менеджеры проекта, заказчики или даже конечные пользователи. Они могут предоставить информацию о целях и задачах проекта, ожиданиях от функционала и критериях его успешности.
2. Изучение существующего продукта: Если проект не новый, то изучение уже существующего функционала может дать понимание ожидаемого поведения системы. Это поможет определить, какие аспекты продукта важны и какие могут быть потенциальными точками для тестирования.
3. Использование агил-методологий (например, Scrum или Kanban): В таких методологиях требования часто формулируются в виде пользовательских историй (user stories), которые описывают функционал с точки зрения конечного пользователя. Работа в тесном взаимодействии с командой разработки и постоянное уточнение деталей помогают детализировать требования даже без формальной документации.
4. Анализ конкурентов: Изучение продуктов-аналогов может дать представление о стандартных функциях и возможностях, которые ожидаются от аналогичных систем. Это помогает выявить неявные требования, которые могут быть не очевидны изначально.
5. Проведение сессий мозгового штурма: Совместные сессии с командой проекта могут помочь сгенерировать идеи и определить требования, на основе знаний и опыта участников.
6. Прототипирование: Создание прототипов или MVP (минимально жизнеспособный продукт) позволяет на ранних этапах получить обратную связь от пользователей и уточнить требования на основе этой обратной связи.
7. Техническая документация и API: Даже если нет прямой документации по требованиям, техническая документация по API или архитектуре системы может дать понимание о предполагаемых взаимодействиях и ограничениях.

Что делать, если баг воспроизводится после исправления

Проверка условий тестирования: нужно убедиться, что тестовая среда, версия продукта и прочие условия точно соответствуют тем, на которых исправление должно было быть проверено. Иногда проблема может возникать из-за различий в окружении или неправильной конфигурации.
2. Точное воспроизведение шагов: Нужно абсолютно точно воспроизвести шаги и убедиться, что все детали и шаги выполнены точно. Иногда могут быть упущены важные детали, которые влияют на воспроизведение проблемы.
3. Сбор дополнительных данных: После всего это будет хорошо собрать как можно больше информации о баге и условиях его воспроизведения после якобы исправления. Скриншоты, видеозаписи, **** ошибок и точное описание шагов могут помочь разработчикам лучше понять проблему.
4. Обновление или повторное открытие баг-репорта: Если после всех проверок баг действительно воспроизводится, следует обновить статус существующего отчета о баге или повторно его открыть, предоставив обновленную информацию и данные, подтверждающие его воспроизведение. Важно указать, что баг был проверен после сообщения о его исправлении, и подробно описать условия, при которых он воспроизводится.
5. Коммуникация с разработчиками: Важно наладить прямой диалог с разработчиком или командой, ответственной за исправление, для обсуждения деталей воспроизведения проблемы и возможных причин, по которым она не была устранена. Эффективная коммуникация помогает быстрее найти решение.
6. Проверка зависимостей: Иногда баг может быть связан с другими проблемами или изменениями в коде, произведенными после его первоначального исправления. Проверьте, не было ли внесено других изменений, которые могли повлиять на поведение компонента или функционала.
7. Рассмотрение альтернативных сценариев: Если баг воспроизводится не всегда или только при определенных условиях, стоит изучить эти условия подробнее и рассмотреть возможность тестирования альтернативных сценариев использования функционала.

Техническое

Какие есть HTTP методы

1. GET: Используется для получения ресурса с сервера. Запрос GET не должен изменять состояние сервера.
2. POST: Используется для отправки данных на сервер для обработки. Запрос POST может изменять состояние сервера.
3. PUT: Используется для обновления ресурса на сервере. Запрос PUT заменяет ресурс на сервере новыми данными.
4. DELETE: Используется для удаления ресурса на сервере.
5. PATCH: Используется для частичного обновления ресурса на сервере.
6. OPTIONS: Используется для получения параметров текущего HTTP соединения.
7. HEAD: Используется для получения метаданных о ресурсе на сервере без получения самого ресурса.
8. TRACE: Создает петлю, благодаря которой клиент может увидеть, что происходит с сообщением на всех узлах передачи

Чем отличается GET от POST

Назначение и использование:

• GET обычно используется для запроса данных от сервера. Параметры запроса кодируются в URL, что делает их видимыми в адресной строке браузера. Это удобно для сохранения или закладок URL, но не подходит для передачи конфиденциальной информации.
• POST используется для отправки данных на сервер для обработки. Например, при отправке формы на веб-странице. Данные, отправляемые этим методом, включаются в тело запроса, что делает их невидимыми в адресной строке.

2. Ограничения данных:

• GET имеет ограничения на длину данных, поскольку вся информация находится в URL. Размер URL ограничен (ограничение может варьироваться в зависимости от браузера и сервера), что ограничивает количество данных, которые можно отправить.
• POST не имеет ограничений на размер данных, что позволяет отправлять большие объёмы информации.

3. Безопасность:

• GET менее безопасен по сравнению с POST, потому что данные видны в URL, и они могут быть сохранены в истории браузера или логах сервера.
• POST более безопасен, так как данные не отображаются в URL и не сохраняются в истории браузера.

4. Кеширование и история браузера:

• GET может кешироваться браузерами и серверами, а URL с GET-параметрами может быть сохранён в истории браузера, что упрощает повторный доступ к тем же ресурсам.
• POST запросы, как правило, не кешируются и не сохраняются в истории браузера, что делает их менее удобными для повторного использования, но более подходящими для передачи данных, которые не должны быть легко доступны или кешированы.

5. Идемпотентность:

• GET считается идемпотентным, что означает, что повторение одного и того же GET-запроса будет иметь тот же эффект, что и его однократное выполнение.
• POST не идемпотентен, так как повторная отправка одного и того же POST-запроса может привести к повторной обработке данных на сервере (например, дважды разместить заказ).

GET используется для запроса данных и может быть сохранён в истории браузера и кеширован. POST используется для отправки данных на сервер, более безопасен и подходит для больших объёмов данных. GET как открытая витрина магазина, где вы можете только смотреть товары, а POST - это когда вы решили что-то купить и обращаетесь к продавцу через закрытый канал.

Статус-коды (1хх 2xx 3xx 4xx 5xx)

1xx (Информационные): Этот класс кодов статуса указывает, что сервер получил запрос, и он продолжает его обработку. Он используется для информационных сообщений, например, когда сервер отправляет клиенту заголовки ответа.
2xx (Успешные): Этот класс кодов статуса указывает, что запрос клиента был успешно обработан сервером. Наиболее распространенный код в этом классе - 200 OK, который указывает на успешное выполнение запроса.
3xx (Перенаправления): Этот класс кодов статуса указывает, что клиент должен выполнить дополнительные действия для завершения запроса. Например, код 301 Moved Permanently указывает на необходимость перенаправления клиента на новый URL.
4xx (Ошибки клиента): Этот класс кодов статуса указывает, что сервер не смог выполнить запрос из-за ошибки, связанной с запросом клиента. Например, код 404 Not Found указывает на то, что запрашиваемый ресурс не найден на сервере.
5xx (Ошибки сервера): Этот класс кодов статуса указывает, что сервер не смог выполнить запрос из-за ошибки, связанной с сервером. Например, код 500 Internal Server Error указывает на ошибку сервера при обработке запроса.

Структура HTTP запроса и ответа

HTTP запрос:

• Метод (GET, POST, PUT, DELETE и т.д.)
• URL (Это адрес ресурса на сервере, к которому клиент хочет получить доступ или выполнить действие. URL включает в себя протокол (например, "http://" или "https://"), доменное имя (например, "www.example.com ") и путь к конкретному ресурсу на сервере)
• Заголовки (Заголовки содержат дополнительную информацию о запросе, такую как тип контента, язык, куки, агент пользователя и другие метаданные)
• Тело (Некоторые типы запросов (например, POST) могут содержать данные, которые клиент отправляет на сервер. Эти данные находятся в теле запроса.)

HTTP ответ:

• Статус код (например, 200 для успешного запроса)
• Заголовки (Как и в случае с запросом, заголовки ответа могут содержать дополнительную информацию, такую как тип контента, дата, сервер и другие метаданные.)
• Тело ответа (Это часть ответа, содержащая данные, запрошенные клиентом (например, HTML-код веб-страницы, JSON-данные и т. д.).)

Клиент серверная архитектура

Клиент-серверная архитектура — это модель взаимодействия, где система делится на две основные части: клиент и сервер. Вот как это работает:

1. Клиент: Это устройство или приложение, которое отправляет запросы к серверу. Клиент обычно отвечает за интерфейс пользователя и взаимодействие с ним. Например, веб-браузер, мобильное приложение или настольное приложение могут выступать в роли клиента.
2. Сервер: Это более мощный компонент, который принимает запросы от клиентов, обрабатывает их и отправляет ответы обратно. Сервер может выполнять множество задач, таких как хранение данных, выполнение бизнес-логики и обеспечение безопасности. Примеры серверов включают веб-серверы, базы данных и файловые серверы.

Как это работает:

• Запрос и ответ: Клиент отправляет запрос к серверу через сеть (например, Интернет). Сервер обрабатывает запрос, выполняет необходимые действия (например, получает данные из базы данных) и возвращает ответ клиенту.
• Протоколы: Взаимодействие между клиентом и сервером часто осуществляется через стандартные сетевые протоколы, такие как HTTP для веб-приложений или FTP для передачи файлов.
• Разделение обязанностей: Клиент и сервер выполняют разные задачи, что позволяет улучшить производительность и масштабируемость системы. Клиенты могут обращаться к серверу для получения данных, а серверы могут обрабатывать запросы и предоставлять ресурсы, не перегружая клиентскую часть.

Что такое JSON

JSON (JavaScript Object Notation) — это легкий формат для обмена данными, основанный на языке JavaScript, но используемый независимо от него. Он представляет данные в виде пар "ключ-значение", что делает его удобным для хранения и передачи структурированных данных. Почему JSON так популярен?

1. Легкость чтения и написания:
   Для человека этот формат довольно прост и понятен, а для машины — легко разбираем и генерируем.
2. Широкая поддержка:
   Большинство языков программирования имеют встроенные библиотеки для работы с ним, что делает его удобным для межплатформенного обмена данными.
3. Эффективность:
   Будучи текстовым форматом, оптимален для обмена данными через сеть и легко сжимается, что снижает затраты на трафик.

Что такое кэш

Кэш - это механизм хранения данных, который позволяет ускорить доступ к часто используемым ресурсам. Когда браузер загружает веб-страницу, он сохраняет некоторые данные в кэш на ваш ПК для быстрого доступа к этим данным в будущем. Кэш может хранить данные, такие как изображения, скрипты, стили, файлы cookie и другие ресурсы.
Кэширование может ускорить загрузку страниц и уменьшить нагрузку на сервер, так как браузер может использовать ресурсы, которые уже находятся в кэше, вместо того, чтобы загружать их снова. Кроме того, кэш может помочь уменьшить использование сетевых ресурсов и трафика, что особенно важно для мобильных устройств и медленных интернет-соединений.
Однако, кэш может также стать причиной проблем, например, когда в кэше сохраняются устаревшие данные или когда разработчик обновляет ресурсы на сервере, но пользователи продолжают использовать старые версии, сохраненные в кэше. В таких случаях нужно вручную обновить кэш или же дождаться его обновления

Что такое cookie и для чего они нужны

Cookies - это небольшие файлы, которые хранятся на компьютере пользователя и содержат данные, связанные с веб-сайтом, который он посещает. Они часто используются для хранения информации о пользователе и его настройках на веб-сайте.
Вот несколько причин, по которым сайты используют cookies:

1. Авторизация и управление сессиями: cookies используются для хранения идентификатора сессии, который помогает серверу отслеживать активности пользователя на сайте в течение сессии.
2. Хранение настроек пользователя: cookies могут использоваться для хранения настроек пользователя, таких как язык, который он предпочитает, и другие настройки.
3. Отслеживание поведения пользователя: cookies могут использоваться для отслеживания поведения пользователя на сайте, таких как страницы, которые он посещает, и товары, которые он добавляет в корзину.
4. Реклама и маркетинг: cookies могут использоваться для показа на сайте релевантной рекламы на основе интересов пользователя.
5. Аналитика: cookies могут использоваться для анализа трафика на сайте и поведения пользователей, чтобы улучшить производительность и пользовательский опыт.

Cookies могут быть полезным инструментом для сайтов и пользователей, но также могут представлять угрозу для конфиденциальности и безопасности. Поэтому тестировщики должны проверять, как веб-приложения обрабатывают и хранят cookies, чтобы убедиться в их правильной работе и защите конфиденциальности пользователей.

Чем отличается кэш от куки

Кэш помогает ускорить работу сайта, сохраняя ресурсы (например, изображения), а куки сохраняют информацию о вас и вашем взаимодействии с сайтом (например, настройки языка, темной темы или данные о входе в систему)

Что такое сессия

Сессия - это период времени, в течение которого пользователь взаимодействует с веб-приложением. Каждая сессия начинается, когда пользователь входит в систему, и заканчивается, когда пользователь выходит из системы или когда сессия истекает.
Во время сессии сервер сохраняет данные о пользователе, такие как ID и другие данные, которые используются для отслеживания действий пользователя на сайте. Эти данные могут включать в себя информацию о предыдущих действиях пользователя, таких как страницы, которые он посещал, товары, которые он добавил в корзину, и другие детали, связанные с его сеансом.
Сессии часто используются для управления безопасностью и авторизацией на веб-сайтах. Например, при входе в систему пользователь получает уникальный идентификатор сессии, который используется для проверки правильности доступа к различным страницам и функциям сайта. Если пользователь выходит из системы или сессия истекает, то идентификатор сессии становится недействительным, и пользователь должен войти в систему снова, чтобы продолжить работу.

Какие протоколы передачи данных

• IP
• TCP
• UDP
• HTTP
• HTTPS
• DNS
• SSH

Какие основные форматы передачи данных

• XML
• JSON
• YAML

Чем отличается REST от SOAP протокола

• REST — это архитектурный стиль. SOAP — это формат обмена сообщениями, имеющий веб-сервис WSDL с прописанными методами, которые можно удаленно вызывать.
• REST работает только по HTTP/HTTPS, SOAP — с любым протоколом прикладного уровня: SMPT, FTP, HTTP, HTTPS, POP3.
• REST наследуется от протокола HTTP и употребляет все его правила.
• REST более прост, гибок и быстр, SOAP типизирован, но в некоторых случаях лучше визуализируется за счет применения синтаксиса, похожего на HTML разметку.
• REST использует Json и XML, SOAP — только XML.

Что такое API

АРI - это набор способов и правил, по которым различные программы общаются между собой и обмениваются данными

Авторизация и аутентификация

Аутентификация и авторизация - это два разных понятия, хотя они часто употребляются вместе.
Аутентификация - это процесс проверки подлинности пользовательских учетных данных, например логина и пароля.
Авторизация - это процесс определения прав доступа пользователя к ресурсам системы после успешной аутентификации. Это процесс проверки прав пользователя.
Проще говоря, аутентификация проверяет, кто вы такой, а авторизация проверяет, что вы можете делать на сайте или в системе после того, как вы зарегистрировались и вошли в свою учетную запись. Например, после того, как вы ввели свой логин и пароль, система проводит проверку этих данных (аутентификация), а затем определяет, какие действия вы можете совершать в системе (авторизация).

Какие есть типы приложений

• Веб-приложения — это приложения, которые работают через веб-браузер и не требуют установки на устройство пользователя. Например, Gmail или Facebook. Они удобны тем, что доступны с любого устройства с интернет-браузером, и обновления происходят на сервере.
• Мобильные приложения устанавливаются на смартфоны и планшеты. Примеры включают Instagram и WhatsApp. Эти приложения оптимизированы для мобильных устройств и могут использовать функции, такие как GPS или камера.
• Настольные приложения предназначены для установки на компьютеры и ноутбуки. Это такие приложения, как Microsoft Office или Adobe Photoshop. Они часто имеют более широкие функциональные возможности и могут работать в оффлайн-режиме.
• Гибридные приложения сочетают элементы веб- и мобильных приложений. Они устанавливаются на мобильные устройства, но используют веб-технологии. Например, Uber или Twitter. Они позволяют разрабатывать одно приложение для нескольких платформ.
• Кроссплатформенные приложения разрабатываются так, чтобы работать на различных платформах, таких как iOS и Android, используя единую кодовую базу. Примеры — Slack и Spotify. Это упрощает разработку и поддержку приложения.
• Серверные приложения работают на сервере и предоставляют функциональность другим приложениям или пользователям через сеть. Примеры — веб-серверы и базы данных. Они управляют данными и бизнес-логикой на серверной стороне.
• Встраиваемые приложения встроены в устройства или системы, например, в бытовую технику или автомобили. Это может быть программное обеспечение для управления автомобилем или умные часы. Эти приложения интегрируются с аппаратным обеспечением для выполнения специализированных функций.
• Бизнес-приложения предназначены для использования в бизнесе и помогают автоматизировать и улучшать бизнес-процессы. Примеры включают CRM-системы или системы управления проектами. Они помогают оптимизировать процессы и управлять данными.

Что такое local storage

localStorage — это веб-хранилище, которое позволяет сохранять данные в браузере на неопределенный срок. Эти данные остаются в браузере, пока пользователь сам их не удалит или не очистит кеш. Например, можно использовать localStorage, чтобы сохранить пользовательские настройки или предпочтения, которые должны сохраняться между сессиями и перезапусками браузера. Данные, сохраненные в localStorage, доступны для всех вкладок и окон в одном браузере.

Что такое session storage

sessionStorage — это также веб-хранилище, но оно сохраняет данные только в рамках текущей сессии. Данные будут удалены, как только пользователь закроет вкладку или браузер. Это удобно для хранения временных данных, таких как состояние формы или информация, которую не нужно сохранять между сессиями. В отличие от localStorage, данные в sessionStorage доступны только в пределах одной вкладки или окна браузера и не передаются между разными вкладками.

Монолит и микросервисы

Монолит и микросервисы — это два разных подхода к архитектуре приложений.
Монолит — это когда всё приложение работает как единое целое. Все компоненты, такие как интерфейс, бизнес-логика и работа с данными, находятся в одном коде. Это может быть удобно, потому что проще разрабатывать и тестировать всё в одном месте. Но есть и минусы: если приложение растёт, его поддержка и масштабирование могут стать сложными, и любые изменения требуют перезапуска всего приложения.
Микросервисы — это подход, при котором приложение разбивается на несколько независимых сервисов. Каждый сервис выполняет конкретную функцию и может разрабатываться, развертываться и масштабироваться отдельно. Это даёт гибкость и позволяет масштабировать только те части, которые нуждаются в этом. Но это также добавляет сложности, так как нужно управлять взаимодействием между сервисами и следить за их развертыванием и мониторингом.
В общем, монолит проще в разработке и развертывании, но может стать сложным в поддержке по мере роста. Микросервисы предлагают больше гибкости и масштабируемости, но требуют более сложного управления и координации.