В первой части (eсли не читали — вот она) я говорила о том, как быстро изучить проект, получить доступы и изучить документацию. Теперь переходим к следующему этапу — организации тестирования.
Порой всего просто слишком много и это вызывает хаос, в котором из вида теряются важные детали и появляется прокрастинация. Такие ситуации часто вызывают стресс и для того, чтобы этого избежать (или свести к минимуму) нужен план и понимание что, а главное для чего, нужно делать.
Что будет в этой статье:
Как составить тест-план и зачем он нужен
Как сравнить тестовую документацию и документацию разработки и найти ошибки в покрытии
Как правильно писать тест-кейсы и чек-листы
Как правильно писать баг-репорты
И главное: готовые промпты для ChatGPT, которые помогут сократить рутину
⚠️ Важно:
Все промпты в статье — не волшебные кнопки. Они не заменят вашего опыта и здравого смысла. Это инструменты, которые можно адаптировать под конкретную задачу и использовать как базу, с которой можно начать работу.
Тест-планы
Тест-план определяет, что тестируем, какие риски учитываем, какие тесты автоматизируем и как отслеживаем покрытие. Также он наглядно показывает другим участникам команды процесс тестирования и не дает превратиться тестированию в набор случайных проверок.
Шаблон тест-плана
Раздел | Описание |
1. Введение | Краткое описание проекта, основные цели, особенности тестирования |
2. Область тестирования | Какие модули покрываем, что исключаем |
3. Тестовая стратеги�� | Типы тестирования (функциональное, API, UI, нагрузочное) |
4. Окружения | Dev, Staging, Prod – их особенности и доступы |
5. Подход к автоматизации | Какие тесты автоматизируем, инструменты |
6. Баг-репорты | Как оформлять баги, где хранятся, как приоритизируются |
7. Риски и ограничения | Возможные проблемы, зависимости, ограничения тестирования |
Промпт для ChatGPT: генерация тест-плана
Ты — QA с опытом. На основе описания проекта составь короткий, но рабочий тест-план — без воды, пригодный для реального применения.
Описание проекта: (вставь текст и шаблон плана если нужно).
Что нужно:
Введение
Область покрытия
Стратегия
Окружения
Автоматизация
Риски и возможные баги
Вопросы к команде
Пиши по делу, как в рабочем чате, а не для аудита.
Не включай разделы, если они не актуальны — предложи, как их заменить.
Если проект сложный — предложи, как разбить тест-план на части.
Как найти расхождения между тестами и тех документацией
Из-за человеческого фактора и нехватки времени нередко упускаются важные детали в документации: старые фичи не обновлены, новые — не описаны. Поэтому перед тем, как начинать тестирование, полезно проверить насколько вообще совпадают описание и реальность.
Вот несколько вопросов, которые помогут это выяснить:
Все ли фичи покрыты? – Если в документации есть функциональность, но на нее нет тестов, это проблема.
Нет ли противоречий? – В документации одно, в тестах другое? Нужно разобраться.
Какие тесты пропущены? – Часто забывают про критичные сценарии и негативные кейсы.
Есть ли дубли? – Повторяющиеся тесты только увеличивают работу, но не дают пользы.
Промпт для ChatGPT: Сравнение тестовой документации с документацией разработки
Ты — QA с опытом. Сравни тестовую документацию с технической. Если документация большая — скажи, как её разбить для анализа.
Тестовая документация: (вставь)
Тех. документация: (вставь)
Что нужно сделать:
Проверь, где тесты соответствуют требованиям, а где — нет.
Найди, что упущено: нет кейсов на важные сценарии, нет негативных проверок и т.д.
Выяви дубли и бесполезные тесты.
Отметь, где документация противоречит сама себе или тестам.
Предложи, как улучшить покрытие.
Если что-то непонятно — зафиксируй вопросы к команде.
Составить список ответов по пунктам выше по каждому модулю/фиче
Тест-кейсы
Тест-кейсы хороши тем, что любой сможет воспроизвести его. При условии, что это хороший тест-кейс, конечно же.
Ключевые принципы хорошего тест-кейса
Структурированность и стандартизация – использовать единый шаблон, четко прописывать предусловия и шаги, разделять кейсы по функциональности и приоритетам.
Понятность и воспроизводимость – один тест-кейс = один сценарий, без двусмысленностей, с четким ожидаемым результатом, прикладывая при необходимости – скриншоты и ссылки на баги.
Обновляемость – регулярно обновлять и удалять устаревшие кейсы, чтобы сократить время на тестирование.
Тест-дизайн – применять техники (граничные значения, классы эквивалентности, попарное тестирование итд) для снижения числа тестов без потери качества.
Шаблон тест-кейса
Поле | Описание |
ID | Нумерация должна быть уникальной и логически привязанной к функциональности |
Название | Краткое и понятное описание тест-кейса |
Описание | Если тест-кейс краткий, описание можно опустить. Если сложный — добавьте контекст. |
Приоритет | High / Medium / Low |
Категория | Функциональное / Нефункциональное / UI / API |
Предусловия | Что нужно для выполнения теста (авторизация, тестовые данные и т. д.) |
Постусловие | Если нужно очистить систему после создания тестовых данных. |
Шаги | 1. Действие 1 2. Действие 2 3. Действие 3 |
Ожидаемый результат | Четкое описание ожидаемого поведения |
Промпт для ChatGPT для кейсов по тестированию API
Ты — QA с опытом в тестировании API. На основе API-документации составь набор тест-кейсов для тестирования. Кейсы должны быть в одном формате.
API-документация: (вставь сюда описание или ссылку)
Что нужно:
Позитивные и негативные кейсы.
Каждый кейс — самостоятельный, с предусловиями, шагами и результатом.
Шаги — в формате curl, с плейсхолдерами ({{user_id}}, {{token}}).
Указывай ожидаемый код ответа и пример JSON-ответа.
Уточняй постусловия, если нужно что-то удалить или сбросить.
Используй fillme_server как базовый адрес.
Формат для каждого кейса:
Название (можно добавить пример ваших названий, чтобы все было в одном формате)
Тип: позитивный / негативный
Приоритет
Предусловия
Шаги
Ожидаемый результат
Постусловия
Промпт для ChatGPT для кейсов по тестированию UI
Ты — QA с опытом в UI-тестировании. На основе документации составь набор тест-кейсов для тестирования. Учитывай как функциональность, так и визуальное поведение. Кейсы должны быть в одном формате.
Документация: (вставь текст, ссылку, описание или скрин)
Что нужно в кейсах:
Позитивные и негативные сценарии (валидные/невалидные данные, edge-кейсы).
Взаимодействие с UI-элементами: поля, кнопки, таблицы, ошибки и т.п.
Ожидаемые результаты — и поведение, и визуальная часть.
Учти адаптивность (мобильная/десктоп), кросс-браузерность, поведение при ошибках (например, сбой API).
Формат каждого кейса:
Название (можно добавить пример ваших названий, чтобы все было в одном формате)
Тип: позитивный / негативный
Приоритет
Предусловия
Шаги
Ожидаемый результат
Постусловия
Обычно мне достаточно этих запросов для чата, чтобы получить набор поверхностных неплохих проверок, проработать/улучшить их и использовать как основу для тестирования.
Иногда, чтобы кейсы были составлены подробнее и четче, имеет смысл просить генерировать кейсы не на несколько эндпоинтов/экранов сразу, а на каждый из необходимых отдельно.
Чек-листы
Иногда для быстрых проверок может быть достаточно чек-листа. Также чек-лист может быть полезен перед составлением тест-кейсов для визуализации некоторых сценариев и проверок.
Ключевые принципы хорошего чек-листа:
Простота и лаконичность – каждая проверка должна быть короткой и понятной.
Отсутствие лишних деталей – только ключевые шаги, без подробного описания.
Группировка по функциональности – логически разделять тесты на секции.
Фокус на критичные сценарии – чек-лист должен покрывать основные риски.
Использование утверждений – писать в формате "Система должна...", "Кнопка должна..."
Минимум технических деталей – чек-лист подходит для быстрого тестирования, а не для глубокой диагностики.
Обновляемость – чек-листы должны легко обновляться и дополняться.
Промпт для ChatGPT для составления чек-листа
Ты — QA с опытом. На основе документации составь лаконичный и удобный чек-лист для тестирования.
Документация: (вставь текст, ссылку или описание)
Что нужно:
Сгруппируй проверки по модулям или ролям (если подходит).
Делай отдельные блоки для позитивных и негативных сценариев.
Пиши коротко: одна строка = одна проверка.
Отмечай must-have для критичных проверок.
Если есть предусловия (например, нужно быть залогиненым) — укажи их перед блоком.
Если чего-то не хватает — в конце добавь список вопросов к команде.
Формат:
Модуль / роль
Позитивные проверки
Негативные проверки
(предусловия, если есть)
Вопросы к команде (если нужно)
Баг репорты
Не будь багов — не было бы и работы для QA. От того, как мы передадим пойманный баг повлияет на скорость и качество его починки. Так как можно найти кучу описаний хороших баг-репортов, я лишь добавлю краткие заметки и промпт для генерации репорта по шаблону.
Примеры разных типов багов и их влияние на продукт
Баги бывают разными, но все они мешают пользоваться продуктом.
Как фиксировать баги, которые воспроизводятся нестабильно?
Приложить видео (если баг редкий, показать его появление).
Собрать логи (консольные ошибки, network-запросы).
Проверить на другом устройстве/браузере.
Указать условия (Wi-Fi, слабый интернет, низкий заряд).
Шаблон баг-репорта
Поле | Описание |
Название | Кратко и по делу, например: "[Critical] Краш приложения при входе (Android 12)" |
Шаги воспроизведения | 1. Открыть приложение 2. Ввести данные пользователя 3. Нажать "Войти" 4. Приложение закрывается без ошибки |
Ожидаемый результат | Пользователь должен успешно войти в систему |
Фактический результат | Приложение вылетает без ошибки |
Окружение | ОС: Android 12 Браузер/приложение: Chrome 120.1 Сервер: Staging Дата/время обнаружения: 2025-03-16 14:30 |
Дополнительные материалы | Скриншоты / Видео (если баг UI) Логи (если есть ошибки в консоли) curl-запрос (если баг API) |
Промпт для ChatGPT для создания баг-репорта
Ты — опытный QA. Составь баг-репорт по описанию ошибки так, чтобы разработчику было просто воспроизвести баг и понять суть.
Описание ошибки: (вставь кейс и описание ошибки)
Что нужно в баг-репорте:
Заголовок — коротко: элемент, действие, результат.
Шаги воспроизведения — по пунктам, чётко.
Ожидаемый результат — как должно работать.
Фактический результат — что происходит на самом деле.
Окружение — браузер, ОС, устройство, версия приложения.
Дополнительно (если нужно): curl, скри��шоты, логи, ошибки из консоли.
So,
Хорошо выстроенная тестовая документация экономит время, снижает хаос и делает тестирование понятным. И чтобы это не занимало слишком много времени, нужно искать способы оптимизации этого процесса. Один из способов - использование искусственного интеллекта для рутинной работы.
Если вы уже этим пользуетесь — круто, если нет — время попробовать. В следующей части расскажу, как всё это превратить в автотесты.
