Нужен ли ручной тестировщик в проекте
Что проверяют
Готовы ли вы отвечать за качество своего кода или считаете, что ваше дело написать, а проверять будут другие. В командах на Python это ещё и вопрос про тестируемость: язык динамический, опечатка в имени атрибута не ловится компилятором, и без тестов её находит пользователь.
Как отвечать
Разложить по слоям ответственности:
- разработчик закрывает свой уровень: юнит-тесты на логику, интеграционные на базу и очередь через контейнеры, проверка схем и контрактов API, аннотации типов и статический анализ;
- тестировщик нужен там, где автоматизация дорога или бессмысленна: сквозные сценарии через интерфейс, интеграции с внешними системами, разовые миграции данных, приёмка перед релизом;
- отдельный человек полезен ещё до кода: вопросы к требованиям и крайним случаям экономят переписывание готовой функции;
- на небольшом сервисе с хорошим покрытием и стендом команда живёт без выделенного тестировщика, но роль никуда не исчезает, её по очереди выполняют разработчики.
Хорошо показать понимание границы: наличие тестировщика не повод отдавать непроверенный код, а его отсутствие не повод выкатывать без прогона.
Где спотыкаются
Говорят «у нас всё покрыто тестами, тестировщик не нужен» и меряют качество покрытием строк. Покрытие говорит лишь, что строка исполнилась: тест без единой проверки тоже даёт высокий процент.
Второе: пишут только счастливый путь. В динамическом языке основная боль это None там, где ожидали объект, чужой формат ответа, кодировки и часовые пояса, а такие случаи придумывает как раз человек со стороны.
Третье: рассуждают абстрактно про «баланс ручного и автоматического», не привязываясь к своей зоне. Вопрос задан разработчику, и ждут конкретики: что вы проверяете сами, прежде чем передать задачу дальше.