Когда интуитивного тестирования уже недостаточно и качество ведет себя непредсказуемо, метрики перестают быть формальностью и превращаются в обязательный инструмент управления качеством.
За годы работы в тестировании я убедился: то, что невозможно измерить — невозможно улучшить. В статье я разберу ключевые QA-метрики и объясню, как TMS помогает сделать картину качества действительно прозрачной.

The best test engineers don’t just validate software — they shape how teams think about quality.
They don’t just catch problems — they architect solutions that prevent entire categories of issues.
They don’t just report status — they translate technical risk into business language that drives decisions.

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

Каждое ретро превращается в длинный список проблем: команда обсуждает всё подряд, составляет планы — но через месяц список остаётся тем же. Проблемы не решаются, а участники устают от бесконечных разговоров без результата. Squad Health Check работает иначе: он помогает выявить одну самую «больную» точку и сфокусировать команду на её решении.

Мы решили, что будем разделяться на модули: один проект будет содержать много модулей с тестами. Чтобы такое провернуть, мы начали с анализа наших зависимостей, с рефакторинга нашего конфигурационного файла сборщика, или как мы его называем — build.gradle: вынесли в отдельные блоки именно те таски и зависимости этого сборщика, которые точно понадобятся всем модулям.

Благодаря модулям мы получили ещё один серьезный бонус. Допустим, что через некоторое время мы хотим заменить наш старый HTTP-клиент на новый. Раньше это была бы мучительная задача по рефакторингу сотен тестов. Теперь же мы меняем зависимость и логику только в одном месте — в модуле-адаптере. Сами автотесты даже «не узнают», что что-то поменялось. Мы изолировали изменения!

В данной статье отражена попытка применить модель детекции для UI-тестирования.
Предполагалось, что внедрение ML должно позволить (даже при полном изменении интерфейса) не переписывать автотесты и полностью исключить человеческий фактор при UI-тестировании.

Этот вид тестирования показал свою эффективность в тех случаях, когда у вашего проекта есть следующие особенности:

- это легаси проект с непрозрачной, плохо задокументированной и достаточно сложной логикой (назовем ее “серой логикой”). При этом члены команды, обладающие контекстом легаси не могут 100% гарантировать (или у вас есть сомнения), что их воспоминания о фактическом поведении “серой логики” верны 
- на проекте присутствует БД, данные которой являются точкой применения вышеуказанной “серой логики”
- сам проект уже в production
- при этом ограничения, установленные на уровне БД не могут покрыть все необходимые ограничения, которые требует бизнес логика (само собой при наличии достаточно сложного функционала)

Мы же хотели обучающую модель, при которой получали бы опытных сотрудников, готовых выполнять задачи на наших инструментах сразу, без адаптации. В итоге создали корпоративную школу автоматизированного тестирования (далее — Школа АТ), которая уже третий год обучает AQA-инженеров на практических примерах и действующих в компании фреймворках.