У цьому матеріалі спеціаліст компанії Growe на позиції Manual QA розповідає про свій 3-річний досвід в аутсорсингових і продуктових компаніях. Найбільше автора мотивує і «драйвить» процес створення й оптимізації робочих процесів у команді, впровадження нових технологій, ідей та підходів.
Передумовою написання цієї статті було запровадження у моїй команді QA Metrics, тому теоретичний матеріал буде переплітатися із практичним досвідом і робочими прикладами.
Майте на увазі, що метрики поза контекстом – це лише цифри. Щоб правильно оцінити роботу команди, потрібно враховувати специфікацію проєкту, очікувані результати, процеси компанії тощо.
Перед написанням статті я зібрав статистику щодо реального використання QA метрик на проєктах шляхом опитування у LinkedIn, результати якого засвідчили, що тема досить актуальна.
Якщо говорити про мою команду, то ми певною мірою універсали й маємо досвід імплементації таких завдань:
1) розробка інтеграційних функціональностей у core модулі продукту, які при цьому були ускладнені проходженням code contribution процесу із core командами;
2) реалізація задач із backlog відповідно до пріоритетів product команди та потреб бізнесу;
3) розробка архітектури з нуля багатофункціонального back office для потреб усієї компанії.
Важливо зазначити, що ми працюємо за власною змішаною Agile методологією, якою точно не є Scrum або Kanban, тому це завдавало певні обмеження для вибору метрик, необхідних для наших робочих процесів.
Для чого вводяться метрики?
Метрики не дають відповіді на «Що сталося?», а лише «підсвічують» проблему і допомагають:
• оцінити поточну робочу ситуацію у командах;
• своєчасно виявити проблему;
• виявити залежності;
• відслідкувати зміни й тренди;
• коректно розподілити ресурс тестування;
• знаходити точки росту.
До чого потрібно бути готовим під час імплементації метрик?
Під час імплементації команда може думати, що їхню роботу будуть ретельно оцінювати, завзято аналізуючи при цьому будь-які відхилення. Тестувальники зі свого боку можуть намагатися підігнати результати під встановлені метрики.
Як покращити результати після збору метрик?
1. Ротація у продуктових командах. Ротація учасників як між невеликими командами всередині одного департаменту, так і в межах продукту чи компанії в цілому.
2. Оцінка тестування при плануванні спринту. Плануючи черговий спринт, ви можете бути більш підготовленими, заклавши вже виміряну вами оцінку на тестування при оцінюванні загального часу, витраченого на проєкт.
3. Внесення змін у флоу роботи із задачами. Таке рішення ви можете сміливо ухвалити на основі вимірювання метрик. Важливо пам’ятати, що головна мета імплементування метрик – це вимірювання результату й ухвалення рішення для подальших змін, а також прогнозування майбутнього продукту в цілому.
4. Оптимізація процесу тестування. А саме:
- збільшення тестового покриття технічних та бізнес-вимог;
- пришвидшення реалізації фічі, що перебуває на етапі розробки, враховуючи при цьому допустимий рівень якості для конкретного прикладу;
- зменшення витрати часу на тестування внаслідок актуалізації наявних тест с’ютів.
5. Покриття коду автотестами. Тут важливо додати, що:
- автоматизація доречна для тест-кейсів, які є основними для smoke тестування головного функціоналу, окремого модулю або продукту в цілому;
- автоматизація релевантна для тих тест-кейсів, які не підлягають частій зміні логіки у функціоналі;
- у разі достатнього бюджету та часу на автоматизацію, є сенс почати її впроваджувати;
- також є можливість підключення Manual тестувальників до написання автотестів із використанням відповідних інструментів та достатньою компетенцією під наглядом вже досвідченого автоматизатора.
Що я рекомендую вимірювати на проєкті?
Ми з командою вимірюємо такі метрики:
1. QA Metrics щодо задач, повернутих у Re-Open статус. Це допомагає фіксувати задачі, які зі статусу Ready for Testing повертались у Re-Open через недостатній або відсутній опис у задачі, неготовий/незмерджений код або неробоче середовище для тестування. Цю метрику нам було цікаво відслідковувати, щоб зрозуміти поточний стан якості розробки й опису у задачах, які беруться у розробку.
2. QA Metrics щодо дефектів, допустимих для релізу на прод. Ми готові піти у продакшн із наявністю некритичних дефектів і зобов’язуємося виправити їх якнайшвидше. Зазвичай це відбувається протягом 1-2 днів після релізу. У цьому випадку, відслідковуючи вказаний показник, ми хотіли бачити тенденцію зменшення кількості допустимих дефектів для проду.
3. QA Metrics щодо середньої кількості багів у розрізі одного епіку (епік – тип задачі, який створюється у випадку реалізації об’ємної задачі та розбивається на окремі таски для імплементації).
Додатково я роблю вибірку по severity кожного дефекту для більш наглядної статистики. Саме такий вигляд цієї метрики зумовлений особливістю робочих процесів всередині команди. У результаті за наявності великої кількості дефектів в епіку, можна зробити висновки щодо: складності поточного модулю та імплементації задачі, недостатнього рівня експертності розробника у цьому модулі або навіть неточних і невичерпних вимог до задачі.
Кожен виділяє свій перелік метрик, які вважає must have до виконання. Я опишу свій топ, який ви можете або імплементувати у тому вигляді, як він описаний, або ж модифікувати згідно із вашими потребами.
1. Тестове покриття вимог. Ваше значення в ідеалі повинно бути більше одиниці. Чим більше значення, тим краще. Але завжди пам’ятайте, що є достатній рівень покриття вимог, який на кожному проєкті команда визначає самостійно.
2. Щільність дефектів допомагає виявити найбільш проблемні компоненти вашого продукту. У результаті отримаєте певний показник – чим менший він буде, ти безпечніше модуль.
3. Кількість повторно відкритих баг тікетів. Перевідкриття дефектів може статися через неправильний мердж код, затирання змін у гілці, відкат гілки на ранню версію.
4. Velocity роботи команди показує, скільки роботи може виконати команда за одну ітерацію чи спринт. Ця метрика вимірюється у story points.
5. Середній час життя дефекту. Цю метрику також можна додатково сортувати за severity і таким чином це допоможе вам зрозуміти, наскільки швидко ми фіксимо найкритичніші помилки.
6. Кількість дефектів, які були релізнуті на прод або так звану live версію вашого продукту. Метрику використовують після релізу, вона може вимірюватися для кожної версії/ітерації окремо. Чим менший показник, тим краще.
Деякі компанії допускають наявність випуску деяких багів на продакшн. Проте гарною тенденцією є зміна кількості таких багів і зниження рівня severity цих дефектів. Та не варто забувати: відсутність таких дефектів означає лише те, що їх немає у нашій багтрекінговій системі, що не дорівнює відсутності у нашому застосунку взагалі.
Цю метрику я особисто використовую на своєму проєкті, і вона є показником ефективності роботи команди із тестування.
На практиці успішне використання показників якості передбачає досягнення балансу, використання їхніх переваг та усунення недоліків для ефективного управління якістю.
Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!
