За последние десять лет роль тестирования изменилась гораздо сильнее, чем за предыдущие двадцать. Если раньше QA воспринимался как последний рубеж перед релизом, то сегодня инженеры по качеству участвуют в проектировании требований, помогают команде выстраивать процесс поставки изменений и зачастую становятся теми, кто первым замечает, что система начинает терять устойчивость.
При этом вокруг технического долга до сих пор существует одна довольно устойчивая иллюзия. Стоит в команде заговорить о замедлении разработки, росте количества регрессий или усложнении релизов, как почти неизбежно звучит предложение: «Нужно усилить тестирование». Иногда под этим понимают автоматизацию, иногда — увеличение покрытия тестами, иногда — дополнительные проверки перед релизом. Формулировки могут отличаться, но логика остаётся одной и той же: если система становится сложнее, значит, её нужно лучше тестировать.
На первый взгляд такая логика выглядит вполне разумной: если система становится сложнее, значит, её нужно лучше тестировать. Проблема в том, что тестирование не устраняет причину этой сложности. Оно лишь позволяет раньше заметить её последствия.
Мы привыкли воспринимать технический долг как инженерскую проблему, которую можно постепенно уменьшить: провести рефакторинг, переписать несколько сервисов, улучшить покрытие тестами. Но тестирование вообще не находится в той точке жизненного цикла, где этот долг появляется. Оно сталкивается с ним значительно позже, когда архитектурные решения уже приняты, зависимости между компонентами сформированы, а сложность системы стала объективной характеристикой продукта.
