Введение в документацию тестирования пользовательских историй

Документация тестирования пользовательских историй служит критически важным мостом между требованиями продукта и обеспечением качества. В 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-инженеры. Каждый сценарий должен охватывать специфические условия и ожидаемые результаты.

Структура тестового сценария

Полноценный тестовый сценарий включает:

  1. ID тестового сценария: Уникальный идентификатор
  2. Ссылка на пользовательскую историю: Ссылка на оригинальную историю
  3. Цель теста: Какой аспект тестируется
  4. Предусловия: Состояние системы до тестирования
  5. Шаги теста: Детальные действия для выполнения
  6. Ожидаемые результаты: Что должно произойти
  7. Постусловия: Состояние системы после тестирования
  8. Приоритет: Критический, Высокий, Средний, Низкий
  9. Тестовые данные: Необходимые специфические данные

Пример документации тестового сценария

## Тестовый сценарий 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-001US-2024-156AC-WISH-001TS-WISH-001TC-WISH-001-01PassВысокийJ. Smith
REQ-WISH-001US-2024-156AC-WISH-001TS-WISH-001TC-WISH-001-02PassВысокийJ. Smith
REQ-WISH-002US-2024-156AC-WISH-002TS-WISH-002TC-WISH-002-01PassВысокийA. Jones
REQ-WISH-003US-2024-156AC-WISH-003TS-WISH-003TC-WISH-003-01FailСреднийM. Lee
REQ-WISH-004US-2024-156AC-WISH-004TS-WISH-004TC-WISH-004-01PassНизкий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

Пример отчета о покрытии:

КатегорияВсегоПокрытоНе покрытоПокрытие %
Функциональные требования4543295.6%
Нефункциональные требования1210283.3%
Бизнес-правила880100%
Итого6561493.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 гарантируют, что пользовательские истории реализованы правильно и полностью.

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

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