Как вести приемочные критерии для формы
Что проверяют
Умеете ли вы превратить «сделать форму регистрации» в проверяемые условия и где их хранить. Интервьюер смотрит, думаете ли вы о негативных сценариях и граничных значениях ещё до разработки. Следом часто просят на ходу написать пару критериев для конкретного поля.
Как отвечать
Критерии формулируют аналитик или продакт, разработчик и QA вместе на груминге до спринта и хранят в самой пользовательской истории в Jira или Confluence. Тест-кейсы в TMS (TestRail, Qase, Allure TestOps) ссылаются на критерии, а не дублируют их.
Формат выбирают под задачу:
- сценарный (Given/When/Then): подходит для поведения и потом ложится в автотесты на Cucumber. Пример: дано пустое обязательное поле email, когда пользователь нажимает кнопку отправки, тогда форма не уходит, а под полем появляется текст ошибки из макета;
- список правил: подходит для валидации полей, каждое правило отдельной строкой.
Что покрыть для формы:
- поля: обязательность, формат, минимальная и максимальная длина, допустимые символы, пробелы по краям;
- момент валидации: при потере фокуса или при отправке, и когда ошибка исчезает;
- отправка: блокировка кнопки на время запроса, поведение при ошибке сервера и потере сети, сохранение введённых данных;
- успех: что видит пользователь и что записано в систему;
- доступность: подписи к полям, работа с клавиатуры, фокус на первое поле с ошибкой.
Главное требование к критерию: его можно проверить однозначно. «Форма удобная» не критерий, «сообщение об ошибке появляется под полем после потери фокуса» критерий. Критерии меняются только через историю задачи, иначе тесты проверяют уже не то, о чём договорились.
Где спотыкаются
Путают приёмочные критерии с Definition of Done. Критерии относятся к конкретной задаче, DoD общий для всех задач команды: код отревьюен, тесты прошли.
Пишут только позитивный сценарий. Пустые поля, длина на границе, пробелы при вставке и двойной клик остаются без договорённости, и спор возникает уже на баге.
Расписывают критерии до уровня тест-кейсов. Такой документ никто не читает, и он устаревает с первым изменением макета.