Как тестировать требования
Тестирование требований — это не про поиск багов в коде. Это процесс проверки того, насколько сами требования корректны, полны и понятны.Зачем это вообще нужно?
Ошибки в требованиях → баги в реализации → потери времени и денег.
Тестирование требований позволяет:
— Выявлять дефекты до этапа кодинга
— Экономить время команды
— Делать ожидания всех сторон прозрачными
— Повышать качество продукта без доработок «в последний момент»
Как понять, что требование хорошо сформулировано:
Какие техники тестирования требований использовать?
Взаимный просмотрПоказываем свою работу коллегам
Вопросы
Уточняем у заказчиков и коллег
Тест-кейсы и чек-листы
Прорабатываем набор вопросов для проверки требований
Рисунки
Наглядно представляем приложение
Прототипирование
Делаем наброски интерфейса и переходов между экранными формами
Исследование поведения системы
Мысленно моделируем работу пользователя с системой
Как проверить количество и атомарность?
— Делаем блок-схему, чтобы увидеть дубли и лишние шаги— Проверяем, что требование описывает Create / Read / Update / Delete / List
— При помощи сценария использования проверяем, что требование покрывает весь путь пользователя
— Используем таблицу решений, чтобы убедиться, что все варианты условий покрыты
— Ищем отсылки на неопределенную информацию — если есть «и т.д.», «как обычно», стоит уточнить
— Проверяем на союз «и» — часто он объединяет в одном требовании сразу два, а иногда и больше
Как проверить выполнимость и однозначность?
Хорошее требование не вызывает споров — его можно понять одинаково, реализовать и проверить результат.Что важно:
— Терминология
— Отсутствие качественных определений
— Простое изложение
— Возможность составить набор тестов
— Тестирование внешних сервисов
Как проверить актуальность и последовательность?
Если требование забыли, потеряли или поняли не так — беда в процессе.На что обращаем внимание:
— Одно требование описано в одном месте
— Есть user story или хотя бы сценарий использования
— У автора требований есть знание предметной области
— Учтены интересы всех пользователей
— Договоренности из чатов перенесены в документацию
— Согласована дата последнего обновления требований и документации
Хорошие требования — это результат не только опыта, но и осознанной практики.
