Як оцінити автоматизацію тестування. Методи і приклади

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Привіт, мене звати Артур і я працюю керівником відділу автоматизованого та мануального тестування у компанії Yalantis.

У цій статті я хочу показати вам, як можна проводити оцінювання тестування, які методи можна використовувати та як підготуватися до процесу оцінювання загалом. Але майте на увазі, що кожен проєкт також може мати свої особливості чи підходи.

Почнемо з того, що загалом діяльність з автоматизації тестування можна розділити на 2 фази.

Початкова фаза

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

  • Загальний онбординг — зазвичай 1–2 дні, щоб скласти перше враження про застосунок.
  • Вивчення вимог/ мануалів/ посібників — може тривати до 1 тижня. Зазвичай застосунки мають деякі посібники щодо складних функцій/фіч, як вони працюють та як ми повинні їх тестувати. Колись у мене був проєкт, коли таким посібником до тестування була книга на 300 сторінок 😁.
  • Створення/ оновлення Test Automation Strategy — зазвичай вам буде запропоновано оновити або створити з нуля стратегію автоматизації. Іноді це абсолютно новий артефакт у проєкті, а іноді стратегію автоматизації буде включено до такого артефакту як Master Test Plan. Залежить від правил вашої компанії. Зазвичай займає 6-8 годин.
  • Налаштувати середовище (необов’язковий пункт): це процедура створення середовища для автоматизованого тестування. Іноді цю частину виконує DevOps, але якщо ні — майте на увазі, що для цього вам знадобиться додатковий час. Також вам може знадобитися налаштувати можливість запускати тести в локальному середовищі — зазвичай це може зайняти 3–6 годин у випадках, коли розробники/ DevOps вже підготували скрипти для налаштування всіх сервісів.
  • Написання мокових сервісів/ емуляторів (необов’язково) — іноді вам може знадобитися написати власний mock-сервер або симулятор для якогось IoT-пристрою.
  • Розгортка самого фреймворку — зробіть запуск першого тесту, переконайтесь, що всі залежності оновлені (якщо це треба і не суперечить вимогам безпеки, наприклад), якщо треба — додайте додаткові, перевірте, чи логування та репортинг працюють та чи їх можна запустити на вашій локальній машині, переконайтеся, що можливо запускати тести на різних середовищах, браузерах, пристроях — зазвичай це все займає 4–8 годин.
  • Налаштуйте CI/CD — переконайтеся, що: тести можна запускати з CI, звіт генерується, історія трендів відображається (у випадку Allure Framework Reporting); всі змінні інфраструктури приховано, наприклад, в GitLab envs; тести можна запускати в різних середовищах. Зазвичай для тестів API потрібно 4-6 годин, якщо також планується автоматизація UI — це ще десь 8-10 годин додатково.

Активності in-sprint

На цьому етапі ми автоматизуємо та пишемо тести. Тому візьміть до уваги наступні активності:

  1. Аналіз вимог — зазвичай до 1-2 годин на кожну user-story.
  2. Ручне тестування для випадків автоматизації інтерфейсу користувача (необов’язково) — 1-2 години — щоб краще зрозуміти, як працює функція.
  3. Реалізація PageObjectModel та допоміжних методів — залежить від елементів, які взаємодіють, у разі відсутності ідентифікатора для кожного елемента може знадобитися до 5 хвилин, а для кожного допоміжного методу (клацання, заповнення, очищення, переміщення тощо) — 5-10 хвилин. Отже, у випадку, якщо сторінка складається з 2 кнопок і 2 текстових полів, які можуть містити помилки — приблизна оцінка буде 6*5 + 6*10 + 1 година для ризиків = 2,5-3 години для опису POM за допомогою методів. Крім того, може знадобитися розробка повторюваних/ спільних вебкомпонентів (наприклад, календарів, деяких спеціальних менюшок, компонентів фільтрів тощо).
  4. Розробка API-клієнтів з допоміжними методами — для кожного методу зазвичай потрібно приблизно 1-2 години.
  5. Реалізація DTO/Response Models — залежно від кількості полів і складності об’єкта, який ви використовуватимете — займає приблизно 1-2 години.
  6. Підготовка тестових даних — це, наприклад, створення методів для динамічних і випадкових тестових даних.
  7. Тест дизайн — які тести ви будете автоматизувати і як саме, але без конкретних тестів — 1-2 години.
  8. Розробка та виконання тестових сценаріїв — кожен тест приблизно 10-30 хвилин.
  9. Код ревʼю (необов’язково) — 2-6 годин на user-story.
  10. Розробка допоміжних функцій для мануальних тестувальників (необов’язково) — залежить від завдання, але здебільшого це буде розробка допоміжних методів для API, які можна повторно використовувати з наших тестів. Наприклад, для генерації певного набору тестових юзерів або якихось сутностей — до 2 годин.
  11. Тестовий звіт + Запуск тестів в кінці спринту + аналіз результатів — 1-2 години. Це може включати: створення підсумкових звітів, лінкування скріншотів/ логів, запуск нотифікацій у канали зв’язку про виконання тесту, завершення тощо, а також повторний запуск зафейлених тестів.
  12. Публікація результатів до інструментів ALM (Application Lifecycle Management) — наприклад, JIRA, Team Foundation Server, Polarion за допомогою API або CLI.
  13. Очищення середовища.
  14. Моніторинг логів з продакшену.

Підходи оцінювання в тестуванні програмного забезпечення

Work Breakdown Structure (WBS)

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

Кожен підмодуль, своєю чергою, поділяється на функціональні можливості, а вони — на підфункціональні.

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

3-Point software testing Estimation

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

B = найкраща оцінка (best-case).
M = найімовірніша оцінка (most likely).
W = оцінка найгіршого випадку (worst-case).

B. Оптимальна оцінка: припускається, що такі аспекти проєкту, як наявність висококваліфікованої команди та наявність необхідних ресурсів, все пройде правильно, і проєкт не стикатиметься з блокерами.

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

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

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

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

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

Розрахуємо оцінку:

B, M і W відповідно використовуються для обчислення «E» і «SD».
«E» для оцінки та
«SD» для стандартного відхилення — вимірює невизначеність оцінки
E= (B+4M+W)/6
У наведеному вище прикладі E = (50+(4*70)c+100)/6 = 71,6 людиногодин
SD = (W-B)/6
У наведеному вище прикладі E = (100—50)/6 = 8,3

Таким чином, можна вважати, що найближче наближення для оцінки тестування змінюється в діапазоні від E+SD до E-SD людиноднів. Для наведеного вище прикладу оцінка варіюватиметься від 63,3 до 79,9 людиногодин.

Function Point Analysis (FPA)

Оцінка з точки зору функціональності. Аналіз функціональних точок базується на специфікаціях проєкту або дизайну. Подібно до WBS, завдання поділено на модулі, і кожному модулю надається функціональна точка (FP) залежно від її складності.

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

Total Effort = Total FP x Estimate per FP

Оцінку кожного FP визначає менеджер тестування на основі досвіду та навичок команди з огляду на час, гроші чи розмір. Наприклад, 10 годин/бал або $100 США/бал.

FP для кожного модуля = кількість модулів певної складності x FP цього модуля. Потім додається FP кожного модуля, щоб отримати загальний FP.

Техніка Delphi

Цей метод є методом групового оцінювання та є одним з найпопулярніших, коли оцінки виводяться після кількох раундів оцінювання, яку проводить група експертів. Він має такі кроки:

  1. Експертна група робить прогнози з обґрунтуванням на основі результатів декількох сесій щодо того, скільки годин займе виконання певного завдання чи проєкт під керівництвом менеджера.
  2. Після першої сесії експертам дозволяється переглянути свої оцінки на основі того, як вони інтерпретують відповіді групи, враховуючи судження інших експертів.
  3. Раунди повторюються до зменшення діапазону прогнозів і досягнення середнього значення.
  4. Цей метод простий і надійний, оскільки експерти мають великий досвід у цій галузі. Отримані оцінки за цією методикою відображають консенсусну оцінку групи експертів.

Agile Estimation

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

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

Деякі з широко використовуваних методів гнучкого оцінювання:

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

На початку кожного спринту проводиться оцінка user-story (найменша вимірювана вимога користувача) і визначаються пріоритети. Члени команди використовують колоду карток з числами від 0 до 21 у послідовності Фібоначчі (0, 1, 2, 3, 5, 8, 13, 21). Ці цифри представляють «Story Points».

Модератор зустрічі описує user-story та просить членів аджайл-команди оцінити зусилля приватно, не консультуючись з іншими членами команди. Оцінки проводяться за шкалою Story Points. Потім учасників просять одночасно підняти картку, показуючи зусилля, які, на їхню думку, потрібні для user-story. Цей процес повторюється з обговоренням, доки всі голоси не будуть враховані та обґрунтовані.

Розмір футболки. Іноді для ще більшого абстрагування можна перейти на нечислову систему, як-от розміри футболок: XS, S, M, L, XL тощо, де ці розміри відповідають розміру user-story, на яку учасник оцінює історію.

Це простий, але точний спосіб оцінки зусиль тестування.

Test Case Point Analysis / Test case based estimation

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

В аналізі Test Case Point (TCP) тестові сценарії використовуються як вхідні дані для оцінки результатів тестування. Тестові сценарії класифікуються за складністю. Зазвичай низький, середній, високий і дуже високий.

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

Наприклад, припустимо, що ми повинні оцінити зусилля тестування набору зі 100 тестів:

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

Оцінка на основі історичних даних

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

Цей метод корисний для оцінки проєктів, які мають схожу природу, технічний стек і учасників команди тестування.

Сподіваюсь, після цієї статті ваші оцінки на тестування будуть ще вдалішими й точнішими.

Щасливого тестування :)

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось38
До обраногоВ обраному15
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ще можете прослухати подкаст за участю автора youtu.be/TqYLHU40Dqc

Я б ще додав
— аналіз домену (якщо новий для інженера)
— аналіз архітектури системи, типів комунікацій (синхроний хттп, сокети, черги, БПМС),
— технологічного стеку сервісів та компонент системи
— який реліний цикл кожної компоненти
— які вже є «кволіті гейти»
— які плани по рефакторінгу або вирішеню технічного боргу
— які нові фічі планується розробляти на наступні квартали

Щоб краще оцінити тестування з автоматизацією та описати тестову стратегію, і стек який обрати для автомтаизації 😇

Підписатись на коментарі