Как построить адекватный процесс тестирования на проекте и собрать результативную команду QA

Салют, Хабр! Мы в Clevertec тестируем финтех-приложения, и на практике бывает всякое: мы подключаемся к работающим проектам на разных этапах и ведем их с нуля. Набили шишек, извлекли опыт и делимся, как строим процессы и формируем команды для оптимального эффекта.

Начнем с команды

Сколько нужно тестировщиков на одном проекте? Нет золотого правила. Это зависит от размера команды разработки, задач, которые стоят перед отделом тестирования, и выделенного бюджета.

Но есть закономерности, которые помогают поддерживать последовательный и прозрачный процесс тестирования.

Посмотрим на примере мобильного банковского приложения, которое работает на двух платформах: Android и iOS.

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

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

В это время тестировщики чётко и с полным погружением работают по задачам, не переключаясь на организационные и менеджерские вопросы. Для этого есть тимлид.

Действительно нужно так много людей?

Зачем оплачивать работу стольких тестировщиков, если можно оставить одного на 5-6 разработчиков. 

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

Что случается, когда тестировщик приходит на проект последним

Моделируем негативный сценарий: код написан – на финальном этапе в команду приглашают QA.

На всё есть два месяца. Что получилось? Первый месяц команда потратила на погружение: запрашивали данные с TestRail, доступы к микросервисам, Jira, искали тестовые данные, писали кейсы, тест-план и чек-листы. Разобрались, но остался всего месяц. Выход один: выбрать основные пользовательские сценарии и проверить их, привести к идеальному состоянию. Все остальное выверить не удалось, придется проверять уже после релиза. А это гарантирует, что пользователи столкнутся с проблемами.

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

Переходим к процессу тестирования

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

Иногда на ранних этапах разработки мы привлекаем пользователей в качестве группы для закрытого тестирования. Это даёт возможность продумать улучшения ещё до общего релиза.

Разберём, чем занимается команда тестирования на каждом этапе разработки.

Работа с требованиями

Когда аналитики завершили работу над требованиями, QA их тестируют.

Если находятся дефекты: требование описано не полностью или содержит двусмысленные фразы – они возвращаются к аналитику и быстро редактируются.

Если дефекты в требованиях обнаружатся уже после разработки, на их устранение нужно будет значительно больше времени: изменить требования, переписать код и снова приступить к тестированию. Это сложно и накладно для всего проекта – фактически двойная работа. 

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

• Запрашиваем заранее тестовые данные, если их предоставляет третья сторона.

• Определяем парк устройств, на которых будет проводиться тестирование. 

• Планируем распределение ролей.

Если команда состоит из тестировщиков с разным опытом работы, распределять задачи помогает RACI матрица ролей. Сложные задачи выполняют более опытные люди, менее сложные – люди с небольшим опытом под руководством более опытных.

Разработка

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

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

Для создания и хранения тестовой документации можно использовать готовые инструменты: TestRail, TestLink, JIRA Zephyr и т.д.

Мы используем TestLink, потому что он бесплатный, с развитой системой ролей и уровней доступа и с красивыми отчётами по прогонам.

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

Долгожданный этап наступил. Начинаем активное тестирование, выполняем проверки по уже написанным тест-кейсам или чек-листам. 

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

Обнаруженные дефекты заносим в багтрекинговую систему: Jira Bugzilla, Redmine или другие. 

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

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

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

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

Внедрение и эксплуатация

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

Когда тестирование заканчивается?

Есть три причины, которые встречаются в реальной разработке:

• Все тест-кейсы пройдены, найденные баги исправлены и перепроверены;

• Вышло время;

• Закончился бюджет.

Идеальных процессов и универсальных подходов к ним не бывает. 

Обеспечение качества продукта – это не конечный процесс, с каждым новым релизом оно продолжается. Мы совершенствуем и исправляем продукт, подстраиваемся под новые реалии и запросы клиентов.

Получить 100% качества нельзя. Но можно добиться максимального качества с гибкой командой QA-специалистов, которая открыта для новых подходов и инструментов. А что думаете вы? Расскажите в комментариях.