Зачем нужны стандарты
Без стандартов: пять тестировщиков пишут баг-репорты в пяти форматах, критическая информация теряется, время уходит на уточнения при ревью.
Создание шаблонов
Принципы проектирования
- Включайте подсказки, а не только заголовки
- Отмечайте обязательные vs опциональные разделы
- Приводите примеры
- Сохраняйте минимализм
- Версионируйте шаблоны в wiki или репозитории
Основные шаблоны
- Баг-репорт: Заголовок (формула), окружение, серьёзность, шаги, ожидаемый/фактический, доказательства
- Тест-кейс: ID, заголовок (Проверить, что…), предусловия, шаги с результатами, тестовые данные
- Итоговый отчёт: Резюме, область, результаты, дефекты, покрытие, риски, go/no-go
Что стандартизировать
| Область | Стандарт |
|---|---|
| Заголовки багов | Формула: [Компонент] Действие падает с [Ошибкой] при [Условии] |
| Шкала серьёзности | 4 уровня с определениями |
| Именование тест-кейсов | TC-[МОДУЛЬ]-[NNN] |
| Скриншоты | Аннотированные с выделениями и стрелками |
| Тестовые данные | Никогда реальные PII, использовать Faker |
Что НЕ стандартизировать
Стиль написания, уровень детализации для опытных тестировщиков, количество слов.
Упражнение: Создайте руководство по стандартам
Создайте одностраничное руководство «Стандарты QA-документации» для команды из 8 человек.
Решение
Шаблоны: Баг-репорт (формула заголовка, обязательные поля), Тест-кейс (ID, заголовок, шаги), Итоговый отчёт (резюме, go/no-go).
Именование: TC-[AUTH/CART/PAY]-[001-999], TP-[Проект]-v[X.Y], TR-[Спринт]-[дата].
Ревью: Баг-репорты без обязательного ревью. Критические тест-кейсы — peer review. Тест-планы — одобрение QA Lead.
Хранение: Центральная wiki, тест-кейсы в Zephyr, баги в Jira, ежеквартальный пересмотр.
Ключевые выводы
- Шаблоны обеспечивают единообразие — включайте подсказки, а не пустые заголовки
- Стандартизируйте важное (форматы, обязательные поля, именование), но не стиль
- Храните централизованно в wiki или репозитории
- Пересматривайте стандарты ежеквартально по обратной связи команды
- Балансируйте стандартизацию с гибкостью