Что является хорошим показателем эффективности тестирования / тестирования?

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

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

Но как насчет тестеров? Наше тестирование в основном основано на требованиях и представляет собой сочетание ручного, полуавтоматического и автоматического тестирования (не потому, что мы не успели все автоматизировать, а потому, что некоторые вещи не автоматизируются в нашей тестовой системе).

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

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

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

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

Есть несколько показателей, которые мы использовали на моей последней работе для оценки QA:

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

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

QA следует измерять двумя основными показателями: сколько ошибок пройдут QA, чтобы найти их в поле? Какова их серьезность?

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

Хотя, в конце концов, я боюсь, что вы потратите больше денег, пытаясь измерить эффективность вашего персонала, работающего по контракту, чем экономию, полученную благодаря использованию персонала, работающего по контракту

Компания, в которой я работаю, использует ряд показателей качества.

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

Что бы вы ни делали, не зацикливайтесь на количестве тестов. Это примерно так же полезно, как LOC в день.

Множество способов измерения производительности на этапах разработки и тестирования во время выполнения проекта. Мы использовали ниже меры в наших проектах. Производительность разработки измеряется 4 популярными метриками кода (индекс сопровождения, циклометрическая сложность, глубина наследования, связи классов). Для C # получит его в Microsoft Visual Studio. Для тестового покрытия очень полезен Ncover / Ndepend. Производительность тестирования измерялась по отсутствию ошибок разработки - за последние 4 спринта. Ошибки системного тестирования - за последние 4 спринта. Не пройдено ни одного теста автоматизации, в частности выпуск / поставка функций.