Методи оцінювання тестів у тестуванні програмного забезпечення
Томас Гамільтон
⚡ Розумний підсумок
Методи оцінки тестування програмного забезпечення приблизно показують, скільки часу триватиме тестування та скільки воно коштуватиме. Чотириетапний процес — розбивка завдань, призначення відповідальних, оцінка зусиль та затвердження із зацікавленими сторонами — перетворює розпливчасті терміни на обґрунтований план, який може затвердити керівництво.
Що таке тестування програмного забезпечення?
Оцінка тестування програмного забезпечення – це управлінська діяльність, яка приблизно визначає, скільки часу займе завдання тестування та скільки воно коштуватиме. Створення достовірної оцінки тестування є одним із найважливіших обов'язків у управління тестами оскільки це впливає на рішення щодо графіка, бюджету та ресурсів.
Чому оцінювання тестів має значення
Клієнти завжди ставлять два питання перед підписанням тестового контракту:
Для невеликих проектів на ці питання легко відповісти. Для більшого проекту, скажімо, тестування Guru99 Вебсайт банку — вам потрібна структурована техніка захисту відповіді.
Що оцінити?
- Ресурси: люди, обладнання, приміщення, фінансування та все інше, що потрібно для виконання роботи.
- Час: найцінніший ресурс у будь-якому проєкті — кожен реліз має термін виконання.
- Людські навички: знання та досвід команди. Сильніші тестувальники закінчують швидше, ніж менш досвідчена команда.
- Вартість: бюджет проекту — скільки коштів потрібно для проведення запланованого тестування.
Як оцінити
Поширені методи оцінювання тестування програмного забезпечення:
- Структура розподілу робіт (WBS).
- Триточкова оцінка.
- Широкосмуговий Дельфі.
- Аналіз функціональної точки або точки тестування.
- Метод точок використання.
- Відсотковий розподіл.
- Спеціальний метод.
Чотириетапний процес, наведений нижче, поєднує кілька методів для отримання обґрунтованої оцінки. У прикладі використовується Guru99 Банківське тематичне дослідження.
Крок 1) Розділіть весь проект на підзадачі
Ввімкніть кнопку Структура декомпозиції робіт техніка для розбиття складного проєкту на модулі, підмодулі та, зрештою, найменші значущі завдання. Оцінки набагато надійніші на рівні листків, ніж для нечітких головних проєктів.
Застосуйте техніку, щоб розірвати GuruРозділіть проект 99 Bank на п'ять менших завдань:
Потім кожне завдання розбивається на підзадачі, доки кожен рядок не буде достатньо деталізований для оцінки.
| Завдання | Підзавдання |
|---|---|
| Аналіз специфікації вимог до програмного забезпечення | Дослідіть специфікації вимог. |
| Візьміть інтерв'ю у розробників та інших зацікавлених сторін, щоб дізнатися більше про веб-сайт. | |
| Створіть специфікацію тесту | Розробка тестових сценаріїв. |
| Створіть тестові випадки. | |
| Revпереглядати та редагувати тестові випадки. | |
| Виконайте тестові випадки | Створіть тестове середовище. |
| Виконайте тестові випадки. | |
| Revпереглянути результати виконання тесту. | |
| Повідомити про дефекти | створіть дефект звіти. |
| Повідомте про дефекти. |
Крок 2) Доручіть кожне завдання члену команди
Призначте кожне підзавдання найбільш підходящому відповідальному.
| Завдання | власник |
|---|---|
| Аналіз специфікації вимог до програмного забезпечення | Усі члени команди |
| Створіть специфікацію тесту | Тестер / Тестовий аналітик |
| Створіть тестове середовище | Адміністратор тестування |
| Виконайте тестові випадки | Тестер, адміністратор тестування |
| Повідомити про дефекти | Тестер |
Крок 3) Оцінка зусиль для кожного завдання
На цьому етапі добре працюють дві взаємодоповнюючі методики:
- Метод функціональних точок.
- Триточкова оцінка.
Метод 1) Метод функціональної точки
Менеджер тестування оцінює розмір, тривалість та вартість для кожного завдання.
Крок A) Оцінка розміру завдання
Візьмемо завдання «Створити тестову специфікацію». Її розмір залежить від функціонального розміру тестованої системи — чим більше функцій, тим складніша система. Функціональні точки зазвичай класифікуються на три групи: складні, середні та прості.
Залежно від складності, менеджер тестування призначає вагу кожній функціональній точці:
| Group | Зважування |
|---|---|
| Комплекс | 5 |
| Medium | 3 |
| простий | 1 |
Команда GuruВебсайт банку 99 поділено на 12 функціональних пунктів. Їх складність коротко описана нижче.
| # | Модулі | Відповідні ролі | Опис | Зважування |
|---|---|---|---|---|
| 1 | Запит на залишок | Менеджер, клієнт | Customer: переглядати лише баланс власних рахунків. Менеджер: переглядати баланс кожного клієнта під наглядом. |
3 |
| 2 | Переказ коштів | Менеджер, клієнт | Customer: переказувати кошти з власного рахунку на будь-який рахунок. Менеджер: переказувати кошти з будь-якого джерела до будь-якого пункту призначення. |
5 |
| 3 | Міні -заява | Менеджер, клієнт | Останні п'ять транзакцій по рахунку. Customer: переглядати лише власні облікові записи. Менеджер: переглянути будь-який обліковий запис. |
3 |
| 4 | Індивідуальна заява | Менеджер, клієнт | Фільтровані транзакції за датою або сумою. Customer: лише власні рахунки. Менеджер: будь-який обліковий запис. |
5 |
| 5 | Змінити пароль | Менеджер, клієнт | Customer: змінити власний пароль. Менеджер: змінити власний пароль (не пароль клієнта). |
1 |
| 6 | Новий клієнт | менеджер | Додавайте та редагуйте дані клієнта (адресу, електронну пошту, телефон). | 3 |
| 7 | Новий акаунт | менеджер | Ощадний та поточний рахунки; клієнт може мати кілька кожного типу. Менеджер додає нові рахунки для існуючих клієнтів. | 5 |
| 8 | Редагувати обліковий запис | менеджер | Редагувати дані існуючого облікового запису. | 1 |
| 9 | Видалити аккаунт | менеджер | Видалити існуючий обліковий запис клієнта. | 1 |
| 10 | Видалити клієнта | менеджер | Видаляйте клієнта лише тоді, коли немає активних облікових записів. | 1 |
| 11 | Депозит | менеджер | Внесіть готівку на будь-який рахунок у відділенні. | 3 |
| 12 | Вивід | менеджер | Знімайте готівку з будь-якого рахунку у відділенні. | 3 |
Крок B) Оцінка тривалості виконання завдання
Після визначення складності оцініть тривалість, необхідну для тестування кожної групи.
- Загальні зусилля: докладено максимум зусиль для тестування кожної функції веб-сайту.
- Загальна кількість очок функцій: загальна кількість модулів веб-сайту.
- Оцінка на кожну функціональну точку: середні зусилля на очко; залежить від продуктивності команди.
Припустимо, що оцінка команди на кожну функціональну точку становить 5 годин/точкаЗагальні зусилля для GuruПриклад банку 99:
| Group | Зважування | Функціональні точки | Усього: |
|---|---|---|---|
| Комплекс | 5 | 3 | 15 |
| Medium | 3 | 5 | 15 |
| простий | 1 | 4 | 4 |
| Сума балів функції | 34 | ||
| Оцінка за бал | 5 | ||
| Загальна оціночна трудовитрата (людино-години) | 170 | ||
Загальні зусилля для завершення «Створення тестової специфікації» становлять приблизно 170 людино-годинЩойно обсяг робіт буде відомий, можна виділити ресурси для визначення тривалості та вартості.
Крок C) Оцінка вартості завдань
Цей крок відповідає на друге запитання клієнта — «Скільки це коштує?». Припустимо, що середня ставка команди $ 5 / год. Наведене вище завдання займає 170 годин, тому вартість становить 170 × $5 = $850Застосуйте той самий розрахунок до кожного завдання WBS, щоб отримати бюджет проекту.
Чим точніша оцінка, тим краще ви можете керувати бюджетом проекту та гарантувати, що кожен долар принесе користь.
Метод 2) Триточкова оцінка
Триточкова оцінка — це структурований метод, за якого менеджер тестування надає три значення для кожного завдання — оптимістичний, ймовірно та песимістичний зусилля — на основі попереднього досвіду або найкращих припущень.
Для «Створення специфікації тесту» три значення можуть бути такими:
- Кращий випадок: 120 людино-годин (~15 днів) з сильною, досвідченою командою.
- Найімовірніше: 170 людино-годин (~21 день) з типовою командою та ресурсами.
- Найгірший випадок: 200 людино-годин (~25 днів) з менш досвідченою командою та додатковою переробкою.
Обчисліть середньозважене значення за формулою у стилі PERT:
Значення E є середнє зважене — кошторис заголовка для «Створення тестової специфікації».
Висловити впевненість навколо E, обчисліть стандартне відхилення:
Для Guru99 Банківський приклад, за яким виходить оцінка 166.6 ± 13.33 людино-годин — діапазон від 153.33 до 179.99 людино-годин.
Крок 4) Перевірте оцінку
Зібрати всі оцінки завдань з WBS та надати план правлінню (генеральному директору, керівнику проекту, ключовим зацікавленим сторонам) для розгляду та затвердження.
Логічно проведіть дошку по оцінці, щоб вони зрозуміли припущення, обрані методи та враховані вами непередбачені обставини.
Найкращі практики оцінювання тестів
Додати буферний час
Плани рідко витримують контакт з реальністю — члени команди звільняються, тести тривають довше, ніж очікувалося, залежності зникають. Закладіть розумний буфер у кожну оцінку, щоб графік поглинав незначні несподіванки.
Плануйте доступність ресурсів
Враховуйте заплановані відпустки, навчання та чергування. Оцінки, які не враховують доступність, чудово виглядають на папері, але не виконуються належним чином.
Використовуйте минулий досвід як орієнтир
Історичні дані з подібних проектів є безцінними. Якщо ви тестували аналогічний веб-сайт минулого року, враховуйте його фактичні показники, виявлені проблеми та буфер, який врятував становище.
Дотримуйтесь оцінки, але перегляньте її
Оцінки не є обманливимиtracts; це найкращі припущення. RevВстановлюйте їх на відомих етапах та коригуйте лише тоді, коли вимоги суттєво змінюються або нова інформація змінює ситуацію. Прозоро обговорюйте будь-які зміни з клієнтом.
Шаблон оцінки тесту програмного забезпечення
Завантажити оцінку тестування програмного забезпечення у форматі Excel (.xlsx)
Інші методи оцінювання
Окрім WBS, функціональної точки та триточкової оцінки, широко використовується кілька інших методів:
- Широкосмуговий Дельфі: ітеративна консенсусна оцінка групою експертів.
- Метод точок використання: отримує зусилля від кількості та складності випадків використання.
- Відсотковий розподіл: виділяє фіксований відсоток від загальної кількості зусиль проекту на тестування.
- Спеціальний метод: експертна думка, коли відсутні історичні дані.
Оцінювання «знизу вгору» проти оцінювання «зверху вниз»
Практичний погляд на оцінку також розпадається на дві взаємодоповнюючі стратегії:
- Оцінка «знизу вгору»: на основі завдань на найнижчому рівні WBS. Кілька зацікавлених сторін, досвідчених співробітників та учасників об'єднують свої цифри, щоб отримати точний підсумок. Ідеально, коли робота добре зрозуміла.
- Оцінка зверху вниз: класифікує проект за розміром та складністю і порівнює його із завершеними проектами аналогічної форми. Також використовує середні зусилля на тестовий випадок та масштабується за прогнозованою кількістю випадків. Корисно на ранніх етапах проекту, коли деталей недостатньо.
Більшість команд поєднують ці два методи — зверху вниз для загального показника, знизу вгору для впевненості — і накладають результат на складні моделі, коли бюджети виправдовують зусилля.
