Процесс тестирования с нуля: этапы и что делать одному тестировщику

С чего начать на новом проекте

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

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

• Команда

  Кто бизнес-аналитик, кто менеджер проекта, кто владелец продукта (product owner), есть ли другие тестировщики и за что отвечает каждый.

• Требования

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

• Тестовая документация

  Что уже написано и где лежит: в таблицах, в системе управления тестированием (TMS) или нигде. Если проект давно идёт, артефактов может оказаться много.

• Доступы

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

• Процесс в трекере

  Попросите скрам-мастера или менеджера провести экскурсию по Jira или другому трекеру: какие есть статусы и как задача идёт от создания до закрытия.

• Знакомство с продуктом

  Когда доступы получены, продукт проходят руками. Если тестовая документация есть, по ней, если нет, исследовательским тестированием.

• Цели и сроки

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

• СтатьяТестирование требований: как с ними работать

Этапы процесса тестирования

Я строю процесс по тем же фазам, что и жизненный цикл тестирования (STLC): анализ требований, планирование, разработка тестовой документации, подготовка окружений, выполнение тестов и закрытие. В программе ISTQB Foundation Level процесс тестирования тоже разбит на группы активностей: планирование, мониторинг и контроль, анализ тестирования, проектирование тестов, реализация, выполнение и завершение тестирования. Этот список одинаков в версиях программы 2018 и 2023 года.

Первым делом узнают методологию разработки, потому что процесс в водопадной модели устроен иначе, чем в Scrum, а Scrum отличается от Kanban. На практике фазы редко идут строго друг за другом, их совмещают. После первого плана цикл повторяется на каждой итерации: анализ новых требований, документация, тестирование и отчёт.

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

• Изучение текущего состояния

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

• Планирование

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

• Документация и тестирование

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

• Отчётность

  Отчёт о результатах тестирования в конце итерации и метрики в динамике. По нему решают, готов ли продукт к релизу.

• Закрытие

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

• СтатьяМодели разработки ПО, SDLC и STLC
• СтатьяAgile, Scrum и Kanban для тестировщика

Тест-план, workflow и договорённости

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

Метрики выбирают под проект. Например, число критических багов на фоне общего числа найденных, чтобы видеть динамику, или распределение багов по функциональности. Отдельно договариваются о работе с багами: кто их заводит, кто назначает исполнителя и ставит приоритет, что считать critical и что minor. Договорённости в переписке лучше фиксировать письменно, лучше всего баг-репортом в трекере.

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

• Ожидает разработки

  Задача в бэклоге. Тестировщик в это время анализирует требования и задаёт по ним вопросы.

• В разработке и на код-ревью

  Разработчик пишет код, коллеги его проверяют. Тестировщик готовит тест-кейсы и дополняет регрессионные наборы.

• Готово к тестированию

  Задача ждёт тестировщика в очереди.

• В тестировании

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

• Закрыто или на согласовании

  Если всё в порядке, задачу закрывают или отправляют на дополнительное согласование владельцу продукта или аналитику.

• СтатьяТест-план и тестовая стратегия
• СтатьяТестовые окружения: Local, Dev, Stage, Prod

Документация, регресс и обязательные проверки

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

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

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

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

Минимум проверок, который, на мой взгляд, нужен на любом проекте, такой.

• Смоук

  Решает, можно ли тестировать сборку дальше. Если сборка разваливается, тестирование останавливают.

• Тестирование новой функциональности

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

• Ретест

  Подтверждает, что исправленный дефект действительно исправлен.

• Регресс

  Проверяет, что изменения не сломали то, что работало раньше.

• Нефункциональное тестирование

  Производительность, локализация, удобство использования и другое, если этого требуют проект и заказчик.

• СтатьяРегрессионное и смоук-тестирование: в чём разница
• СтатьяЧек-лист и тест-кейс: что выбрать на проекте

Если вы один тестировщик на проекте

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

У такой работы есть и плюсы: процесс и инструменты можно выбрать под себя, а менеджерские навыки растут быстрее. Я сам на первой работе был единственным тестировщиком, дал себе на неё год, потому что чувствовал, что перестаю расти, а второй тестировщик появился только через полгода. Хорошо устроенный отдел тестирования, по-моему, начинает тестирование как можно раньше, ещё на этапе требований (shift left), у тестировщиков есть менеджер и наставник, а время на тестирование учитывают при оценке задач. Один тестировщик на десять разработчиков для меня перекос, а на двух-трёх нормальная пропорция, хотя многое решают автоматизация и юнит-тесты.

Если вы всё же один, на старте помогает следующее.

• Опираться на команду

  Разработчики знают, как реализована функциональность и как сервисы общаются между собой, а аналитик знает, как продукт должен работать. Мне продукт на первой работе объясняли именно аналитики. Стеснительность я считаю худшим, что может помешать разобраться в продукте.

• Искать требования вокруг продукта

  Если команда делает мессенджер, многое подскажут уже существующие мессенджеры. Для мобильного приложения есть гайдлайны магазинов приложений, и по ним приложение проверяют перед публикацией в App Store и Google Play.

• Изучить продукт руками

  Готовый продукт проходят исследовательским тестированием и раскладывают на модули. У интернет-магазина это регистрация, вход, сброс пароля, корзина и избранное.

• Начать с чек-листов

  Их быстрее написать и легче поддерживать. К тест-кейсам переходят, когда функциональности становится больше или появляется второй тестировщик: по кейсам удобно учить тех, кто придёт следом.

• Выбирать инструменты вместе с руководителем

  Если просят выбрать систему для хранения кейсов или баг-трекер, сравните варианты по функциям и цене и обсудите с руководителем бюджет и цели. Пока денег нет, кейсы ведут в Excel или Google Таблицах.

• Искать опыт снаружи

  Спрашивать тестировщиков с других проектов компании, читать статьи и разбирать, как процесс устроен у других.

• СтатьяСобеседование тестировщика: что спросить у компании
• СтатьяСистемы управления тестированием и баг-трекеры

Видеоуроки, шпаргалки и задания

Построение процесса я разбираю в ролике "Как построить процесс тестирования с нуля?" на YouTube. Подробнее те же этапы я раскрываю в докладе об организации процесса тестирования, отдельный ролик посвящён работе единственным тестировщиком, а в коротком ответе подписчику описан идеальный, на мой взгляд, отдел тестирования. В бесплатном базовом курсе по тестированию теме посвящён урок о настройке QA-процесса с нуля.

Шпаргалки по тест-плану и отчёту о тестировании разбирают оба документа по частям, шпаргалка по матрице трассировки показывает, как требования связывают с тестами, а в тренажёре нужно найти в такой матрице непокрытые требования и лишние тесты.

• Урок курсаЭтот урок – бесплатно
• Мой видеоуроккак построить процесс тестирования с нуля
• Мой видеоурокорганизация процесса тестирования на пальцах
• Мой видеоурокчто делать, когда вы один тестировщик на проекте
• Мой видеоурокидеальный отдел тестирования
• Шпаргалкатест-план
• Шпаргалкаотчёт о тестировании
• Шпаргалкаматрица трассировки и метрики покрытия
• ШпаргалкаSDLC и STLC
• Тренажёрматрица трассировки
• СтатьяТест-план и тестовая стратегия

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы