У компании могут быть десятки QA-метрик и при этом не быть ответа на вопрос: почему продукт становится все дороже и сложнее менять?
Команда знает, сколько дефектов нашла за спринт, сколько ошибок дошло до продакшена, сколько времени занимает регрессия, какой процент сценариев автоматизирован. После каждого релиза появляются новые цифры, графики и отчеты.
А теперь представим продукт, который выпускает релизы раз в две недели. Серьезных дефектов больше не становится, автоматизация развивается, команда укладывается в релизный цикл. На первый взгляд все в порядке.
Но за последний год регрессия заметно выросла. Изменение одного сервиса все чаще требует проверки нескольких соседних. Одни и те же компоненты регулярно всплывают в инцидентах и срочных исправлениях после релиза.
Для QA это дополнительные проверки и знакомые проблемные модули. Для CTO — возможный сигнал, что растет стоимость изменений.
Через несколько кварталов эта история может проявиться уже в сроках разработки. Новые функции станут выходить дольше, оценки начнут расти, а для сохранения прежней скорости понадобится больше людей.
Первые признаки проблемы при этом уже были в данных QA.
Примерно вокруг этой идеи и строится Quality Intelligence.
Что вообще такое Quality Intelligence
За термином Quality Intelligence скрывается практичная идея: данные о качестве могут рассказать о продукте гораздо больше, чем просто показать, насколько хорошо он протестирован перед очередным релизом.
История тестирования, дефекты, изменения компонентов, продакшн-инциденты, обращения пользователей, продуктовые показатели — все это следы того, как система развивается и как она реагирует на изменения. Если смотреть на них вместе и в динамике, можно заметить проблемы задолго до того, как они станут очевидны на уровне сроков, бюджетов или пользовательских жалоб.
Читать далее