Техники тестирования требований
Техники тестирования требований
Введение
Тестирование начинается не с запуска приложения, а с анализа требований. Чем раньше ты найдёшь проблему в документе — тем дешевле обойдётся её исправление. Устранить баг на этапе требований в 10–100 раз дешевле, чем после релиза.
В этом уроке разберём конкретные техники, которые тестировщик применяет при работе с требованиями.
Ревью требований
Ревью требований — это внимательное чтение спецификаций с целью найти проблемы: неоднозначности, пробелы, противоречия.
Что искать при ревью:
| Проблема | Пример |
|---|---|
| Неоднозначность | «Система должна работать корректно» |
| Пробел | Описан вход в систему, но не описан выход |
| Противоречие | В одном месте «поле обязательно», в другом — «поле необязательно» |
| Нетестируемость | «Пользователи должны быть довольны» |
| Неполнота | Описан успешный сценарий, но не описана обработка ошибок |
Совет: читай требования с позиции «а что если пользователь сделает Х?» — это сразу выявляет пробелы.
Создание тест-кейсов по требованиям
Один из лучших способов проверить качество требования — попытаться написать тест-кейс для него.
Правило: Если ты не можешь написать тест-кейс — требование написано плохо.
Попробуй составить тест для требования «Система должна быть безопасной». Что конкретно проверять? Ничего не понятно.
А для «Пароль должен содержать минимум 8 символов, включая хотя бы одну цифру и одну заглавную букву» сразу понятно:
- Тест 1: ввести пароль из 7 символов → ожидается ошибка
- Тест 2: ввести пароль без цифры → ожидается ошибка
- Тест 3: ввести пароль без заглавной буквы → ожидается ошибка
- Тест 4: ввести правильный пароль → ожидается успех
Вопросы бизнесу
Задавать вопросы как можно раньше — одна из главных ценностей тестировщика в команде. Не жди, пока разработчик сдаст функцию, чтобы задать вопрос аналитику.
Шаблон вопросов:
| Вопрос | Для чего |
|---|---|
| Кто? | Кто выполняет это действие? Какие роли? |
| Что? | Что именно должно произойти? |
| Когда? | При каком условии? |
| Где? | На каком экране / в каком состоянии? |
| Почему? | Зачем эта функция нужна бизнесу? |
| Как? | Как именно это должно выглядеть / работать? |
Пример: требование «Пользователь может удалить аккаунт». Вопросы:
- Что происходит с данными пользователя после удаления?
- Можно ли восстановить аккаунт после удаления?
- Удаление немедленное или с периодом ожидания?
Матрица трассируемости
Матрица трассируемости (Traceability Matrix) — таблица, которая связывает требования с тест-кейсами. Она позволяет убедиться, что каждое требование покрыто тестами.
| ID требования | Требование | Тест-кейс | Статус |
|---|---|---|---|
| REQ-01 | Регистрация по email | TC-01, TC-02 | Passed |
| REQ-02 | Вход в систему | TC-03, TC-04, TC-05 | Passed |
| REQ-03 | Восстановление пароля | TC-06 | Failed |
| REQ-04 | Двухфакторная аутентификация | — | Не покрыто |
Матрица сразу показывает: REQ-04 не имеет тест-кейса — это пробел в тестировании.
Техника вопросов для анализа требований
При чтении любого требования задай себе этот чеклист:
□ Что происходит при успешном выполнении?
□ Что происходит при ошибке?
□ Что если пользователь ничего не ввёл?
□ Что если пользователь ввёл слишком много / слишком мало?
□ Что если пользователь не авторизован?
□ Есть ли граничные значения (минимум, максимум)?
□ Что видит пользователь после действия?
□ Как это влияет на другие функции?
Распространённые ошибки
- Начинать писать тест-кейсы без ревью требований — потом придётся переделывать
- Не документировать вопросы — устные договорённости забываются
- Не обновлять матрицу — устаревшая матрица хуже, чем её отсутствие
- Задавать вопросы только разработчикам — нужно идти к аналитику или Product Owner
Что мы запомним
- Ревью требований — это поиск неоднозначностей, пробелов и противоречий до начала тестирования
- Если нельзя написать тест-кейс — требование написано плохо
- Вопросы «кто, что, когда, где, почему, как» помогают вскрыть пробелы
- Матрица трассируемости связывает требования и тест-кейсы, показывает непокрытые требования
- Чем раньше найден дефект требований — тем дешевле его исправить