В чем ценность QA-метрик? Есть ли смысл тратить усилия на измерение, анализ, проверку, а затем на принятие действий в соответствии с полученными результатами? Тип и необходимость QA-метрик изменились с популярностью и широким распространением методологии разработки программного обеспечения Agile. Когда-то QA-метрики определяли количество выполненных, пройденных или проваленных тестов, но теперь эти метрики не дают существенной пользы для повышения качества тестирования или качества программного обеспечения в релизе. 

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

Проблема с QA-метриками заключается в том, что их трудно выразить количественно, поскольку они в значительной степени субъективны. Кроме того, измерение QA-метрик требует больших затрат ресурсов. Однако для того, чтобы получить представление об эффективности процессов тестирования и разработки, метрики очень важны. Ведь невозможно совершенствоваться, не имея представления о том, с чего вы начали. Agile-команды практикуют непрерывное совершенствование. Без измерения метрик команды и показателей качества у команд нет исходных данных, от которых можно отталкиваться для улучшения.   

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

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

QA-метрика №1 - удовлетворенность пользователей 

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

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

QA-метрика №2 - дефекты, обнаруженные в продакшене после релиза 

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

• Изменение требований или расширение скоупа проекта

• Добавление или удаление не задокументированных фич в рамках связанных сторей 

• Добавление новых функций без задокументированных сторей или требований

• Недостаточная глубина или детальность тестовых кейсов в определенных областях приложения

• Неэффективность или отсутствие покрытия тестами функций серверной части приложения или интегрированных соединений 

• Несоответствие скорости тестирования и его покрытия 

• Различия в инфраструктуре тестовой и продакшен среды 

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

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

QA-Метрика №3 – Тестовое покрытие требований 

Третьим номером в списке 5 лучших QA-метрик является показатель Test Case Coverage. Измерение покрытия тестовыми кейсами означает анализ качества и содержания тестов. Измерение покрытия тестами позволяет убедиться в том, что все стори, требования и критерии приемки охвачены одним или несколькими тестовыми кейсами. Многие организации, занимающиеся разработкой программного обеспечения, допускают ошибку, отождествляя покрытие тестами с количеством выполненных тестов. Количество выполненных тестов полезно только в маркетинговых целях; оно ничего не говорит о валидности тестов или их покрытии по отношению к требованиям. 

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

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

QA-метрика № 4 - дефекты во время спринта 

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

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

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

QA-метрика №5 - соотношение обещанных и выполненных сторей  

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

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

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

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

Получение реальной пользы от QA-метрик 

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

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

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