Метрика — це оцінка, яка дозволяє отримати числове значення певної характеристики, а так само це механізм зворотного зв'язку. Багато хто з нас стикався з такими поняттями як «якість» і як її досягти. Як зрозуміти наскільки якісний наш додаток, наскільки якісний процес тестування, наскільки якісний процес розробки і всі подібні питання. Для того, щоб відповісти на них, найчастіше потрібно мати будь-які дані, зібрати показники і порівняти їх з чим-небудь. Все аналогічно процесу тестування. Ми дивимося на наші фактичні результати в певному контексті, порівнюємо їх з певними очікуваними результатами і робимо певні висновки.
Але навіщо? Найчастіше для того, щоб отримати актуальну інформацію та можливість впливати на процес.
Ти не можеш контролювати те, що ти не можеш виміряти
Але де знайти дані? Найчастіше з можна знайти в наступних джерелах (як у очікуваних, так і у фактичних):
- Test Plan
- Test Reports
- Continuous Integration (CI)
- Bug Tracking Systems
- Task Tracking Systems
- Test Management Systems (TMS)
- Test Strategy
Важлива ремарка. Метрик існує величезна кількість, як для тестування, так і для всіх інших аспектів роботи з розробки ПЗ, але в даній статті я зібрав ті, що найбільш часто збираються і корисні в моєму розумінні. Отже, почнемо з найпростішої.
Defect Containment
Defect Containment (DC) або показник стримування дефектів
Визначення: це відношення кількості дефектів, які були знайдені на предрелізній стадії із загальною кількістю дефектів (перед- і пострелізной стадії)
Рекомендуємо курс по темі
Що показує?
Значення якості кінцевого продукту, значення якості тестування.
Типові межі (залежать від програми та «рівня» дефекту):
Критичні дефекти = 0
Major = близько до 0
Minor = «кілька» дефектів допустимо
Decline Rate
Decline Rate (DR) або рейтинг відмов
Визначення: це відношення недійсних дефектів до закритих.
Що показує?
Якість процесу створення звітів про дефекти.
Типові межі:
В ідеальному світі завжди має дорівнювати 0 :)
Оптимістично всього, якщо DR <= 0.2
У реальному світі цей показник часто дуже сильно перевищує 1 :(
Re-Open Rate
Re-Open Rate (ROR) або рейтинг перевідкриттів
Визначення: це відношення перевідкриття дефектів до суми перевідкриття і завданнях дефектів
Що показує?
Тут трохи складніше. Складно інтерпретувати цю метрику при відсутності контексту. Ця метрика може показати:
Якість ремонту дефектів
Якість опису дефектів
Проблеми в процесі в цілому
Якість розробки і тестування
Типові межі:
В ідеальному світі завжди має дорівнювати 0 :)
Оптимістичніше всього, якщо ROR <= 0.1
У реальному світі цей показник часто близький до 0.5 :(
Current Quality Ratio
Current Quality Ratio (CQR) або поточний рейтинг якості
Що показує?
Одна з основних метрик, яка показує якість тестування. Низьке значення служить індикатором проблем в процесі розробки або неправильному розподілі зусиль з тестування. У будь-якому випадку, ця метрика показує, що розробка і тестування — це дві сторони однієї медалі, які не повинні існувати одна без іншої. Ця метрика може показати високу якість розробки і низьку якість тестування, так і навпаки.
Вона показує кількість функціональних областей, які можна успішно демонструвати.
Типові межі: від 5% до 100%
Добре — більше 90%
Терпимо — від 70% до 90%
Погано — менше 70%
Quality of Fixes
Quality of Fixes (QF) або якість починок
Що показує?
Ще одна з основних метрик, яка показує якість тестування. Все вище сказане, в контексті Current Quality Ration, справедливо і для даної метрики.
Може показати проблеми в процесі розробки, кількість раніше працює функціональності і кількість знайдених в ній дефектів.
Типові межі: від 5% до 100%
Хотілося б відзначити, що якщо ви бачите, що в процесі розробки, тестування або будь-якому іншому процесі вашої щоденної роботи відбуваються проблеми — ваше завдання як фахівців із забезпечення якості (а я сподіваюся, що таких більшість), повідомити про це. Метрики — це зручний і об'єктивний інструмент, який дозволить вам це зробити і дозволить бути почутими. Повторюся, їх існує маса. Тому вибирайте показник, який вам потрібен, і вперед — вимірювати якість.
