Как проверять документацию на этапе разработки
Что проверяют
Понимаете ли вы проверку документации как статическое тестирование и умеете ли находить дефекты до того, как написан код. Следом часто дают реальное требование и просят найти в нём проблемы прямо на собеседовании.
Как отвечать
Проверка документации это тестирование без запуска кода и самая дешёвая точка для поиска дефекта. Назовите, по каким критериям смотрите:
- полнота: описаны негативные сценарии, пустые состояния, ограничения полей, права ролей, поведение при ошибке сервера;
- однозначность: слова «быстро», «удобно», «при необходимости» заменены измеримыми критериями;
- непротиворечивость: требование не спорит с другим требованием, макетом в Figma и контрактом API;
- тестируемость: по каждому пункту можно написать проверку с ожидаемым результатом;
- атомарность и трассируемость: одно требование описывает одну вещь и связано с задачей в трекере.
На практике задача приходит к вам на ревью до разработки. Вы читаете её, сразу набрасываете чек-лист или тест-кейсы и возвращаете вопросы аналитику комментариями в Confluence или Jira. Хорошо работают совместные разборы втроём: аналитик, разработчик и тестировщик, иногда с примерами в формате «дано, когда, тогда».
Для API часть работы автоматизируется: спецификацию OpenAPI проверяет линтер Spectral, а соответствие реализации спецификации ловят контрактные тесты или Schemathesis, который генерирует запросы по схеме.
Закончите своим примером: какой дефект нашли в требованиях и сколько переделки это сэкономило.
Где спотыкаются
Сводят проверку к орфографии и оформлению. Опечатки второстепенны, важны пропущенные сценарии и противоречия.
Ждут готового функционала, чтобы сверить документацию с ним. Это уже не проверка на этапе разработки, а поиск расхождений постфактум.
Оставляют общие замечания вроде «требование непонятное». Полезный комментарий содержит вопрос и вариант: «что показываем, если список пуст? Предлагаю заглушку с кнопкой создания».