Введение в документацию тестирования пользовательских историй
Документация тестирования пользовательских историй служит критически важным мостом между требованиями продукта и обеспечением качества. В Agile-среде разработки, где пользовательские истории являются основным средством фиксации функциональности, правильная документация тестирования гарантирует выполнение критериев приемки, корректную валидацию функций и последовательное достижение Definition of Done (DoD).
Это всеобъемлющее руководство исследует основные компоненты документации тестирования пользовательских историй, от написания проверяемых критериев приемки до реализации форматов BDD, поддержания трассируемости и валидации по DoD.
Понимание пользовательских историй в контексте тестирования
Пользовательская история представляет функцию или требование с точки зрения конечного пользователя, обычно следуя формату:
Как [тип пользователя]
Я хочу [действие или функцию]
Чтобы [получить выгоду или ценность]
Пример:
Как зарегистрированный клиент
Я хочу сохранять товары в список желаний
Чтобы я мог купить их позже без повторного поиска
Для целей тестирования пользовательские истории должны сопровождаться четкими, измеримыми критериями приемки, которые определяют, когда история считается завершенной и работающей по назначению.
Написание проверяемых критериев приемки
Критерии приемки - это условия, которым должен удовлетворять программный продукт, чтобы быть принятым заинтересованными сторонами. Хорошо написанные критерии приемки необходимы для создания эффективной документации тестирования.
Фреймворк SMART-критериев
Критерии приемки должны быть:
- Конкретными (Specific): Четко определенными, без двусмысленности
- Измеримыми (Measurable): Можно проверить с помощью тестирования
- Достижимыми (Achievable): Реалистичными с учетом технических ограничений
- Релевантными (Relevant): Напрямую связанными с пользовательской историей
- Ограниченными по времени (Time-bound): Можно протестировать в рамках спринта
Форматы критериев приемки
Формат 1: На основе сценариев (Дано-Когда-Тогда)
Дано я являюсь авторизованным клиентом
Когда я нажимаю кнопку "Добавить в список желаний" на странице продукта
Тогда товар должен быть добавлен в мой список желаний
И должно появиться сообщение с подтверждением
И счетчик списка желаний должен увеличиться на 1
Формат 2: На основе чек-листа
- Пользователь может добавлять товары в список желаний со страницы детального описания продукта
- Пользователь может добавлять товары в список желаний из результатов поиска
- Иконка списка желаний отображает текущее количество товаров
- Максимум 100 товаров разрешено в списке желаний
- Дублирующиеся товары не добавляются (вместо этого показывается предупреждение)
- Список желаний сохраняется между сеансами
Формат 3: На основе правил
Бизнес-правило: Управление списком желаний
- ЕСЛИ пользователь не авторизован, ТО показать запрос на вход при добавлении в список желаний
- ЕСЛИ товар уже в списке желаний, ТО показать сообщение "Уже в списке желаний"
- ЕСЛИ в списке желаний 100 товаров, ТО отключить кнопку "Добавить в список желаний"
- ЕСЛИ товар не в наличии, ТО все равно разрешить добавление в список желаний
Пример: Полные критерии приемки
Пользовательская история: Как зарегистрированный клиент, я хочу сохранять товары в список желаний, чтобы я мог купить их позже без повторного поиска.
Критерии приемки:
Сценарий 1: Добавление товара в список желаний со страницы продукта
Дано я авторизован как зарегистрированный клиент
И я просматриваю страницу детального описания продукта
И продукт еще не в моем списке желаний
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда продукт должен быть добавлен в мой список желаний
И я должен увидеть сообщение об успехе "Товар добавлен в ваш список желаний"
И счетчик иконки списка желаний должен увеличиться на 1
Сценарий 2: Предотвращение дублирующихся товаров в списке желаний
Дано я авторизован как зарегистрированный клиент
И у меня есть продукт "ABC123" в списке желаний
Когда я пытаюсь добавить продукт "ABC123" в список желаний снова
Тогда продукт не должен быть добавлен
И я должен увидеть сообщение "Этот товар уже в вашем списке желаний"
Сценарий 3: Ограничение емкости списка желаний
Дано я авторизован как зарегистрированный клиент
И мой список желаний содержит 100 товаров
Когда я пытаюсь добавить еще один товар в список желаний
Тогда товар не должен быть добавлен
И я должен увидеть сообщение "Список желаний заполнен. Максимум 100 товаров разрешено."
Сценарий 4: Доступ неавторизованного пользователя
Дано я не авторизован
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда я должен быть перенаправлен на страницу входа
И после успешного входа товар должен быть добавлен в мой список желаний
Создание тестовых сценариев из пользовательских историй
Тестовые сценарии переводят критерии приемки в конкретные тестовые случаи, которые могут выполнять QA-инженеры. Каждый сценарий должен охватывать специфические условия и ожидаемые результаты.
Структура тестового сценария
Полноценный тестовый сценарий включает:
- ID тестового сценария: Уникальный идентификатор
- Ссылка на пользовательскую историю: Ссылка на оригинальную историю
- Цель теста: Какой аспект тестируется
- Предусловия: Состояние системы до тестирования
- Шаги теста: Детальные действия для выполнения
- Ожидаемые результаты: Что должно произойти
- Постусловия: Состояние системы после тестирования
- Приоритет: Критический, Высокий, Средний, Низкий
- Тестовые данные: Необходимые специфические данные
Пример документации тестового сценария
## Тестовый сценарий TS-WISH-001: Добавление продукта в список желаний
**Пользовательская история:** US-2024-156 - Функциональность списка желаний
**Приоритет:** Высокий
**Тип:** Функциональный
### Предусловия
- Существует учетная запись пользователя (email: test.user@example.com, пароль: Test@123)
- Пользователь авторизован
- Каталог продуктов содержит тестовый продукт (SKU: PROD-001)
- Список желаний пользователя пуст
### Шаги теста
1. Перейти на главную страницу (https://example.com)
2. Найти продукт с SKU "PROD-001"
3. Нажать на продукт, чтобы открыть страницу детального описания
4. Найти кнопку "Добавить в список желаний" (иконка сердца)
5. Нажать кнопку "Добавить в список желаний"
6. Наблюдать сообщение с подтверждением
7. Перейти на страницу списка желаний
8. Проверить, что продукт появляется в списке желаний
### Ожидаемые результаты
- Шаг 5: Кнопка должна быть кликабельна и реагировать на клик
- Шаг 6: Появляется сообщение об успехе: "Товар добавлен в ваш список желаний"
- Шаг 6: Иконка счетчика списка желаний обновляется с "0" на "1"
- Шаг 8: Продукт "PROD-001" появляется в списке желаний с правильными деталями (название, цена, изображение)
- Шаг 8: Список желаний показывает "1 товар"
### Постусловия
- Список желаний содержит ровно 1 товар
- Запись в базе данных создана в таблице `user_wishlists`
- Пользователь остается авторизованным
### Тестовые данные
| Поле | Значение |
|------|----------|
| Имя пользователя | test.user@example.com |
| Пароль | Test@123 |
| SKU продукта | PROD-001 |
| Название продукта | Премиум беспроводные наушники |
| Цена продукта | $199.99 |
Формат разработки через поведение (BDD)
BDD устраняет разрыв между бизнес-заинтересованными сторонами и техническими командами, используя общий язык для описания поведения системы. Синтаксис Gherkin - наиболее широко используемый формат BDD.
Компоненты синтаксиса Gherkin
Ключевые слова:
Feature
: Высокоуровневое описание программной функцииScenario
: Конкретный пример бизнес-правилаGiven
: Предусловие или контекстWhen
: Событие или действиеThen
: Ожидаемый результатAnd/But
: Дополнительные шагиBackground
: Общие предусловия для всех сценариевScenario Outline
: Шаблон с несколькими примерами
Полный пример BDD-файла функции
Feature: Управление списком желаний
Как зарегистрированный клиент
Я хочу управлять списком желаний продуктов
Чтобы я мог сохранять товары для будущей покупки
Background:
Дано существуют следующие пользователи:
| email | password | статус |
| customer@example.com | Pass@123 | активный |
И существуют следующие продукты:
| sku | название | цена | склад |
| PROD-001 | Беспроводные наушники | 199.99 | 50 |
| PROD-002 | Bluetooth-колонка | 89.99 | 0 |
| PROD-003 | USB-C кабель | 12.99 | 200 |
Scenario: Успешное добавление товара в наличии в список желаний
Дано я авторизован как "customer@example.com"
И я нахожусь на странице детального описания продукта для "PROD-001"
И мой список желаний пуст
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда продукт "PROD-001" должен быть добавлен в мой список желаний
И я должен увидеть уведомление об успехе "Товар добавлен в ваш список желаний"
И счетчик списка желаний должен отображать "1"
И кнопка "Добавить в список желаний" должна измениться на "В списке желаний"
Scenario: Добавление товара не в наличии в список желаний
Дано я авторизован как "customer@example.com"
И я нахожусь на странице детального описания продукта для "PROD-002"
И у продукта "PROD-002" 0 на складе
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда продукт "PROD-002" должен быть добавлен в мой список желаний
И я должен увидеть уведомление об успехе "Товар добавлен в ваш список желаний"
И я должен увидеть значок "Нет в наличии" на элементе списка желаний
Scenario: Предотвращение дублирующихся товаров в списке желаний
Дано я авторизован как "customer@example.com"
И мой список желаний содержит следующие продукты:
| sku |
| PROD-001 |
Когда я перехожу на страницу детального описания продукта для "PROD-001"
И я нажимаю кнопку "Добавить в список желаний"
Тогда я должен увидеть предупреждающее уведомление "Этот товар уже в вашем списке желаний"
И список желаний должен по-прежнему содержать 1 товар
И счетчик списка желаний должен отображать "1"
Scenario Outline: Валидация емкости списка желаний
Дано я авторизован как "customer@example.com"
И мой список желаний содержит <текущих_товаров> товаров
Когда я пытаюсь добавить новый продукт в список желаний
Тогда операция должна быть <результат>
И я должен увидеть сообщение "<сообщение>"
Examples:
| текущих_товаров | результат | сообщение |
| 99 | успех | Товар добавлен в ваш список желаний |
| 100 | неудача | Список желаний заполнен. Максимум 100 товаров разрешено. |
| 50 | успех | Товар добавлен в ваш список желаний |
Scenario: Неавторизованный пользователь пытается добавить в список желаний
Дано я не авторизован
И я нахожусь на странице детального описания продукта для "PROD-001"
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда я должен быть перенаправлен на страницу входа
И я должен увидеть сообщение "Пожалуйста, войдите, чтобы добавлять товары в список желаний"
И URL страницы детального описания продукта должен быть сохранен для перенаправления после входа
Scenario: Успешное перенаправление после входа с действием списка желаний
Дано я не авторизован
И я нахожусь на странице детального описания продукта для "PROD-001"
И я нажал кнопку "Добавить в список желаний"
И я был перенаправлен на страницу входа
Когда я вхожу с email "customer@example.com" и паролем "Pass@123"
Тогда я должен быть перенаправлен обратно на страницу детального описания продукта для "PROD-001"
И продукт "PROD-001" должен быть автоматически добавлен в мой список желаний
И я должен увидеть уведомление об успехе "Товар добавлен в ваш список желаний"
Определения шагов BDD (пример на JavaScript/Cucumber)
const { Given, When, Then } = require('@cucumber/cucumber');
const { expect } = require('chai');
Given('я авторизован как {string}', async function (email) {
await this.loginPage.open();
await this.loginPage.login(email, 'Pass@123');
const isLoggedIn = await this.navigation.isUserLoggedIn();
expect(isLoggedIn).to.be.true;
});
Given('я нахожусь на странице детального описания продукта для {string}', async function (sku) {
await this.productPage.openProductBySKU(sku);
const displayedSKU = await this.productPage.getProductSKU();
expect(displayedSKU).to.equal(sku);
});
Given('мой список желаний пуст', async function () {
await this.wishlistAPI.clearWishlist(this.currentUser.id);
const itemCount = await this.wishlistPage.getItemCount();
expect(itemCount).to.equal(0);
});
When('я нажимаю кнопку {string}', async function (buttonText) {
await this.productPage.clickButton(buttonText);
});
Then('продукт {string} должен быть добавлен в мой список желаний', async function (sku) {
const wishlistItems = await this.wishlistAPI.getWishlistItems(this.currentUser.id);
const productInWishlist = wishlistItems.find(item => item.sku === sku);
expect(productInWishlist).to.exist;
});
Then('я должен увидеть уведомление об успехе {string}', async function (message) {
const notification = await this.notification.getMessage();
expect(notification).to.equal(message);
});
Поддержание трассируемости требований
Трассируемость обеспечивает тестирование каждого требования и связь каждого теста с требованием. Эта двунаправленная связь критически важна для соответствия нормам, анализа покрытия и оценки влияния.
Структура матрицы трассируемости
Матрица трассируемости требований (RTM) связывает требования с тестовыми случаями, обеспечивая полное покрытие.
Пример RTM:
ID требования | Пользовательская история | ID критерия приемки | ID тестового сценария | ID тестового случая | Статус | Приоритет | Назначено на |
---|---|---|---|---|---|---|---|
REQ-WISH-001 | US-2024-156 | AC-WISH-001 | TS-WISH-001 | TC-WISH-001-01 | Pass | Высокий | J. Smith |
REQ-WISH-001 | US-2024-156 | AC-WISH-001 | TS-WISH-001 | TC-WISH-001-02 | Pass | Высокий | J. Smith |
REQ-WISH-002 | US-2024-156 | AC-WISH-002 | TS-WISH-002 | TC-WISH-002-01 | Pass | Высокий | A. Jones |
REQ-WISH-003 | US-2024-156 | AC-WISH-003 | TS-WISH-003 | TC-WISH-003-01 | Fail | Средний | M. Lee |
REQ-WISH-004 | US-2024-156 | AC-WISH-004 | TS-WISH-004 | TC-WISH-004-01 | Pass | Низкий | K. Chen |
Реализация трассируемости в коде
Использование тегов в BDD:
@REQ-WISH-001 @US-2024-156 @приоритет:высокий @регрессия
Scenario: Успешное добавление товара в наличии в список желаний
Дано я авторизован как "customer@example.com"
Когда я нажимаю кнопку "Добавить в список желаний"
Тогда продукт должен быть добавлен в мой список желаний
Трассируемость в инструментах управления тестированием:
Большинство платформ управления тестированием (TestRail, Zephyr, qTest) поддерживают пользовательские поля для трассируемости:
{
"test_case_id": "TC-WISH-001-01",
"title": "Добавить продукт в список желаний - Позитивный сценарий",
"requirement_id": "REQ-WISH-001",
"user_story_id": "US-2024-156",
"acceptance_criteria_id": "AC-WISH-001",
"priority": "Высокий",
"automated": true,
"automation_id": "wishlist.feature:15"
}
Анализ покрытия
Рассчитать покрытие тестами, чтобы убедиться, что все требования валидированы:
Покрытие % = (Количество требований с тестовыми случаями / Всего требований) × 100
Пример отчета о покрытии:
Категория | Всего | Покрыто | Не покрыто | Покрытие % |
---|---|---|---|---|
Функциональные требования | 45 | 43 | 2 | 95.6% |
Нефункциональные требования | 12 | 10 | 2 | 83.3% |
Бизнес-правила | 8 | 8 | 0 | 100% |
Итого | 65 | 61 | 4 | 93.8% |
Валидация Definition of Done (DoD)
Definition of Done - это общее понимание того, что означает “завершено” для пользовательской истории. Документация тестирования должна валидировать выполнение всех критериев DoD перед приемкой истории.
Пример чек-листа DoD
## Definition of Done - Пользовательская история US-2024-156
### Качество кода
- [ ] Код проверен как минимум 2 членами команды
- [ ] Нет критических или высокоприоритетных нарушений SonarQube
- [ ] Покрытие кода ≥ 80% для нового кода
- [ ] Все предупреждения компилятора решены
### Тестирование
- [ ] Все критерии приемки имеют соответствующие тестовые случаи
- [ ] Юнит-тесты написаны и проходят (12/12 пройдено)
- [ ] Интеграционные тесты написаны и проходят (5/5 пройдено)
- [ ] Регрессионные тесты выполнены и проходят (Все пройдено)
- [ ] Исследовательское тестирование завершено (2 часа)
- [ ] Нет открытых критических или высокоприоритетных дефектов
### Документация
- [ ] Документация API обновлена (если применимо)
- [ ] Пользовательская документация обновлена
- [ ] Тестовые случаи задокументированы в TestRail
- [ ] Запись в примечаниях к релизу создана
### Нефункциональные требования
- [ ] Требования к производительности выполнены (загрузка страницы < 2с)
- [ ] Стандарты доступности выполнены (WCAG 2.1 Уровень AA)
- [ ] Сканирование безопасности завершено без высокорискованных находок
- [ ] Кросс-браузерное тестирование завершено (Chrome, Firefox, Safari, Edge)
- [ ] Адаптивный дизайн для мобильных устройств проверен
### Развертывание
- [ ] Feature flag настроен (если применимо)
- [ ] Миграции базы данных протестированы
- [ ] Развернуто в staging-среде
- [ ] Smoke-тесты пройдены в staging
- [ ] Получена приемка от Product Owner
**Валидировано:** Jane Smith, QA Lead
**Дата:** 2025-10-08
**Статус:** ✅ ГОТОВО
Шаблон отчета о валидации DoD
# Отчет о валидации DoD
**Пользовательская история:** US-2024-156 - Функциональность списка желаний
**Спринт:** Спринт 24
**Дата валидации:** 2025-10-08
**QA-инженер:** Jane Smith
## Резюме
Все критерии Definition of Done выполнены. Пользовательская история готова к развертыванию в продакшн.
## Детальные результаты валидации
### 1. Функциональное тестирование
| Критерий | Статус | Доказательство | Примечания |
|----------|--------|----------------|------------|
| Все критерии приемки протестированы | ✅ Pass | TestRail Suite ID: 2456 | 15/15 тестовых случаев пройдено |
| Граничные случаи покрыты | ✅ Pass | Тестовые сценарии: TS-WISH-001 до TS-WISH-008 | Включая граничные условия |
| Обработка ошибок валидирована | ✅ Pass | Негативные тестовые случаи: 8/8 пройдено | Все сообщения об ошибках проверены |
### 2. Покрытие автоматизации
| Критерий | Статус | Доказательство | Примечания |
|----------|--------|----------------|------------|
| Автоматизированные тесты созданы | ✅ Pass | Cucumber-сценарии: 12 | Все сценарии автоматизированы |
| CI/CD пайплайн проходит | ✅ Pass | Jenkins Build #456 | Все этапы зеленые |
| Автоматизированные тесты в регрессионном наборе | ✅ Pass | Добавлены в regression-wishlist.feature | Помечены тегом @регрессия |
### 3. Валидация производительности
| Метрика | Цель | Фактически | Статус |
|---------|------|------------|--------|
| Время отклика API | < 500мс | 234мс | ✅ Pass |
| Время загрузки страницы | < 2с | 1.6с | ✅ Pass |
| Поддерживаемые одновременные пользователи | 1000 | 1200 | ✅ Pass |
### 4. Тестирование безопасности
- ✅ Чек-лист OWASP Top 10 завершен
- ✅ Валидация ввода проверена
- ✅ Тестирование SQL-инъекций пройдено
- ✅ Тестирование уязвимостей XSS пройдено
- ✅ Аутентификация/авторизация проверена
### 5. Документация
- ✅ Тестовые случаи задокументированы: TestRail Проект WISH
- ✅ Результаты выполнения тестов зафиксированы
- ✅ Дефекты зарегистрированы и решены: 3 дефекта найдено и исправлено
- ✅ Матрица трассируемости обновлена
## Подпись
- QA Lead: Jane Smith - Утверждено ✅
- Product Owner: Mike Johnson - Принято ✅
- Дата: 2025-10-08
Лучшие практики для документации тестирования пользовательских историй
1. Сотрудничайте рано и часто
- Вовлекайте QA в сессии уточнения историй
- Проверяйте критерии приемки до планирования спринта
- Проводите сессии “Три амиго” (Разработчик, Тестировщик, Product Owner)
2. Поддерживайте живую и доступную документацию
- Храните документацию тестирования в системе контроля версий
- Используйте инструменты для совместной работы (Confluence, Notion)
- Обновляйте документацию по мере развития требований
3. Автоматизируйте где возможно
- Конвертируйте ручные тестовые сценарии в автоматизированные тесты
- Используйте BDD-фреймворки для исполняемых спецификаций
- Интегрируйте с CI/CD пайплайнами
4. Поддерживайте четкую трассируемость
- Используйте согласованные соглашения по ID
- Связывайте требования с тестовыми случаями двунаправленно
- Регулярно генерируйте отчеты о трассируемости
5. Валидируйте против DoD непрерывно
- Не ждите конца спринта
- Создавайте чек-листы DoD в вашем инструменте управления задачами
- Проверяйте статус DoD на ежедневных stand-up
Инструменты для документации тестирования пользовательских историй
Категория инструмента | Инструменты | Назначение |
---|---|---|
BDD-фреймворки | Cucumber, SpecFlow, Behave | Исполняемые спецификации |
Управление тестированием | TestRail, Zephyr, qTest, PractiTest | Управление тестовыми случаями, трассируемость |
Совместная работа | Jira, Azure DevOps, Rally | Управление пользовательскими историями |
Документация | Confluence, Notion, SharePoint | Централизованная документация |
Автоматизация | Selenium, Cypress, Playwright | Выполнение тестов |
Отчетность | Allure, ExtentReports, ReportPortal | Визуализация результатов тестирования |
Заключение
Эффективная документация тестирования пользовательских историй - это основа качественной поставки программного обеспечения в Agile-среде. Написание проверяемых критериев приемки, создание полноценных тестовых сценариев, использование форматов BDD, поддержание трассируемости и валидация против Definition of Done гарантируют, что пользовательские истории реализованы правильно и полностью.
Ключ к успеху - это сотрудничество, ясность и непрерывное улучшение. Вовлекайте всех заинтересованных сторон в процесс документирования, поддерживайте четкие и исполняемые спецификации, регулярно пересматривайте и совершенствуйте ваши практики на основе извлеченных уроков.
Помните: документация тестирования - это не только о записи того, что тестировать - это о создании общего понимания ожидаемого поведения, обеспечении качества и укреплении уверенности в ваших релизах программного обеспечения.