Какие подходы и техники применить для достижения максимально качественного кода
Что проверяют
Понимаете ли вы, что качество закладывается до тестирования, и какую роль в этом играет QA, кроме поиска багов в готовой сборке. Следом обычно спрашивают, как вы встраиваете эти практики в процесс команды и чем меряете результат.
Как отвечать
Стройте ответ по этапам жизни задачи:
- требования: тестирование начинается с постановки. Разбор задачи втроём (аналитик, разработчик, тестировщик), критерии приёмки, при BDD сценарии на Gherkin. Дефект, пойманный в требованиях, стоит дешевле всего;
- пирамида тестов: много быстрых юнит-тестов, меньше интеграционных и контрактных, немного E2E на критичные пути. Перевёрнутая пирамида даёт медленный и нестабильный регресс;
- тест-дизайн: классы эквивалентности, граничные значения и таблицы решений применимы и к юнит-тестам, их полезно обсуждать с разработчиками;
- статический анализ: линтеры под стек (ESLint, Checkstyle, Ruff) и SonarQube с quality gate, который не пропускает новый код с падением покрытия или критичными замечаниями;
- код-ревью: небольшие пулл-реквесты, чек-лист, ревью тестов наравне с кодом;
- CI: каждый коммит проходит линтер, сборку и тесты, красная сборка блокирует слияние. Нестабильные тесты чинят или изолируют, а не перезапускают до зелёного;
- метрики: покрытие как индикатор, мутационное тестирование (PIT, Stryker) как проверка, что тесты действительно что-то ловят, доля дефектов, ушедших в прод, и их причины.
Дополните своим опытом: какую практику вы внедрили и что изменилось в цифрах, например сократилось время регресса или число багов с прода. Если внедрять не приходилось, расскажите, как участвовали в уже работающем процессе и что предложили бы улучшить.
Где спотыкаются
Сводят качество к тестам после разработки. Для QA это слабая позиция, сильнее звучит участие на этапе требований и ревью.
Называют высокое покрытие целью. Сто процентов строк без осмысленных проверок ничего не гарантируют, и мутационное тестирование это наглядно показывает.
Перечисляют SOLID, DRY и KISS без связи с ролью. От тестировщика ждут не лекции по проектированию, а того, как он помогает команде держать планку и как пишет качественный код автотестов.