Біль тестувальників, або Чому не всі виявлені баги приймаються до виправлення

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

Привіт, мене звати Ольга і я тестувальниця. Маю 10+ років досвіду. Наразі обіймаю посаду QA TL на проєкті Wix Stores, компанія Wix. Маючи багато бесід зі своїми колегами я помітила одне питання яке часто виникає в тестувальників після важких проєктів — чому не всі знайдені ними баги приймаються на виправлення. На це питання я й спробую відповісти у статті.

Чи було у вас таке, що після довгої та складної роботи ви усвідомлювали, що левову частку виявлених вами багів в результаті ніхто так і не пофіксив? Ви йшли до розробників, пояснювали про свої знахідки. І наче вони ними дійсно переймалися. Продакт-менеджери обіцяли вам розглянути дефекти. Проходив час, ваша фіча потрапляла на продакшен — а разом з нею і ті самі баги, ніби про них всі забули. У мене таке було.

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

Про цей процес і піде далі мова.

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

Почнемо з того, що впливає на рішення, фіксити баги чи ні.

Фактори, що впливають на рішення про фікс багів

1) Стратегія компанії/ проєкта щодо багів

Приклади:

• Zero-bug policy — якщо ваша компанія розробляє ПЗ для медичної сфери;
• фіксимо тільки блокери — якщо це стартап, який тільки намагається вийти на ринок;
• фіксимо функціональні баги, ігноруємо UI — якщо це продукт для внутрішнього використання.

Стратегія може бути прийнята як на рівні всієї компанії, так і на рівні окремого проєкту чи підрозділу.

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

2) Критичність бага

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

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

3) Девелоперські ресурси

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

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

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

4) Складність виправлення

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

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

Може здатися, що складні дефекти будуть увесь час ігноруватися, але ж ні. Критичну проблему можна ігнорувати до певної межі, після якої компанія почне мати збитки. У такому випадку діяти слід наступним чином: після виявлення дефекту відбувається його оцінка. Створюється (за можливості) компенсаційний план для користувачів, а сам дефект додається до планів на наступний квартал, як повноцінна фіча.

5) Наскільки легко баг відтворити

• Баг легко і стабільно відтворюється — ігноруємо цей показник і дивимось на попередні чинники.
• Баг складно відтворити, але він відтворюється стабільно — це може вказувати на граничний випадок, який трапляється рідко і зачіпає незначну аудиторію. Таке зазвичай знижує критичність бага, звісно, якщо це не дефект, який афектує бізнес-користувачів.
• Баг складно відтворити і він відтворюється випадково або зрідка (ми не можемо визначити точний сценарій) — тут знову ж таки треба дивитися на критичність дефекту і скільки часу девелопер може витратити на дослідження проблеми, щоб знайти першопричину.

6) Пріоритети компанії

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

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

Хто приймає рішення про фікс багів

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

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

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

Як стейкхолдери бачать баги

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

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

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

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

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

Оцінка багів за різних обставин

Баги, виявлені під час тестування нової фічі

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

Спринтова пріоритезація багів з беклогу

Баги з беклогу — це технічний борг команди. Під цю задачу як правило виділяють фіксований час, наприклад, 10% від загального часу роботи команди на один спринт. Саме тому треба так пріоритезувати беклог-баги, щоб до спринта на виправлення потрапляли найбільш «болючі» для користувачів.

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

Оцінка багів з сапорт-каналу (скарги користувачів)

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

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

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

У цьому процесі задача тестувальників — надати найактуальнішу інформацію по кожному дефекту і передати її стейкхолдерам для подальшої оцінки.

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

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

Як правильно представляти інформацію про виявлені дефекти

Почну з прикладу.

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

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

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

Чим відрізняється другий опис:

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

Другий наведений приклад свідчить про максимальну критичність дефекту.

Як видно з прикладу, вкрай важливо робити правильні акценти у своєму тест-репорті (по суті, опис бага також є різновидом тест-репорта).

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

Чому деякі дефекти ніколи не будуть виправлені, та чи це справедливо

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

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

У підсумку

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

З досвіду моєї компанії:

• є певні фактори, які впливають на рішення про фікс багів:
  • стратегія компанії щодо багів;
  • критичність бага;
  • дев-ресурси;
  • складність виправлення;
  • наскільки легко баг відтворити;
  • пріоритети компанії.
• Рішення про те, які баги підуть на фікс, приймають стейкхолдери. Найчастіше — продакт-менеджери.
• Продакт-менеджери сприймають інформацію про дефекти з того, як це подають тестувальники.
• Бувають різні ситуації оцінки багів:
  • баги, виявлені під час тестування нової фічі;
  • спринтова пріоритезація багів з беклогу;
  • оцінка багів з сапорт-каналу (скарги користувачів).
• В залежності від ситуації для прийняття рішення використовуються ті чи інші фактори.
• Кількість наявних багів у продуктовій компанії завжди перевищує існуючі дев-ресурси. Для того, щоб розвивати продукт і тримати належну якість, потрібно правильно пріоритезувати виявлені баги.
• У процесі пріоритезації задача тестувальників — надавати найактуальнішу інформацію щодо кожного дефекту.
• Коли тестувальники готують інформацію про дефекти, важливо робити правильні акценти, які допомагають чітко показати критичність дефекту.
• Почуття несправедливості з приводу того, що деякі дефекти ніколи не будуть виправлені, виникає тоді, коли тестувальник задається хибною метою — знайти якомога більше багів і боротися за те, щоб кожен з них пофіксили.
• Правильна мета — надавати стейкхолдерам інформацію щодо стану продукту, його відповідність явним і неявним вимогам, а також повідомити про потенційні ризики. Така мета дозволяє почуттю завершеності і гордості виникати щоразу, як потрібна інформація була надана і відповідним чином опрацьована.