Методи оцінки часу тестування

Час – це гроші, а дізнатися, скільки часу та коштів знадобиться на тестування продукту, – це один із перших кроків у співпраці з командою QA-спеціалістів. 

Test Estimation – це процес визначення часу, який знадобиться для виконання того чи іншого завдання. Оцінка зусиль тестування є одним із головних і важливих завдань в управлінні тестуванням.

Під час цього процесу оцінюються наступні моменти:

• необхідні ресурси для виконання будь-яких завдань проєкту (сюди можна віднести працівників, обладнання тощо);
• витрати часу на проєкт;
• знання та досвід членів команди (команді, члени якої мають низькі навички тестування, знадобиться більше часу для завершення проєкту, ніж тій, яка має високі навички тестування);
• бюджет проєкту. 

На сьогоднішній день існують десятки методів оцінки проєктів. У нашій статті ми опишемо найпоширеніші методи оцінки, а також їх переваги та недоліки

1. Work Breakdown Structure (структура розподілу робіт)

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

2. Three-Point Estimation (трибальна оцінка)

Суть цього методу полягає в тому, щоб знайти найкращі та найгірші умови роботи для вашої команди. Це статистичний метод, але він також розбиває завдання на підзадачі (на кшталт техніки WBS). Кожну підзадачу потрібно розділити на три можливі сценарії:

1. Ви маєте талановиту команду та всі необхідні ресурси, проблем не виникає, все йде без перешкод, і ви можете виконати завдання, наприклад, за 100 людино-годин (години фактичної роботи людини). Це оптимістичний сценарій (О).
2. У вас хороша команда, достатньо ресурсів і майже все йде правильно, хоча можуть виникнути деякі проблеми, і ви виконаєте завдання за 150 людино-годин. Це нормальний сценарій (N).
3. Команда не має досвіду, більшість ситуацій не відповідає передбаченим сценаріям і вам доведеться вирішувати численні проблеми, а завдання буде виконано за 200 людино-годин. Це песимістичний сценарій (P).

Таким чином, у вас є три значення: O = 100, N = 150, P = 200.

Тепер ви можете обчислити середнє значення для оцінки тесту (E), використовуючи таку формулу:

E = (O+4*N+P)/6

E = (100 + 4 x 150 + 200)/6 = 150 людино-годин

Оскільки середнє значення може дещо коливатися, потрібно розрахувати стандартне відхилення (SD – standard deviation) – межі, в яких E може змінюватися. Формула виглядає так:

SD = (P – O)/6

SD = (200 – 100)/6 = 16,7 людино-годин

Остаточну оцінку можна представити так: команді потрібно 150 +/- 16,7 людино-годин для виконання підзавдання.

3. Function Point Analysis (оцінка функцій за допомогою балів)

Цей метод встановлює оцінку часу залежно від складності завдання (від 1 до 5). Кожному модулю залежно від його складності присвоюються бали (FP – functional points). Прості завдання отримують нижчі бали, складні – вищі. Загальне зусилля розраховується за формулою:

Загальні зусилля = загальна кількість балів x оцінка, визначена для одного бала

Оцінка, визначена для одного бала, – це задане значення, яке визначає керівник QA-команди на основі її досвіду. Воно розраховується з урахуванням часу, вартості або розміру.

Наприклад, оцінка для FP = 100$

Весь проєкт розділений на три групи модулів:

• Комплексні модулі (FP 5) – 2 шт
• Середні модулі (FP 3) – 10 шт
• Прості модулі (FP 1) – 5 шт

Загальні зусилля = 45 x 100 = 4500$

Це означає, що для завершення проєкту вам потрібно 4500$.

FPA не є насправді точним методом, оскільки він пов’язаний з ризиками та може дати дещо помилкові результати.

4. Delphi

Це метод, заснований на комунікації, який спирається на думку експертів команди. Суть полягає в тому, що експертна група під керівництвом керівника обговорює поставлене завдання і робить анонімні персональні прогнози (скільки людино-годин займе це завдання), обґрунтовуючи свою думку.

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

5. Agile

Описані вище методи більше підходять для Waterfall і V-моделі розробки. Вони використовують підхід «знизу вгору», коли всі деталі та вимоги повинні бути визначені, а всі завдання повинні бути оцінені окремо, перш ніж ви зможете спланувати графік і бюджет проєкту. 

Все більше клієнтів і постачальників віддають перевагу використанню методології гнучкої розробки. Agile оцінка принципово відрізняється від традиційних методів і використовує підхід «зверху вниз».

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

Kanban і Scrum – дві популярні методики для гнучкої розробки.

Kanban – це метод візуалізації. Весь робочий процес організовано на канбан-дошці, що дозволяє членам команди відстежувати прогрес і бачити нові функції чи труднощі, щойно вони виникають. Таким чином, команда може визначитися з відповідним навантаженням.

Оцінка тривалості елемента в цьому методі не обов’язкова. Після виконання одного пункту учасники команди просто переходять до іншого. 

Scrum – це каркас для структурування процесу. Використовуючи Scrum, розробники можуть розбити свою роботу на спринти. На початку кожного спринту вони складають плани, оцінюють розмір, керують пріоритетами та прогнозують релізи. В кінці кожного спринту постачається робоче програмне забезпечення.

Правила оцінки

Під час оцінювання часу тестування варто дотримуватися таких правил:

1. Проводити оцінювання згідно з вимогами до програмного забезпечення.
2. Використовувати дані, досвід і знання з попередніх проєктів.
3. Враховувати можливі внутрішні та зовнішні ризики (простій, підвищення кваліфікації, брак ресурсів тощо).
4. Враховувати доступність ресурсів, а також знання та навички команди.
5. Оновлювати оцінку якщо в проєкті відбуваються зміни.
6. Перевіряти оцінку декількома спеціалістами.

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