Практика
Практика: анализ User Story
Введение
Теория без практики не работает. В этом уроке разберём, как тестировщик читает User Story и извлекает из неё тест-кейсы. Это один из самых важных навыков в реальной работе.
Как читать User Story
User Story — это короткое описание функции с точки зрения пользователя. Стандартный формат:
Как [роль],
я хочу [действие],
чтобы [польза / результат].
Пример:
Как зарегистрированный пользователь,
я хочу войти в систему по email и паролю,
чтобы получить доступ к своим данным.
User Story отвечает на вопросы: кто, что и зачем. Но не описывает как именно — это задача критериев приёмки.
Критерии приёмки (Acceptance Criteria)
Критерии приёмки — это условия, при выполнении которых User Story считается реализованной. Без них разработчик не знает точно, что именно нужно сделать, а тестировщик — что именно проверять.
Хорошие критерии приёмки:
- Конкретны и однозначны
- Покрывают успешные и негативные сценарии
- Написаны языком, понятным всем участникам
Формат GIVEN-WHEN-THEN
Самый популярный способ записи критериев приёмки — GIVEN-WHEN-THEN (Дано-Когда-Тогда):
GIVEN [начальное состояние / контекст]
WHEN [действие пользователя]
THEN [ожидаемый результат]
Практический пример: User Story «Вход в систему»
Как зарегистрированный пользователь,
я хочу войти в систему по email и паролю,
чтобы получить доступ к своим данным.
Критерии приёмки:
AC-1: Успешный вход
GIVEN пользователь зарегистрирован в системе
WHEN вводит корректный email и пароль и нажимает «Войти»
THEN он перенаправляется на главную страницу личного кабинета
AC-2: Неверный пароль
GIVEN пользователь зарегистрирован в системе
WHEN вводит корректный email, но неверный пароль, и нажимает «Войти»
THEN отображается сообщение «Неверный email или пароль», форма не очищается
AC-3: Блокировка после попыток
GIVEN пользователь ввёл неверный пароль 5 раз подряд
WHEN пытается войти снова
THEN отображается сообщение «Аккаунт временно заблокирован. Попробуйте через 15 минут»
AC-4: Незаполненные поля
GIVEN пользователь открыл форму входа
WHEN нажимает «Войти», не заполнив поля
THEN отображаются сообщения валидации: «Введите email» и «Введите пароль»
AC-5: Несуществующий email
GIVEN пользователь не зарегистрирован
WHEN вводит несуществующий email и любой пароль
THEN отображается то же сообщение «Неверный email или пароль» (без подсказки о регистрации)
Тест-кейсы на основе критериев приёмки
Теперь из каждого критерия приёмки можно написать тест-кейс:
| Тест | Данные | Ожидаемый результат |
|---|---|---|
| TC-01: Успешный вход | email: user@test.com, пароль: Pass1234 | Редирект на /dashboard |
| TC-02: Неверный пароль | email: user@test.com, пароль: wrongpass | Сообщение об ошибке, форма заполнена |
| TC-03: Пустой email | email: пусто, пароль: Pass1234 | Валидационное сообщение на поле email |
| TC-04: Пустой пароль | email: user@test.com, пароль: пусто | Валидационное сообщение на поле пароля |
| TC-05: Несуществующий email | email: no@test.com, пароль: любой | Сообщение «Неверный email или пароль» |
| TC-06: Блокировка | 5 попыток с неверным паролем | Сообщение о блокировке |
Распространённые ошибки при тестировании без критериев приёмки
- Не знаешь, что именно проверять — нет критерия «готово»
- Тест зависит от настроения — каждый раз проверяется разное
- Нет договорённости о граничных случаях — непонятно, нормально ли 5 попыток или должно быть 3
- Баги не принимаются — разработчик говорит «так и задумано», но это нигде не зафиксировано
Что мы запомним
- User Story описывает кто, что и зачем — но не как
- Критерии приёмки определяют, при каких условиях Story считается готовой
- GIVEN-WHEN-THEN — стандартный и понятный формат для критериев приёмки
- Каждый критерий приёмки — это основа для одного или нескольких тест-кейсов
- Тестирование без критериев приёмки ненадёжно и непредсказуемо