Всем привет! Меня зовут Иван Чечиков, я 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, Яндекс.Танк).
End-To-End тесты (регрессионное тестирование)
E2E-тесты – автоматизируемые тесты, проверяющие тестовый сценарий от начала до конца. Могут быть как и API, так и UI-тесты.
В команде E2E-тесты должен писать QA Automation-инженер. Приступать к работе лучше сразу после планирования, а релизить задачи – вместе или после релизов продукта.
QA Automation-инженер берет задачу в работу в зависимости от ее приоритета. Написав автотест, QA Automation-инженер должен прогнать свой код с помощью CI/CD-инструмента вместе с остальными тестами затронутого модуля. Далее инженер отправляет задачу на ревью. В случае наличия замечаний код исправляют, тесты повторно прогоняются с помощью CI/CD, код еще раз проверяется и мерджится в мастер ответственным лицом.
E2E-тесты или регресс запускаются на завершающей стадии тестирования, перед выпуском релиза в прод, когда ручное тестирование уже было проведено. Регрессионные тесты лучше проводить через CI/CD-инструмент. Критерий успеха – прохождение всех тестовых сценариев.
Внедрение
Внедрение или деплой – завершающая стадия жизненного цикла ПО, обычно выполняется ответственными лицами. Схема такая – ветка в системе управления версиями, содержащая задачи релиза, мерджится в ветку прода, QA-инженер проверяет логи после деплоя, по возможности проводит функциональное тестирование на проде, а заинтересованные лица получают итоговый результат. В случае успеха релиз и все входящие в него задачи переводятся в статус «готово». Если обнаружены блокирующие или критические баги – релиз откатывается через систему управления версиями. Внедрение завершено.
Вот и все! Таким образом можно составить стратегию тестирования для Agile/Scrum-проекта. Она, конечно же, не универсальна и не объемна, ее можно дополнить процессами и практиками. Они могут уже быть в вашем проекте или появиться там со временем, но базово я вижу стратегию такой.
Спасибо за уделенное время, если у вас есть вопросы – буду рад на них ответить в комментариях.
