У процесі тестування проекту ми повинні володіти інформацією чи все у нас йде окей, і чи ми рухаємося у правильному напрямку!!! Хіба не так? Логічно? Звідки нам це знати?

Які критерії оцінки? З чим порівнювати? Де узяти той еталон на який орієнтуватися? Яким чином ідентифікувати проблеми і оперативно зреагувати, ще до того як вони стали невиправними? Як зрозуміти, що саме слід покращувати у себе на проекті?

Немає кращого способу аніж обрати відповідний тестовий показник (test metric), визначити його середнє значення та відстежувати прогрес згідно цього показника тестування чи набору показників протягом наступних тижнів, місяців, років.

Отже, якщо коротко підсумувати, метрики потрібні, щоб ефективно управляти проектом:

  • Інформування.
  • Передбачати різноманітні моменти.
  • Розуміти що саме потрібно вдосконалювати?
  • Для оптимізації процесів.
  • Діагностувати проблеми, локалізувати, виправляти і перевіряти їх.
  • Приймати правильні рішення.

Метрики важливі на усьому циклі розробки програмного забезпечення (SDLC). Проте потрібно аналізувати аспект ефективності застосування кожної метрики з точки зору, на якому етапі розробки проекту від отриманої інформації ми отримаємо максимальний результат.

Отже, а Що таке метрики?

Метрика — це міра, яка дозволяє отримати числове значення деяких властивостей ПЗ.

Метрика — іншими словами це показник поточного стану досягнення цілі. Тому що метрики без цілі, заради того аби щось міряти — не мають змісту. Хоча керівництву, клієнтам є до вподоби гарна аналітика, красиві графіки, показники тощо.

Тому правильно враховувати при підборі метрик специфіку проекту (потреби проекту), так званий контекст і орієнтуватись на цільову аудиторію кому ми будемо їх представляти.

Які головні цілі метрик?

  • Зменшити кількість дефектів.
  • Пришвидшити строки релізу.

Test Metrics Life Cycle

Аналіз метрик — на цьому етапі ми ідентифікуємо метрики і показники якості QA які допоможуть нам вирішити задачі і досягти поставлених цілей.

Узгодження — на цьому етапі тест-менеджер пояснює необхідність збору обраного набору метрик зацікавленим сторонам команді і замовнику відповідно.

Оцінка — перевіряємо отримані дані. Обчислюємо значення показників на основі зібраних даних.

Звітування — підсумовуємо наші метрики у репорт. Отримуємо відгуки про те наскільки вони виявились ефективними від зацікавлених сторін.

Наші дії відповідно наступні:

  • Крок #1 Визначити ключові процеси тестування програмного забезпечення, що підлягають вимірюванню.
  • Крок #2 Визначення частоти відстеження та призначення відповідальної особи.
  • Крок #3 Збір Базових показників (дивись нижче що це таке).
  • Крок #4 Обчислення, управління та інтерпретація визначених показників.
  • Крок #5 Визначення точок вдосконалення залежно від інтерпретації метрик.

Типи Метрик

Придумати метрик можна безкінечну кількість, так само їх групувати ми можемо за різними ознаками. Найперше метрики поділяють на Базові (Базові показники/Base Metrics) і Обчислені показники (Calculated metrics).

Базові показники їх ще називають абсолютними — це необроблені дані, зібрані тестувальниками.

  • Загальна кількість Тест-кейсів (Total number of test cases)
  • Кількість пройдених Тест-кейсів (Number of test cases passed)
  • Кількість зафейлених Тест-кейсів (Number of test cases failed)
  • Кількість заблокованих (Number of test cases blocked)
  • Кількість оброблених вимог
  • Кількість знайдених багів (Number of defects found)
  • Кількість прийнятих (Number of defects accepted)
  • Кількість відхилених (Number of defects rejected)
  • Кількість відкладених (Number of defects deferred)
  • Кількість критичних (Number of critical defects)
  • Кількість багів після доставки (Number of bugs found after shipping)
  • Кількість запланованих годин (Number of planned test hours)
  • Number of actual test hour тощо.

Обчислені показники або похідні — виводяться з співвідношення даних, зібраних у базових показниках.

Метрики, які вимірюют результат — переважно це є абсолютні показники, які основною мірою відображають завершення активності / процесу. Приклад: час, необхідний пройти набір тест-кейсів.
Прогнозовані метрики — похідні показники, які виступають як ранні попереджувальні ознаки. Приклад: Діаграма, яка показує швидкість виправлення дефектів привертає увагу команди, якщо швидкість є нижча, аніж потрібна швидкість.

Process Metrics: допомогою можна підвищити ефективність процесу SDLC (життєвий цикл розробки програмного забезпечення)

Product Metrics: стосується якості програмного продукту

Project Metrics: Він може бути використаний для вимірювання ефективності проектної команди або будь-яких інструментів тестування, які використовуються членами групи

Наприклад ще поділяють метрики ручного тестування, автоматизованого.

Групують так би мовити за сущностями та задачами:

Починаючи ще з етапу вимог

Ця група метрик дозволить оцінити, нам якість документації, її складність. Наскільки пропрацьовані вимоги (user story).

Аналіз вимог — у BurnUp. Співвідношення кількості вимог до днів за які вони будуть опрацьовані. Графік, який візуально показує нам настільки швидко ми опрацьовуємо вимоги. Але зверніть увагу, будь-які базові показники добре відображати у такому графіку затрат, що гарно візуально представляється динаміка руху і чи не має просідань?

Вимірювання рейтингу вимог, як кожної окремої вимоги так і набору вимог. Нам потрібно у табличці кожній вимозі проставляти оцінки свої: повнота, характеристика можливості реалізувати ту чи іншу вимогу, характеристика, що ми зможемо вимогу перевірити і у нас є для цього усі необхідні інструменти. Наприклад: R1, R2, R3. Склавши рейтинг ми візуально зможемо бачити, які задачі ми можемо брати у роботу. А які вимоги слід доопрацювати.

Скріншотик з презентації Олексія Баранцева

Ідея наступна, нам потрібно відслідковувати і бачити прогрес, які вимоги у нас повністю опрацьовані, а з якими нам потрібно ще розбиратися.

Метрика покриття вимог = (Кількість охоплених вимог / Загальна кількість вимог)х 100 

Покриття вимог тестами — метрика обраховується дуже просто загальну кількість тестів ми ділимо на загальну кількість вимог. Зверніть увагу деякий функціонал ми не можемо покрити тест-кейсами але можемо покрити тестами дослідницького тестування до прикладу. Покриття вимог тестами = (Загальна кількість тестів/Загальна кількість Вимог)х100 коли ми бажаємо дізнатись показник наш у відсотках.

Наскільки вимоги є взаємопов’язані одна з одною — дана метрика обчислюється як середня кількість зв’язків кожної вимоги з іншими вимогами. Призначення метрики: дати підставу для оцінки термінів тестування і врахування можливих ризиків. Знаючи ступінь взаємного впливу вимог одна на одну можна, наприклад, запланувати додатковий час і кейси для наскрізного тестування, опрацювати регресивні тести, подивитися в бік інтеграції і т.п.

Значення цієї метрики буде коливатися від 0 до 1. 1 означає, що кожне вимога пов’язана, а 0 — що взаємозв’язків немає. Складно вводити якісь обмеження для значень даного коефіцієнта, багато що залежить від специфіки функціоналу, архітектури, технологій. Однак, зверніть увагу на іншу сторону медалі цієї метрики, якщо показник високий, то значить доопрацювання однієї з вимог буде вести до ланцюжка змін, а значить і можливих помилок, в значній частині продукту.

Коефіціент стабільності вимог — призначення метрики показати, як багато вже реалізованих вимог доводитися переробляти від релізу до релізу при розробці нових фіч. Кількість нових вимог повинно переважати над змінними а коефіцієнт бажано повинен бути менше 0,5. В цьому випадку ми впроваджуємо нові фічі в 2 рази більше, ніж переробляємо існуючих.Якщо коефіцієнт вище 0,5, особливо якщо більше 1, то це швидше за все означає, що раніше ми зробили те, що виявилося непотрібним. Команда фокусується не на створенні нових цінностей для бізнесу, а на переробленні раніше випущених фіч.
Також метрика дає уявлення про те, наскільки легко масштабується функціонал системи, додаються нові можливості.

Коефіціент Стабільності Вимог = Кількість змін у вимогах/Загальну кількість вимог реалізованих за ітерацію, включаючи нові

На етапі тест Дизайну

На рівні Тест Дизайнів метрика складності Тест-Кейсів. Скільки кроків містить тест кейс. Ця метрика є надзвичайно важливою у аджайл проектах. Суть її — прорахувати скільки Story-point робить команда за цикл?

Час виконання Тест-Кейсів — естімейти. Коефіціент. Ми можемо порахувати яку кількість тестувальників і якого саме рівня нам потрібно щоб успішно випустити реліз і до якого часу.

На етапі функціонального тестування

На етапі функціонального тестування метриками ми перевіряємо саму якість розробки ПЗ.

  • Щільність Дефектів (Defect Density) —  це кількість дефектів на одиницю або весь продукт, спринт, функцію, об’єм вихідного коду тощо. Ціль знизити тут кількість дефектів.Обчислюється частка дефектів, яка припадає на окремий модуль протягом ітерації або релізу. Призначення метрики: показати нам, яка частина ПЗ є найбільш проблемною. Ця інформація допоможе при оцінці і плануванні робіт з даним модулем а також при аналізі ризиків.Причини великої кількості дефектів у якомусь одному конкретному модулі (коефіцієнт більше 0,3) можуть бути різні: неякісні вимоги, низька кваліфікація розробника, технічна складність і т.д. У будь-якому випадку дана метрика відразу зверне нашу увагу на проблемну зону. Defect Density = Defect Count/Size of the Release/Module
  • Походження Дефектів — Defect Original потрібно позначати на якому етапі виник дефект. На етапі вимог, на етапі архітектури, на етапі кодування тощо.
  • Час життя багу — Defect Life time скільки часу фіксили дефекти. Цей показник важливий для важливих і блокуючих дефектів.
  • Статус Тестового набору — Test Suite Status каже скільки тест-кейсів пройдено скільки зафейлено скільки пасс.
  • Коефіціент Ретесту дефектів — DefectTest Index показує, яку частину в тестуванні займає перепровірка дефектів. Допустима норма коли на кожні 10 нових дефектів повинно бути не більше 1 старого.
  • Час походження дефектів — TC Execution Time характеристикаважлива коли наступить регресія, то ми можемо виміряти скільки часу нам піде на протестовування старого функціоналу.
  • Метрика запровадження і супроводу Ефективність усунення дефектів (Defect Removal Efficiency) — співвідношення пофіксених дефектів до загальної кількості знайдених дефектів.
  • Коефіціент повторно відкритих Багів метрика тестування яка нам надає можливість оцінювати якість, професійність наших розробників, а також у якісь мірі складність продукту або його певної частини. Кількість повторно виявлених багів/Загальну кількість помилок, включно із виправленими
    Дану метрику можна розраховувати для усієї програми, окремого модуля або функціональності. У випадку отримане значення ближче до 0, тим менше при розробці повторюються старі помилки. Якщо коефіцієнт більше 0,2-0,3, це може свідчити або про технічну складність модуля і високу пов’язаність вимог у ньому, або суттєві недоліки в архітектурі, або попередній фікс був зроблений неякісно.
  • Метрика кількості пропущених багів — Defect Leakage небезпечний показник, бо показує скільки ми протустили дефектів і їх просочилось замовнику. Defect Leakage= (Загальна кількість виявлених дефектів/Загальна кількість виявлених дефектів) x 100

Ефективність і якість роботи команди тестування

Завдання цього набору метрик оцінити наскільки якісно тестувальники виконують свої завдання, визначити рівень компетенцій і зрілості команди QA. Володіючи таким набором показників можна порівнювати команду з нею ж самою у різні моменти часу або з іншими, зовнішніми групами тестування.

Швидкість роботи (velocity) команди QA розраховується як відношення реалізованих story points (або вимог, або user stories) за кілька, наприклад, 4-5 ітерацій (Sprint) до кількості обраних ітерацій. Velocity = Кількість story points за N ітерацій/N Призначення метрики виявити можливості роботи команди для подальшого планування обсягу робіт і аналізу трендів її розвитку. Також метрика дозволяє стежити за швидкістю роботи QA, спостерігати за тим, які внутрішні процеси чи зовнішні впливи на команду можуть на цю швидкість вплинути.

Ефективність тестів і тестових наборів — цікава метрика тим що вона є спірною. Відображає як багато помилок в середньому дозволяють виявити тест-кейси. Ця метрика каже про якість тест дизайну.

Найкраще розраховувати дану метрику для всіх наборів тестів, проте не заборонено і по окремому. Кількість виявлених помилок/Кількість тест-кейсів у тестовому наборі

Коефіцієнт помилок, пропущених на продуктив

Реальний час роботи команди QA — призначення метрики збільшити точність планування, а по-друге, відстежувати і керувати ефективністю роботи  команди. Природно, даний коефіцієнт ніколи не буде дорівнює 1. Практика показує, що для ефективних команд він може становити 0,5-0,6. Кількість часу витраченого на цільові QA активності/Загальна кількість часу

Метрика додаткових витрат це витрати часу скажімо на мітинги, налаштування середовища, пусте очікування якогось функціоналу який є ще неготовий до загального часу.

Точність оцінки часу по видам, типам робіт = Оціночний час роботи/Фактичний час роботи виводимо коефіціент який буде у нас підстраховочний, коригувальний до наступних нащих оцінок, щоб вони були точнішими при плануванні.

Частка непідтверджених (відхилених) дефектів = Кількість неприйнятих дефектів/Загальна кількість заведених дефектів. Призначення метрики показати скільки дефектів були заведені «вхолосту». Якщо частка дефектів, які були відхилені перевищує 20%, то в команді може спостерігатися відсутність розуміння, що є дефектом, а що ні або зовсім низькою кваліфікацією QA.

Метрики зворотнього зв’язку

Для кого ми створюємо ПЗ для користувачів. Значить нам потрібно знати наскільки вони задоволені тим що ми для них виробили !!!

Задоволеність користувачів ІТ сервісом
Регулярний опитування задоволеності користувачів сервісом ІТ з виставленням балів.

Призначення метрики: показати, чи довіряють користувачі продукту, наскільки його робота виправдовує їх очікування. Надає можливість дізнатись чи в тому напрямку рухаємося, чи правильно визначаємо важливість фіч і вибираємо варіанти рішень.

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.