Что такое тестирование пользовательских историй?
В Agile-разработке требования фиксируются как пользовательские истории (user stories) — краткие описания функциональности с точки зрения пользователя. Тестирование user story выводит тест-кейсы из этих историй и их критериев приёмки.
Формат пользовательской истории
Как [роль],
Я хочу [действие],
Чтобы [выгода].
Пример:
Как зарегистрированный клиент,
Я хочу фильтровать товары по ценовому диапазону,
Чтобы быстро находить товары в рамках моего бюджета.
3C пользовательских историй
| C | Значение | Влияние на тестирование |
|---|---|---|
| Card | Написанная история | Определяет область тестирования |
| Conversation | Обсуждение со стейкхолдерами | Выявляет скрытые требования и граничные случаи |
| Confirmation | Критерии приёмки | Прямой источник тест-кейсов |
Критерии приёмки в формате Given/When/Then
Given я на странице списка товаров
And есть товары с ценами от $5 до $500
When я устанавливаю фильтр цены $20 - $100
Then я должен видеть только товары с ценой от $20 до $100
And количество товаров должно обновиться
And URL должен включать параметры фильтра
Given = Предусловие (подготовка теста) When = Действие (шаг теста) Then = Ожидаемый результат (проверка теста)
Полный пример: Story с критериями приёмки
Story: Как зарегистрированный клиент, я хочу добавлять товары в список желаний, чтобы сохранять товары для будущей покупки.
Критерии приёмки:
AC1: Given я авторизован, When я нажимаю «Добавить в список желаний» на товаре, Then товар появляется в моём списке желаний.
AC2: Given я не авторизован, When я нажимаю «Добавить в список желаний», Then я перенаправлен на страницу входа.
AC3: Given товар уже в моём списке, When я нажимаю «Добавить в список желаний», Then я вижу сообщение «Уже в списке желаний».
AC4: Given у меня есть товары в списке, When я просматриваю список, Then я вижу все товары, отсортированные по дате добавления (новые первыми).
AC5: Given у меня есть товары в списке, When я нажимаю «Удалить» на товаре, Then товар удалён и список обновлён.
Вывод тест-кейсов из критериев приёмки
| TC | AC | Тип | Тест |
|---|---|---|---|
| TC1 | AC1 | Позитивный | Авторизованный пользователь добавляет товар → появляется в списке |
| TC2 | AC2 | Позитивный | Не авторизован → перенаправление на вход |
| TC3 | AC3 | Позитивный | Товар уже в списке → сообщение |
| TC4 | AC4 | Позитивный | Просмотр списка → отсортирован по дате |
| TC5 | AC5 | Позитивный | Удалить товар → удалён из списка |
| TC6 | AC1 | Негативный | Добавить товар без наличия → допустимо ли? |
| TC7 | AC4 | Граничный | Список пуст → показать пустое состояние |
| TC8 | AC1 | Граничный | Добавить тот же товар с разных страниц → только одна запись |
| TC9 | AC5 | Граничный | Удалить последний товар → показать пустое состояние |
Критерии INVEST для тестируемых историй
| Буква | Критерий | Влияние на тестирование |
|---|---|---|
| I | Независимая | Можно тестировать изолированно |
| N | Обсуждаемая | AC могут эволюционировать через обсуждение |
| V | Ценная | Ценность для пользователя определяет приоритет тестов |
| E | Оценимая | Объём достаточно ясен для оценки усилий |
| S | Маленькая | Помещается в спринт — управляемый объём тестов |
| T | Тестируемая | Существуют чёткие критерии приёмки |
Если история не Тестируемая — сообщайте об этом до начала разработки.
Продвинутое тестирование user story
За пределами критериев приёмки
AC покрывают «что», но тестировщики должны также учитывать:
| Аспект | Вопросы |
|---|---|
| Производительность | Как быстро должен загружаться список со 100 товарами? |
| Безопасность | Может ли пользователь A видеть список пользователя B? |
| Доступность | Могут ли screen reader навигировать по списку? |
| Совместимость | Работает ли в мобильных браузерах? |
| Данные | Каков максимальный размер списка? |
| Конкурентность | Что если пользователь добавляет товар с двух устройств одновременно? |
BDD: Автоматизация тестов историй
Критерии приёмки в формате Given/When/Then можно автоматизировать с BDD-фреймворками:
Feature: Список желаний товаров
Scenario: Добавление товара в список желаний
Given я авторизован как "client@test.com"
And я просматриваю товар "Синий виджет"
When я нажимаю "Добавить в список желаний"
Then "Синий виджет" должен появиться в моём списке
And я должен увидеть сообщение "Добавлено в список желаний"
Scenario: Попытка добавить дублирующий товар
Given я авторизован как "client@test.com"
And "Синий виджет" уже в моём списке
When я нажимаю "Добавить в список желаний" на "Синий виджет"
Then я должен увидеть "Уже в списке желаний"
And количество в моём списке не должно измениться
Упражнение: Напишите тесты для user story
Story:
Как руководитель команды,
Я хочу назначать задачи членам команды,
Чтобы работа распределялась и отслеживалась.
Критерии приёмки:
- AC1: Я могу выбрать члена команды и назначить его на задачу
- AC2: Назначенный член получает email-уведомление
- AC3: Я могу переназначить задачу другому члену
- AC4: Я могу видеть все задачи каждого члена на дашборде
- AC5: Только руководители могут назначать задачи (обычные члены не могут)
Задание: Напишите тест-кейсы для всех AC, плюс добавьте минимум 3 негативных/граничных теста.
Подсказка
Подумайте о: назначении себе, назначении деактивированному члену, назначении при отсутствии членов команды, массовом назначении, уведомлениях при отключённом email.
Решение
Из AC: 7 тест-кейсов (позитивные + варианты AC3 и AC5)
Дополнительные тесты:
| TC | Тип | Тест |
|---|---|---|
| TC8 | Граничный | Назначить задачу самому себе |
| TC9 | Граничный | Назначить деактивированному члену команды |
| TC10 | Граничный | Назначить при пустом выпадающем списке |
| TC11 | Негативный | Назначить уже завершённую задачу |
| TC12 | Конкурентность | Два руководителя назначают одну задачу одновременно |
| TC13 | Производительность | Дашборд с 500+ задачами загружается за 3 секунды |
Итого: 13 тест-кейсов.
Советы профессионала
- Участвуйте в сессиях уточнения историй. «Conversation» — это где вы обнаружите большинство граничных случаев и неявных требований.
- Пишите тесты до разработки. Это настоящее shift-left тестирование — нахождение неоднозначностей в AC до написания кода экономит огромные усилия на переработку.
- Не тестируйте только написанное. AC — отправная точка, а не полный объём тестов. Всегда добавляйте негативные, граничные и нефункциональные тесты.
- Связывайте тест-кейсы с AC. Трассировка помогает доказать покрытие и выявить пробелы во время sprint review.
- Используйте тестирование историй для улучшения историй. Если не можете написать чёткие тесты по истории — история нуждается в уточнении.