Всем привет! Меня зовут Иван Чечиков, я 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-проекта. Она, конечно же, не универсальна и не объемна, ее можно дополнить процессами и практиками. Они могут уже быть в вашем проекте или появиться там со временем, но базово я вижу стратегию такой. 

Спасибо за уделенное время, если у вас есть вопросы – буду рад на них ответить в комментариях.