Наконец-то дошёл до книги Кента Бека по TDD и сразу же, в самом начале, наткнулся на мысль, которую всегда разделял. Вот выдержка прямо с первых страниц:

…при достаточно низкой плотности дефектов команда контроля качества (Quality Assurance) сможет перейти от реагирования на ошибки к их предупреждению.

Прийти к этому можно с помощью разработки через тестирование, по мнению Кента Бека.

Главная задача инженера по обеспечению качества (QA) не в том, чтобы тестировать и сверять ожидаемый результат с фактическим, а в том, чтобы решать сложные инженерные задачи для предотвращения проблем в продукте. Естественно, такой подход работает только в тандеме с разработчиками, которые понимают и, что важнее, принимают свои зоны ответственности. Частично я раскрывал эту тему в своём посте: https://set.ki/post/d7HWJDx Хочу добавить, что, на мой взгляд, команда QA должна напрямую участвовать в построении процессов разработки. Это включает внедрение и использование статических анализаторов кода, мониторинг code coverage, проведение ревью и т.д. Если каких-то инструментов или процессов не хватает, именно QA должны лоббировать их внедрение. Чтобы разработчики прислушивались, соглашались и следовали вашим рекомендациям, важно обладать высоким уровнем компетенции. Прокачивайте инженерные навыки и участвуйте в процессах разработки на равных.