Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение. В моем понимании, стратегия тестирования – это набор практик и целей тестирования, применяемых на проекте. Стратегия помогает понять, где и как лучше использовать тестирование в жизненном цикле разработки ПО. Почему Agile? На мой взгляд, эта методология востребована в компаниях разного размера за счет своей гибкости и архитектуры процессов: она позволяет качественно и быстро выпускать продукты на рынок. Это – заметный плюс Agile. Я покажу стратегию тестирования на примере гибкой модели разработки ПО (Agile). Вы можете использовать ее элементы для своей модели. Гибкая модель разработки обычно состоит из 5 позиций (Планирование-> Разработка-> Тестирование-> Демонстрация-> Внедрение). Пункт Демонстрация я опущу в этой статье, поэтому рассмотрим такой цикл: Планирование-> Разработка-> Тестирование-> Внедрение Итак, пойдем по порядку: Представим, что команда работает n-недельными спринтами, каждый спринт ориентирован на конкретные пользовательские истории. В рамках планирования спринта происходят следующие процессы: заведение, проработка задач и историй, определение приоритетов и серьезности задач, их оценка. В итоге задачи формируют релизы, которые добавляются в спринт и определяют его цель. QA-инженер после этого этапа уже может начинать создавать тест-кейсы/чек-листы к задачам. В процессе необходимо опираться на функциональные требования, это станет хорошей практикой. Инструменты в этом случае – баг-трекер и система для создания тестов. Критерии успеха – верно сформулированные требования к задаче и созданная тестовая документация. Если у команды есть QA Automation-инженер, то на этапе планирования спринта он может заводить задачи для покрытия автотестами нового критически важного функционала. Получив задачу в работу, разработчик пишет код, коммитит изменения и пушит ветку в систему управления версиями. Согласно одному из семи принципов тестирования, тестирование должно начинаться как можно раньше (раннее тестирование экономит время и деньги). В этом случае хорошей практикой тестирования станет использования юнит- и интеграционных тестов. Юнит-тесты – это модульные или компонентные тесты, направленные на проверку отдельных модулей системы. Модульные тесты пишут разработчики. Разработчик во время работы над задачей должен покрывать новый код юнит-тестами. Перед отправкой задачи на ревью ветка разработчика должна проверяться юнит-тестами с запуском их в CI/CD-инструменте. В случае успешного прохождения тестов, merge request одобряется для ревью. Для контроля этого этапа в системе управления версиями кнопка merge должна быть disabled в случае отсутствия запуска юнит-тестов или же их неудачного прохождения. Интеграционные тесты – это тестирование всех объединенных модулей (компонентов) системы, в результате которого они собираются вместе. После этого модули проверяются на отсутствие ошибок в коде. Интеграционное тестирование должно выполняться после модульного c помощью CI/CD-инструмента. Разработчик пушит ветку в систему управления версиями. Разработчик запускает модульные тесты. Ветка билдится в компилируемый код, содержащий все модули. Запускаются интеграционные тесты. В результате создан pipeline с результатом выполнения тестов. Нужно определить уровни тестирования, которые могут использоваться в проекте. Обычно это: Модульное или компонентное тестирование. Интеграционное тестирование. Системное тестирование. Виды тестирования, которые могут использоваться в проекте: Функциональное. Нефункциональное. Тестирование по доступу к коду (белый/черный ящик). Тестирование с изменениями. Исследовательское тестирование. Следовательно, мы должны построить пирамиду тестирования, где первым и вторым этапами будут тесты разработчиков (модульные и интеграционные), а завершающим – ручное тестирование и автоматизированные end-to-end-тесты (тестирование с изменениями) в рамках системного тестирования, запускаемые QA-инженерами.    Когда задача попала на тестирование, QA-инженер берет ее на выполнение в зависимости от приоритета и создает тест-кейс/чек-лист, если тестовой документации к задаче нет. В зависимости от описания в задаче применяется функциональное/нефункциональное тестирование, тестирование по доступу к коду. При составлении тестовой документации QA-инженер должен использовать подходящие техники тест-дизайна. QA-инженер проверяет задачу и, в случае отсутствия ошибок, подготавливает релиз к регрессионному тестированию. Или же возвращает разработчику на доработку, заведя соответствующий баг. Исследовательское или ad-hoc тестирование – это тестирование в свободной форме, направленное на поиск багов, когда QA-инженер применяет интуитивный подход или накопленные знания о продукте. Когда QA-инженер не загружен задачами, он может проводить исследовательское тестирование системы. Успех здесь – нахождение багов с последующим заведением задач в баг-трекере. Нагрузочное тестирование обычно делится на: тестирование производительности, то есть времени откликов запросов системы. тестирование стабильности – проверка системы при оптимальной нагрузке длительное время. стресс-тестирование – испытание системы под максимальной нагрузкой с достижением падения/отказа. Такое тестирование нужно выполнять при релизе нового/измененного компонента системы, требующего проверки на производительность, масштабируемость, отказоустойчивость, наличие узких мест в коде, утечек памяти, уязвимостей конфигурационной настройки железа. Нагрузочное тестирование необходимо проводить на удаленной машине в тестовой инфраструктуре, с использованием сценариев в соответствующей программе (Jmeter, Яндекс.Танк). E2E-тесты – автоматизируемые тесты, проверяющие тестовый сценарий от начала до конца. Могут быть как и API, так и UI-тесты.  В команде E2E-тесты должен писать QA Automation-инженер. Приступать к работе лучше сразу после планирования, а релизить задачи – вместе или после релизов продукта. QA Automation-инженер берет задачу в работу в зависимости от ее приоритета. Написав автотест, QA Automation-инженер должен прогнать свой код с помощью CI/CD-инструмента вместе с остальными тестами затронутого модуля. Далее инженер отправляет задачу на ревью. В случае наличия замечаний код исправляют, тесты повторно прогоняются с помощью CI/CD, код еще раз проверяется и мерджится в мастер ответственным лицом. E2E-тесты или регресс запускаются на завершающей стадии тестирования, перед выпуском релиза в прод, когда ручное тестирование уже было проведено. Регрессионные тесты лучше проводить через CI/CD-инструмент. Критерий успеха – прохождение всех тестовых сценариев. Внедрение или деплой – завершающая стадия жизненного цикла ПО, обычно выполняется ответственными лицами. Схема такая – ветка в системе управления версиями, содержащая задачи релиза, мерджится в ветку прода, QA-инженер проверяет логи после деплоя, по возможности проводит функциональное тестирование на проде, а заинтересованные лица получают итоговый результат. В случае успеха релиз и все входящие в него задачи переводятся в статус «готово». Если обнаружены блокирующие или критические баги – релиз откатывается через систему управления версиями. Внедрение завершено. Вот и все! Таким образом можно составить стратегию тестирования для Agile/Scrum-проекта. Она, конечно же, не универсальна и не объемна, ее можно дополнить процессами и практиками. Они могут уже быть в вашем проекте или появиться там со временем, но базово я вижу стратегию такой.  Спасибо за уделенное время, если у вас есть вопросы – буду рад на них ответить в комментариях.  Senior QA