До какого уровня доверять в тестировании и проверять работу аналитика
Что проверяют
Где у вас граница ответственности: делаете ли вы строго по ТЗ или отвечаете за результат целиком. Интервьюер ищет баланс: разработчик, который не перепроверяет ничего, пропустит ошибку в требованиях, а тот, кто перепроверяет всё, тормозит команду. Следом почти всегда просят пример, когда вы нашли ошибку у аналитика.
Как отвечать
Хорошая формула: требованиям доверяю как источнику задачи, но проверяю их на полноту и реализуемость до того, как писать код, а за качество своего кода отвечаю сам, не надеясь на тестировщика. Каркас:
- ревью требований: читаете ТЗ с вопросами. Что будет при пустом значении, дубле, нуле, другом часовом поясе? Есть ли критерии приёмки? Не противоречит ли новое правило старому;
- проверка на данных: если аналитик описал формулу или выборку, проверьте её на реальных данных, запросом в базу или в Jupyter через pandas. Часто выясняется, что поле бывает
NULLтам, где его «всегда заполняют»; - свои тесты: примеры из требований превращаются в тесты на pytest через
@pytest.mark.parametrize, граничные случаи вы добавляете сами. Для функций с широким входом помогает hypothesis; - договорённость: расхождение не правите молча, а согласуете с аналитиком и фиксируете в задаче.
Глубина проверки зависит от цены ошибки: биллинг и отчётность для руководства проверяются строже, чем текст на кнопке. Подкрепите это своим случаем с реальными деталями: что нашли, как донесли, чем кончилось. Если такого опыта не было, так и скажите и опишите, как поступили бы. Это честнее выдуманной истории.
Где спотыкаются
Отвечают «делаю как написано, за требования отвечает аналитик». Звучит как готовность выпустить заведомо неверную логику, лишь бы формально быть правым.
Уходят в другую крайность и рассказывают, как переделывают работу за аналитиком. Интервьюер слышит будущий конфликт.
Говорят «тестировщики найдут». Для разработчика это красный флаг: тесты на свой код он пишет сам, а QA проверяет продукт, а не страхует от непроверенных функций.