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