У компании могут быть десятки QA-метрик и при этом не быть ответа на вопрос: почему продукт становится все дороже и сложнее менять?

Команда знает, сколько дефектов нашла за спринт, сколько ошибок дошло до продакшена, сколько времени занимает регрессия, какой процент сценариев автоматизирован. После каждого релиза появляются новые цифры, графики и отчеты.

А теперь представим продукт, который выпускает релизы раз в две недели. Серьезных дефектов больше не становится, автоматизация развивается, команда укладывается в релизный цикл. На первый взгляд все в порядке.

Но за последний год регрессия заметно выросла. Изменение одного сервиса все чаще требует проверки нескольких соседних. Одни и те же компоненты регулярно всплывают в инцидентах и срочных исправлениях после релиза.

Для QA это дополнительные проверки и знакомые проблемные модули. Для CTO — возможный сигнал, что растет стоимость изменений.

Через несколько кварталов эта история может проявиться уже в сроках разработки. Новые функции станут выходить дольше, оценки начнут расти, а для сохранения прежней скорости понадобится больше людей.

Первые признаки проблемы при этом уже были в данных QA.

Примерно вокруг этой идеи и строится Quality Intelligence.

Что вообще такое Quality Intelligence

За термином Quality Intelligence скрывается практичная идея: данные о качестве могут рассказать о продукте гораздо больше, чем просто показать, насколько хорошо он протестирован перед очередным релизом.

История тестирования, дефекты, изменения компонентов, продакшн-инциденты, обращения пользователей, продуктовые показатели — все это следы того, как система развивается и как она реагирует на изменения. Если смотреть на них вместе и в динамике, можно заметить проблемы задолго до того, как они станут очевидны на уровне сроков, бюджетов или пользовательских жалоб.

Представим, что еще год назад полная регрессия занимала два дня, а теперь на нее требуется четыре. Самый очевидный вывод — тестирование стало медленнее, значит, нужно расширять автоматизацию. И в некоторых случаях это действительно сработает.

Но сначала стоит разобраться, откуда появились дополнительные два дня.

За это время мог заметно вырасти сам продукт, появиться новые интеграции или проблемы с тестовыми стендами. Возможно, увеличилось количество ручных проверок. А может быть, причина глубже: даже небольшое изменение теперь затрагивает столько зависимых компонентов, что команде приходится перепроверять значительную часть системы.

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

В этом и заключается логика Quality Intelligence: важно увидеть за изменением показателя то, что происходит с самим продуктом.

История дефектов может многое рассказать о состоянии системы

Количество найденных дефектов само по себе мало что говорит о качестве продукта. Две тысячи ошибок за год выглядят внушительно, но для большой и активно развивающейся системы эта цифра может быть вполне обычной. Гораздо интереснее посмотреть, как эти дефекты распределяются и что происходит с ними со временем.

Если критические ошибки из месяца в месяц возникают в одних и тех же компонентах, это уже повод обратить на них внимание. Особенно когда после изменений в этих модулях команде приходится расширять регрессию, а сами они регулярно фигурируют в срочных исправлениях и инцидентах после релиза.

В такой картине видна уже не просто статистика дефектов. Она может указывать на проблемную область внутри продукта, хотя причина еще требует отдельного анализа. Где-то не хватает тестового покрытия, где-то сказывается высокая связанность компонентов или накопившийся технический долг. В зрелых системах бывает и так, что архитектура, хорошо работавшая несколько лет назад, постепенно перестает справляться с масштабом и темпом изменений.

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

Постепенно отдельные события складываются в связанную историю:

изменение → компонент → тестирование → дефект → релиз → production → пользователь.

Если к ней добавить данные продуктовой аналитики, становится видно и продолжение этой цепочки: какие пользовательские сценарии затронула проблема, насколько часто с ней сталкивались и какое значение эти сценарии имеют для продукта.

В результате привычная история дефектов начинает отвечать на гораздо более интересный вопрос: где продукт постепенно становится сложнее, рискованнее или дороже в изменении.

И это уже информация, которая нужна не только QA-команде.

Критичность дефекта еще не определяет его приоритет

Техническая критичность ошибки и ее влияние на продукт не всегда совпадают.

Представим интернет-магазин, где накопилось 120 дефектов: три критических, 31 серьезный и 86 менее значимых. Если ориентироваться только на эту классификацию, порядок исправлений кажется очевидным — в первую очередь команда займется критическими ошибками.

Но посмотрим на две из них.

Одна критическая ошибка приводит к сбою внутреннего административного интерфейса при редкой комбинации действий. Проблема серьезная с технической точки зрения, однако с ней могут столкнуться лишь несколько сотрудников.

Другая ошибка имеет более низкий уровень критичности, но периодически мешает покупателям завершить оформление заказа после применения промокода. Система продолжает работать, данные не теряются, однако проблема возникает в сценарии, напрямую связанном с покупкой.

Какой из этих дефектов важнее исправить первым?

Одной технической классификации для ответа уже недостаточно. Нужно понимать, как часто возникает ошибка, сколько пользователей с ней сталкиваются, насколько важен затронутый сценарий и к каким последствиям проблема может привести.

Это не требует сложной системы коэффициентов. Иногда достаточно добавить к технической оценке несколько продуктовых показателей. Если дефект возникает на этапе оформления заказа, через который проходит значительная часть покупателей, эта информация должна учитываться при определении приоритета.

В результате список дефектов перестает существовать отдельно от задач по развитию продукта. И там, и там команда решает одну и ту же задачу: куда направить ограниченные ресурсы, чтобы получить наибольший эффект для продукта и его пользователей.

Так данные QA начинают влиять уже не только на очередность исправлений, но и на продуктовые решения.

Самое интересное находится между системами

Собирать для Quality Intelligence какие-то экзотические данные обычно не требуется. Большая часть уже есть внутри компании.

Тесты хранятся в Test Management System. Дефекты и задачи — в Jira. Изменения — в Git. Сборки и развертывания — в CI/CD. Инциденты — в мониторинге. Пользовательские проблемы — в поддержке. Поведение клиентов — в продуктовой аналитике.

Каждая система рассказывает свою часть истории.

QA видит, что выросла регрессия, Git знает, какие компоненты активно менялись. Мониторинг показывает, где после релизов возникали проблемы, а поддержка знает, с чем столкнулись пользователи.

По отдельности получаются несколько отчетов. Вместе они могут дать ответ на совсем другой вопрос. Например, выясняется, что почти вся дополнительная регрессия последних месяцев возникает вокруг нескольких связанных компонентов. Они активно меняются и регулярно участвуют в post-release исправлениях.

После этого вопрос «как еще ускорить тестирование?» становится слишком узким. Важно понять, почему изменения именно в этой части системы обходятся так дорого.

Ответом может стать дополнительная автоматизация. Может потребоваться работа с тестовой инфраструктурой. В какой-то ситуации выяснится, что проблема лежит в архитектуре.

Решение появляется только после того, как данные складываются в общую картину.

Такой взгляд согласуется и с подходом DORA к оценке эффективности поставки ПО. В нем скорость изменений рассматривается вместе со стабильностью, а авторы отдель. С QA работает та же логика. 95% успешно пройденных тестов или 80% автоматизации хорошо смотрятся на дашборде, но мало говорят о способности компании быстро и безопасно менять продукт.

QA может заметить проблему раньше бизнеса

Проблемы с качеством не возникают вместе с большим красным индикатором на дашборде, все происходит постепенно.

После небольших изменений приходится запускать чуть больше тестов. Регрессия понемногу растет. Один компонент второй или третий раз становится причиной проблемы после релиза. Команде все чаще приходится выпускать срочные исправления. Часть спринта начинает уходить на работу, которой не было в плане.

Каждый отдельный эпизод выглядит вполне буднично.

Через несколько кварталов оказывается, что функцию, которую раньше выпускали за месяц, теперь делают полтора. Потом начинают расти оценки. Еще позже возникает вопрос, почему команда стала больше, а скорость развития продукта почти не изменилась.

На уровне бизнеса проблема становится заметной где-то здесь. В данных QA она могла появиться значительно раньше.

Поэтому историю качества полезно рассматривать как систему ранних сигналов о состоянии продукта.

Один сложный релиз может быть случайностью. Если после изменений одного компонента десять релизов подряд увеличивается объем регрессии, перед нами уже закономерность.

Один hotfix — обычная рабочая ситуация. Если их количество последовательно растет несколько месяцев, имеет смысл посчитать, сколько ресурсов команда тратит на незапланированную работу.

Если одни и те же модули регулярно фигурируют в серьезных production-инцидентах, вопрос постепенно переходит из области тестирования в область технологической стратегии.

Благодаря этому Quality Intelligence интересен CTO. Он позволяет увидеть часть проблем продукта до того, как они доберутся до сроков, бюджетов и планов найма.

Из практики: что скрывается за тремя днями регрессии

В одном из проектов «Точки качества» мы работали с цифровыми продуктами крупного российского банка. Перед командой стояла задача повысить производительность тестирования и успевать проводить необходимый объем регрессии.

Было существенное ограничение: из-за требований информационной безопасности специалисты имели доступ только к внешнему контуру банковских систем — пользовательским интерфейсам, анкетам и валидации полей.

Для автоматизации выделили отдельного инженера. В результате автоматизация доступных сценариев позволила сократить время регрессионного тестирования с шести до двух-трех дней.

Это уже хороший результат. Но для разговора о Quality Intelligence интереснее вопросы далее.

Но для Quality Intelligence интересен следующий уровень анализа: понять, как высвободившееся время повлияло на релизный цикл и скорость выпуска функциональности, сохранилась ли прежняя стабильность и где после автоматизации остались самые дорогие ручные проверки.

В рамках опубликованного кейса весь этот набор показателей не измерялся. Здесь они приведены как пример того, какие вопросы позволяют перейти от оценки эффективности QA к оценке влияния на продукт.

Сам показатель «регрессия сократилась с шести до двух-трех дней» важен для QA-команды. Руководителю продукта полезно понять, что компания смогла сделать благодаря высвободившемуся времени.

В этом месте технический результат начинает превращаться в управленческий.

Можно проверить на последних 10–15 релизах

Для первого эксперимента не обязательно интегрировать Jira, Git, CI/CD и мониторинг в единую систему. Возьмите последние 10–15 релизов и соберите по каждому несколько показателей:

Следующим шагом к этим данным уже можно добавить размер изменений, зависимости между компонентами, инциденты после релиза, обращения в поддержку и продуктовые показатели.

Последовательность получается такой:

вопрос → данные → закономерность → контекст → решение.

Если начать с метрик, очень легко собрать несколько десятков показателей просто потому, что технически мы умеем их считать. Если начать с вопроса, то быстро становится понятно, какие данные действительно нужны.

AI здесь пригодится, когда ручной анализ перестанет масштабироваться. Модели могут искать закономерности в тысячах дефектов, релизов и инцидентов, группировать похожие случаи и выявлять аномалии. Но если данные из Jira, Git, мониторинга и системы тестирования невозможно нормально связать между собой, модель получит тот же информационный хаос, с которым до нее работал человек.

Что в итоге

По истории тестирования можно увидеть, где продукт становится дорогим в изменении. По дефектам — обнаружить устойчивые зоны риска. Production-инциденты в связке с продуктовой аналитикой помогают оценить реальное влияние проблем на пользователей. История десятков релизов позволяет заметить тенденции, которые еще не успели проявиться в сроках и бюджетах.

У QA уже есть много информации о том, куда движется продукт. Иногда первые тревожные сигналы появляются там за несколько месяцев до того, как проблема становится очевидной на уровне бизнеса.

Вопрос в том, заканчивается ли эта информация очередным отчетом о тестировании или доходит до людей, которые принимают решения.

Поэтому вместо привычного «сколько у нас сейчас дефектов?» я бы время от времени задавал команде другой вопрос:

что данные о качестве уже сегодня говорят о том, каким наш продукт станет через год?