Agile глазами тестировщика

Всем привет! Меня зовут Арслан — я тестировщик агентства по тестированию и обеспечения качества “Кавычки”. Занимаюсь ручным тестированием. Являюсь идеологом и основателем курса “Вселенная тестирования, или Как стать тестировщиком” на Степике.

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

В 2021 году я попал на B2C проект, использующий Scrum для построения процессов.

Задачи Kanban доски проходили следующие этапы:

• Запланированные задачи. Здесь задачи ждут своего часа
• Задачи на анализе. Здесь аналитики проектируют систему и формируют требования.
• Задачи в разработке. Этап для разработчиков и дизайнеров.
• Тестирование на тестовом стенде. Здесь тестировщики тестируют задачу и проводят регресс.
• Тестирование на боевом стенде. Здесь тестировщики тестируют задачу и проводят тесты критического пути.
• Закрытие задачи. Закрываем задачи, если все ок.

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

Команду устраивал процесс работы. Задач было немного — работа шла по плану.

Проблемы проявились, когда на проекте поменялся Product Owner, который расчехлил водомет фич. Задач стало больше … Сильно больше.

Это привело к тому, что в колонке QA оказалось 40 задач и один тестировщик — я.

Задачи часто возвращались. Дедлайны воскрешались. Причины были следующие:

• Ожидаемый результат тестировщиков не совпадал с ожидаемым результатом разработчиков. Например, есть список со странами. В этом списке присутствует значение “Весь мир”. В требовании не было правила, описывающего логику работы данного пункта. Итог — можно было выбрать “Весь мир” и другие страны.
• Отсутствие подсказок пользователю. Например, есть валидация поля “Email пользователя” по следующей маске “символы@символы.домен”. Если указать несуществующий домен, то выводилась неинформативная ошибка, не указывающая пользователю причину этой ошибки.

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

Проблема

Наш процесс работы выглядел так:

1. Бизнес поставил задачу.
2. Аналитики и дизайнеры спроектировали систему.
3. Разработчики написали код.
4. Тестировщики проверили.

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

В итоге мы получаем следующие проблемы:

• Неравномерная работа тестировщиков: то задачи отсутствуют, то завал перед релизом.
• Требования, содержащие ошибки.
• Частые возвраты задач на предыдущие этапы.
• Низкое покрытие автотестами.

Исходя из этого можно сделать следующий вывод — Agile не такой уж и гибкий? К счастью, это не так. На самом деле проблема не в Agile, а в его неправильном использовании.

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

Главное — понять, что использование инструментов типа систем контроля воркфлоу, как Jira или TeamCity и проведение ежедневных дейли-митингов не делают нас Agile-командой. Agile-командой является та команда, каждый член которой понимает свою ответственность за качество продукта. Качество продукта определяет не только код. Качество продукта начинается с требований. А как проверить качество требований? Так же как и проверить качество кода — тестировать.

«Перехват ошибок на ранних стадиях проекта представляет собой наименее затратный способ обеспечения качества продукта … В разработке программного обеспечения есть дилемма: дефекты обходятся дорого, но устранение дефектов также обходится дорого. Однако, большинство дефектов в итоге превышают средства, которые были бы затрачены на их предотвращение».

Необходимо привлекать тестировщиков на все этапы разработки продукта, начиная с бизнес-требований. Чем раньше найден баг, тем дешевле его устранение, так как время разработки сильно сокращается. Согласно исследованию “Национального института стандартов и технологий США” ситуация следующая:

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

Shift Left Testing предполагает использование автоматизации тестирования, непрерывная интеграция и непрерывное развертывание (CI/CD). С их помощью разработчики могут быстро выявлять дефекты и уязвимости в коде и устранять их до того, как они приведут к серьезным проблемам.

Кроме того, Shift Left Testing помогает улучшить коммуникацию между тестировщиками и другими членами команды разработки.

Решение

Сначала мы переработали процесс разработки и тестирования. Добавили новые этапы, учитывая наши проблемы:

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

В итоге у нас получился следующий процесс разработки:

Также мы пересмотрели стратегию автотестов. Автотесты должны запускаться не каждую ночь, а при релизе каждой задачи, чтобы получить максимальную выгоду от Shift Left Testing.

Запуская автотесты регулярно, можно получить следующие преимущества:

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

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

• Пакет smoke-тестов проверяет критический путь пользователя и проверяет работу всех служб. Эти API-тесты и UI-тесты, которые запускаем при каждом деплое приложения.

• Функциональные пакеты тестов — детальная проверка работы каждого раздела приложения. В связи с тем, что выполнение функциональных тестов требует большего времени, решено перенести их на уровень API. Тестирование на уровне API позволяет проводить тесты быстрее. Данные тесты запускаем в зависимости от задач релиза.

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

Итог

Закончив внедрение нового процесса разработки было обнаружено:

• Требования стали качественными. Споров насчет ожидаемого результата снизились в разы.
• Задачи стали реже возвращаться, что ускорило время доставки фич пользователю.
• Благодаря новой стратегии автотестов, количество багов пропущенных на боевой стенд уменьшилось, что позволило разгрузить команду тех. поддержки. Также ручные тестировщики все меньше тестируют регресс. Надеюсь, скоро вообще перестанут.

Данный опыт позволил мне выделить главные принципы в работе тестировщика в Agile-команде:

• Сотрудничество с другими членами команды: Тестировщик должен активно сотрудничать с другими членами команды. Он должен принимать участие в планировании, обсуждении требований и определении приоритетов.

• Создание и поддержание автоматизированных тестов: Команда тестирования должна создавать и поддерживать автоматизированные тесты для обеспечения качества продукта и быстрого обнаружения ошибок.

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

• Постоянное улучшение процесса: Тестировщик должен постоянно улучшать процесс тестирования и внедрять новые методы и инструменты для повышения качества продукта и ускорения процесса разработки.

При раннем тестировании необходимо уделить внимание правильному планированию, выбору тестовых сценариев и их автоматизации, а также внедрению средств непрерывной интеграции и непрерывной доставки (CI/CD).

Напоследок, хочу привести цитату из книги “Как тестируют в Google”:

“В итоге качество достигается предотвращением, а не выявлением багов…”

P.S. Кстати о книгах. Вот хорошие книжки для изучения темы:

1. Agile-тестирование. Обучающий курс для всей команды. Авторы: Джаннет Грегори и Лайза Криспин
2. Как тестируют в Google. Авторы: Уиттакер Д., Арбон Д., Каролло Д.
3. Экстремальное программирование. Разработка через тестирование. Автор: Кент Бек

Не судите строго — это мой первый опыт публикации. Спасибо за внимание!