Что происходит после разработки требований в процессе разработки
Что проверяют
Знаете ли вы, что работа тестировщика начинается до кода. Требования готовы: вопрос в том, назовёте ли вы их первым объектом тестирования или скажете «дальше разработчики пишут, потом мы проверяем». Второй ответ выдаёт тестировщика, который умеет только прокликивать готовое.
Как отвечать
Сначала требования проверяются сами по себе, это статическое тестирование. Критерии простые:
- полнота: описано ли поведение при ошибке, пустых данных, отказе внешнего сервиса;
- непротиворечивость: не спорит ли пункт с соседним и с уже работающей функцией;
- однозначность: одна формулировка, одно прочтение;
- проверяемость: понятно ли, каким действием и с каким ожидаемым результатом это проверить;
- трассируемость: к какой цели относится пункт.
Дальше идёт тест-анализ: что вообще будем проверять, какие объекты, состояния и связи, где риск выше. На его основе тест-дизайн: классы эквивалентности, граничные значения, таблица решений, диаграмма состояний, попарные комбинации. Параллельно фиксируются критерии приёмки, нужные тестовые данные и окружение, а также критерии входа и выхода для этапа тестирования.
Сильный ответ добавит, что дефект требований на этом шаге стоит дешевле всего, и приведёт пример: «система работает быстро» непроверяемо, а «ответ не дольше заданного времени при заданном числе одновременных пользователей» уже проверяемо.
Где спотыкаются
Пересказывают каскадную модель как единственную: проектирование, разработка, тестирование, поддержка. В итеративном процессе тест-дизайн идёт одновременно с разработкой, а не после неё.
Путают тест-анализ и тест-дизайн. Первое отвечает на вопрос, что проверяем, второе на вопрос, как и какими данными.
Называют только позитивные проверки. Требование задаёт границы и поведение при неверном вводе, и именно там живёт большинство дефектов.