Ответ
Я рассматриваю переработки как исключительную меру, а не регулярную практику. В тестировании уставший инженер с большой вероятностью пропустит баг или составит некачественный тест-кейс, что в итоге только увеличит технический долг и риски для продукта.
В моей практике системные переработки часто сигнализируют о проблемах в процессах: нереалистичные сроки, позднее вовлечение QA, отсутствие автоматизации рутины или нестабильная среда. Я выступаю за то, чтобы анализировать и устранять коренные причины.
Например, вместо ручных регрессий перед каждым релизом мы с командой внедряли автоматизированные smoke- и regression-сеты, которые запускались в CI/CD. Это значительно сокращало необходимость в авралах.
# Пример: автоматический запуск критичных тестов при каждом билде
# (конфигурация для Jenkins/GitLab CI)
stages:
- test
smoke_test:
stage: test
script:
- pytest tests/smoke/ -v --html=report.htmlЯ готов задержаться в форс-мажорных ситуациях, таких как критичный production-баг или горячий релиз, но считаю важным после такого случая провести ретроспективу и не допускать повторения.
