Как выбрать между чек-листом и тест кейсом и когда использовать каждый из них
Что проверяют
Умеете ли вы выбирать уровень детализации под задачу, а не пишете тест-кейсы на всё подряд по привычке. Следом обычно просят пример из опыта: где хватило чек-листа, а где без подробного кейса было не обойтись.
Как отвечать
Начните с разницы по сути:
- чек-лист: список того, что нужно проверить, без шагов и точных данных. Пункт вида «оплата картой с 3-D Secure проходит». Как именно проверять, решает тестировщик, поэтому прогоны немного различаются, и это даже помогает находить новые баги;
- тест-кейс: предусловия, шаги, входные данные и ожидаемый результат. Два разных человека пройдут его одинаково и получат сравнимый итог.
Дальше назовите факторы выбора:
- кто исполняет: опытный тестировщик, знающий продукт, работает по чек-листу; новичку, аутсорсу или коллеге из другой команды нужен кейс;
- цена ошибки: платежи, расчёты, требования регулятора и аудит просят кейсы с зафиксированными данными;
- стабильность фичи: если функциональность меняется каждый спринт, актуализация кейсов съест всё время, выгоднее чек-лист;
- автоматизация: кейс с чёткими шагами и ожидаемым результатом легко превращается в автотест, чек-лист для этого слишком размыт;
- сроки: смоук после деплоя и быстрая регрессия обычно идут по чек-листу.
Сильный итог: инструменты не конкурируют. Частая практика такая: чек-лист служит картой покрытия, а для критичных пунктов из него пишутся подробные кейсы. Хранится всё в TestRail, Qase, Allure TestOps или Zephyr, где в одном наборе уживаются оба формата.
Где спотыкаются
Говорят, что чек-лист «для ленивых», а кейс «для профессионалов». Интервьюер слышит, что вы не считаете стоимость поддержки документации.
Пишут пункты чек-листа, которые нельзя проверить. «Проверить корзину» это не пункт, а тема; пункт звучит как «товар удаляется из корзины, сумма пересчитывается».
Не упоминают поддержку. Сотни кейсов, которые полгода никто не обновлял, хуже их отсутствия: по ним проходят и ставят «passed» на устаревшее поведение.