Как QA не утонуть в новом проекте. Часть 2: организация тестирования и документация

В первой части (eсли не читали — вот она ^[1]) я говорила о том, как быстро изучить проект, получить доступы и изучить документацию. Теперь переходим к следующему этапу — организации тестирования.

Порой всего просто слишком много и это вызывает хаос, в котором из вида теряются важные детали и появляется прокрастинация. Такие ситуации часто вызывают стресс ^[2] и для того, чтобы этого избежать (или свести к минимуму) нужен план и понимание что, а главное для чего, нужно делать.

Что будет в этой статье:

• Как составить тест-план и зачем он нужен

• Как сравнить тестовую документацию и документацию разработки и найти ошибки ^[3] в покрытии

• Как правильно писать тест-кейсы и чек-листы

• Как правильно писать баг-репорты

• И главное: готовые промпты для ChatGPT, которые помогут сократить рутину

⚠️ Важно:
Все промпты в статье — не волшебные кнопки. Они не заменят вашего опыта ^[4] и здравого смысла. Это инструменты, которые можно адаптировать под конкретную задачу и использовать как базу, с которой можно начать работу.

Тест-планы

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

Шаблон тест-плана

Как найти расхождения между тестами и тех документацией

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

Вот несколько вопросов, которые помогут это выяснить:

• Все ли фичи покрыты? – Если в документации есть функциональность, но на нее нет тестов, это проблема.

• Нет ли противоречий? – В документации одно, в тестах другое? Нужно разобраться.

• Какие тесты пропущены? – Часто забывают ^[5] про критичные сценарии и негативные кейсы.

• Есть ли дубли? – Повторяющиеся тесты только увеличивают работу, но не дают пользы.

Тест-кейсы

Тест-кейсы хороши тем, что любой сможет воспроизвести его. При условии, что это хороший тест-кейс, конечно же. 

Ключевые принципы хорошего тест-кейса

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

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

• Обновляемость – регулярно обновлять и удалять устаревшие кейсы, чтобы сократить время на тестирование.

• Тест-дизайн – применять техники (граничные значения, классы эквивалентности, попарное тестирование итд) для снижения числа тестов без потери качества.

Шаблон тест-кейса

Обычно мне достаточно этих запросов для чата, чтобы получить набор поверхностных неплохих проверок, проработать/улучшить их и использовать как основу для тестирования. 

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

Чек-листы

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

Ключевые принципы хорошего чек-листа:

• Простота и лаконичность – каждая проверка должна быть короткой и понятной.

• Отсутствие лишних деталей – только ключевые шаги, без подробного описания.

• Группировка по функциональности – логически разделять тесты на секции.

• Фокус на критичные сценарии – чек-лист должен покрывать основные риски.

• Использование утверждений – писать в формате “Система должна…”, “Кнопка должна…”

• Минимум технических деталей – чек-лист подходит для быстрого тестирования, а не для глубокой диагностики.

• Обновляемость – чек-листы должны легко обновляться и дополняться.

Баг репорты

Не будь багов — не было бы и работы для QA, так что от того, как мы передадим пойманный баг повлияет на скорость и качество его починки. Так как можно найти кучу описаний хороших баг-репортов, я лишь добавлю краткие заметки и промпт для генерации репорта по шаблону.

Примеры разных типов багов и их влияние на продукт

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

Как фиксировать баги, которые воспроизводятся нестабильно?

• Приложить видео (если баг редкий, показать его появление).

• Собрать логи (консольные ошибки, network-запросы).

• Проверить на другом устройстве/браузере.

• Указать условия (Wi-Fi, слабый интернет, низкий заряд).

Шаблон баг-репорта

So,

Хорошо выстроенная тестовая документация экономит время, снижает хаос и делает тестирование понятным. И чтобы это не занимало слишком много времени, нужно искать способы оптимизации этого процесса. Один из способов – использование искусственного интеллекта ^[8] для рутинной работы.

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