П’ять показників контролю якості, щоб покращити тестування

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

Привіт! Мене звати Андрій Кучеров, я QA Engineer в Uklon. Часто у своїй роботі стикаюсь з потребою мати ефективні способи моніторингу продуктивності команди та аналізу поточного стану справ.

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

Всі розуміють, що тестування є важливим етапом розробки. Проте далеко не завжди компанії або команди міряють саме ефективність якості тестування.

Тож, з якими показниками контролю якості ознайомимося у цій статті?

1. Якість тестової документації.
2. Час на виявлення та виправлення помилок.
3. Охоплення тестових випадків.
4. Надійність тестів.
5. Розподіл дефектів.

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

Якість тестової документації

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

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

Щоб визначити, чи підтримується якість документації на достатньому рівні, дайте відповідь на такі питання:

1. Як часто до мене звертаються із питанням, як працює функціонал?
2. Як часто питають, чи було це протестовано?
3. Як часто виникають питання по написаній документації?
4. Скільки часу я витрачаю на підтримку чеклістів?

Відповідь «Часто» на більшість питань буде вашим знаком про необхідність змін.

Рекомендую оцінити свою документацію за такими критеріями:

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

Для її досягнення:

• НЕ використовуйте сленг, а якщо й використовувати сленгові поняття, то всюди називайте їх однаково і вживайте в однаковому значенні;
• створення короткого опису основних чи складних фічей. В цей опис можна додати головну бізнес-логіку, особливості реалізації й те, що важливо знати при роботі з фічею;
• попросіть людей поза командою оцінити зрозумілість написаного.

2. Структурованість. Це коли в документації є логічне та організоване розташування інформації. Вона допоможе пришвидшити пошуки та розуміння, що до чого відноситься.

Для досягнення:

• завчасно продумайте структуру того чи іншого артефакту і слідуйте йому всією командою;
• слідкуйте за тим, щоб структура та стилістика були безликими, щоб всі писали в одному стилі;
• групуйте документацію за певними параметрами.

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

Для досягнення:

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

4. Актуальність (найважче та найголовніше). Це коли при виникненні змін ви оновлюєте відповідну документацію. Потрібна для того, щоб не виникало питань: «Чи можна довіряти написаному?». Адже якщо довгий час не оновлювати до прикладу регресійні чеклісти, то це як лавина, буде накопичувати час на їх актуалізацію в майбутньому.

Для досягнення:

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

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

Через це команда часто відволікалася і працювала не так продуктивно. Зібравши усі запити, виділив основні проблеми та питання, а потім написав інструкцію (детальну, покрокову, зі скрінами, оскільки цільова аудиторія не є технічним персоналом і може не зрозуміти всіх аспектів).

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

З чого можна почати вже зараз:

• створення невеликих статей для важливого чи складного функціонала;
• розбиття перевірок на дрібніші фічі та групування їх в дочірні папки для розлогішого функціонала;
• наполягати на виділенні часу для актуалізації чеклістів після проведення тестування.

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

Час на виявлення та виправлення помилок

Час на виявлення та виправлення помилок — показник, що відображає життєвий цикл бага, від його внесення в багтрекінгову систему до переводу в статус Closed. Цей показник може бути виміряний від моменту, коли помилка виявлена в процесі тестування, до моменту, коли вона повністю виправлена.

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

Є кілька показників процесу, які можуть кількісно визначити та відстежити те, наскільки швидко та ретельно команда розвʼязує проблеми. Візьміть дату відкриття помилки до часу її вирішення (і проходження перевірки якості) -> розширте показник, щоб увімкнути час від дати відкриття помилки до її взяття в роботу. Це може показати, як довго користувачі чекають виправлення. Помилки можна відфільтрувати за ступенем серйозності.

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

Проаналізуйте, в яких статусах баги перебувають найдовше:

1. Баги довго чекають на те, щоб їх взяли в роботу? Це проблема великої кількості задач, або проставлених пріоритетів. Наполягайте на перегляді скоупів, бо через велику кількість задач баг довго чекає своєї черги. Це може стосуватися як очікування для фіксу, так і очікування для ретесту.
2. Баги довго в розробці/ ретесті? Це проблема розуміння проблематики. Передивіться опис задач, можливо, в них недостатня кількість інформації, що змушує витрачати додатковий час на уточнення.
3. Баги довго затримуються на окремих людях? Це проблема «bottleneck». Передивіться обов’язки людини, їй необхідна допомога. Розподіліть частину обов’язків, щоб у людини була можливість швидше виконувати задачі.

Приклад

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

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

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

Зменшення кількості задач допомогло додавати баги в поточний реліз, а в разі наявності місця для задач — підчищати беклог.

З чого можна почати вже зараз:

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

Охоплення тестових випадків

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

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

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

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

Зазвичай усі критичні шляхи пов’язані з:

1. зростанням та утриманням клієнтів;
2. безпекою користувачів;
3. швидкістю та стабільністю роботи;
4. зручністю та інтуїтивністю інтерфейсу користувача.

Приклад 1

На одному проєкті була проблема приросту кількості звернень у старому функціоналі після деплоїв. На перший погляд, причина очевидна — не догледіли, «не дотестили». Але важливо відповісти на питання «Чому?».

При детальному аналізі звернень і проведених перевірках в смоук-чеклістах ми виявили, що тестування не покривало деякі кейси, які почали використовувати юзери.

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

Приклад 2

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

Потрібне було вирішення проблеми. Створення перевірок для всіх необхідних кейсів заплутало б QA інженерів, а створення окремих чеклістів ускладнило підтримку, оскільки деякі перевірки повторюються.

Виходом з такої ситуації стала traceability matrix з різними умовами для двох різних флоу, що покриває собою всі необхідні перевірки для обох.

Це дає більшу впевненість в смоук тестуванні та зменшує час на проведення смоуку.

З чого можна почати вже зараз:

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

Надійність тестів

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

Надійність тестів — міра того, наскільки точні, стійкі та відтворювані результати тестування.

Критерії для оцінки надійності тестів:

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

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

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

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

• кейси містили в собі декілька перевірок;
• кейси мали заплутаний та незрозумілий опис;
• при додаванні нових полів в запит мали окрему перевірку на поле;
• не врахований час на апдейт чеклістів після релізу.

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

Рішення було знайдене в створенні уніфікованих «стандартів»:

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

Дані «стандартів» дозволили якісніше оцінювати охоплення тестових випадків, полегшили розуміння чеклістів та зменшили час на підтримку тестової документації.

З чого можна почати вже зараз:

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

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

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

Розподіл дефектів

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

На що варто звернути увагу?

1. Скупчення дефектів. Визначте, де найчастіше виявляються баги. Це вкаже вам на те, якому функціоналу потрібно приділяти особливу увагу. Визначити це можна, додаючи до багів індикатор, до якого функціоналу він відноситься. Це може бути лейбл, епік лінк тощо.
2. На якому етапі виявлений баг. Визначає проблематику конфігурацій оточення. Це додасть впевненості, що користувач отримає саме той досвід, який був запланований. Тримайте мінімум одне оточення з налаштуваннями проду. Хай на нього розповсюджуються всі правила деплою та роботи з ним.
3. З якого моменту баги почали накопичуватись. Звужує коло пошуку проблеми, що в результаті допоможе визначити, які саме зміни вплинули на збільшення кількості багів. Додавайте до опису багу версію оточення, білда чи реліза, або будь-який інший індикатор версії.

Приклад

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

Провівши дослідження, стало зрозуміло, що причина багів з’явилась після певного білда. Коли розробники переглянути зміни того білда, вирішили провести рефакторинг коду.

Наявність лейбів допомогла QA звернути увагу на присутність проблеми в певному місці, адже 1-2 баги на реліз не викликає підозр, а от 10 багів на 4 релізи вже змушує замислитись. Присутність версій звузила коло для пошуків.

З чого можна почати вже зараз:

• додавайте необхідні параметри, за якими можна групувати баги;
• проводьте моніторинг кількості багів в певних групах;
• проводьте тестування на енві, що копіює прод.

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

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