Тестові метрики на раз-два-три

Ми в компанії зараз впроваджуємо чітку диференціацію (за кольором штанів, два раза ку) рівня професіоналізму спеціалістів з тестування, або в народі – QA. Й оскільки майже вся професія тестувальника, так чи інакше, про вимірювання, то й відповідним розумінням й певними інструментами для вимірювання володіти – це must. Так, мова саме про метрики в тестуванні. (Але, для визначення рівня професіоналізму – це тільки один з багатьох критеріїв)

Так от, розповім вам коротко й зрозуміло: чим мають відрізнятись метрики для джуна, мідла та сіньйора.

По перше, чим взагалі відрізняються спеціалісти на різних ступенях свого професійного зростання? Рівнем абстракції. Максимально абстрактна відповідь 🙂 яка тим не менш призводить до цілком конкретних відповідей щодо складності задач, рівня відповідальності, розумінням процесу, тощо.
Так само і з метриками (доречі, не тільки в тестуванні): вони розрізняються за рівнями абстракції. Виділимо три рівня абстракції метрик:

1️⃣ Результати. Найнижчий рівень абстракції. Відповідає абсолютним значенням вимірювань тих процесів, або активностей, що вже закінчено. Приклади:
defects # – кількість critical дефектів, що знайдено,
tests # – кількість тестів, що пройдено як passed.
2️⃣ Предикати. Більш високий рівень абстракції. Зазвичай, це похідна, яка допомагає отримувати завчасні попередження. Приклади:
простий) requirements coverage – відношення кількості user story в ітерації, на які написані тести, до загальної кількості user story в ітерації (зазвичай всі леді та джентльмени орієнтуються на значення цього показника в 100%)
складний) defects leakage – відношення кількості дефектів, знайденої на UAT, до суми кількості дефектів, знайденої протягом ітерації перед UAT, та кількості знайдених на UAT (і, наприклад, цей відсоток має бути меншим за 5%, а якщо більше – то десь на дашборді щось засвітиться червоним)
3️⃣ Тренди. Найвищий рівень абстракції (насправді ні). Поєднує в собі два попередні рівні метрик та допомагає відстежувати динаміку змін крізь періоди часу. Приклади:
requirements stability index, вимірюваний протягом 5 ітерацій, порівнюється із defects leakage %, також вимірюваним протягом 5 ітерацій, з метою відшукати кореляцію між цими показниками. Й зазвичай така кореляція існує: чим частіше в середині спринту змінюють/додають/видаляють вимоги, тим більший відсоток багів знаходить не команда тестування, а бізнес користувачі на UAT, або навіть PROD.

Так а що ж там з seniority? – А все просто:
1️⃣ junior – має розуміти та при необхідності впоратись з “результатами”.
2️⃣ middle – знати корисні, розуміти та використовувати “предикати”
3️⃣ senior – добре володіти “результатами” і “предикатами”, та ще й “трендами” не нехтувати собі на розвагу і проекту на користь 🙂

Точних та доречних вам вимірювань!

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

Tags:
7 July 2020
Автор: 
Mikhail Chub

Leave a comment

Leave a Reply