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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на 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% від загального часу роботи команди на один спринт. Саме тому треба так пріоритезувати беклог-баги, щоб до спринта на виправлення потрапляли найбільш «болючі» для користувачів.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У підсумку

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

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

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

Які люди на Доу)) Привіт, Оля)

Мені не пощастило працювати в аутсорсі чи аутстафі

Тонко!

Якщо у вас в команді прийнятно думати, що щось не буде пофікшено ніколи, то це великий такий тривожний дзвіночок для девів. Бо якщо менеджмент/команда забивають на фікс того, що може потенційно подбішувати користувачів (тобто тих, завдяки кому компанія має профіт), то тим паче всі заб’ють на оновлення залежностей, міграцію на сучасніші інструменти чи, прости Господи, рефакторинг (бо профіт з такого далеко не такий очевидний) або автотести. А це призведе до того, що проект скотиться в люте легасі, і ніхто не захоче з ним працювати, хіба за великі гроші й по 2 години на день.
В статті згадувалися стабілізаційні задачі на 10% спринта, але щось в контексті всього, воно виглядає як те, що в ті 10% входить те, що і так мали б пофіксити, щоб продукт був придатний до релізу (типу регресійних багів чи скарг сапорту на щось важливе)

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

що щось не буде пофікшено ніколи

та дофіга такого у беклозі. Як правило фокус ресурсів — на хепі флоу. А вселякі едж кейси з низьким пріоритетом можуть довго залишатись без уваги

Баг складно відтворити і він відтворюється випадково або зрідка (ми не можемо визначити точний сценарій)

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

Дякую за цікавий термін, обовʼязково буду використовувати.

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

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

Я в жодному разі не зневажаю девелоперів, як людей

Взіржав, ото вмієте в полткорректність )
Повернемося до наших гейзенбагів. Там процесс відлову, при розумному підході, досить таки керований, але що цікаво — ітераційний. при цьому часу на те йде небагато. Але необхідна взаємодія між куа та девелопером та вміння зі стороні дева, в першу чергу в постановку задач та гіпотез, та зі сторони куа в корректний збір статистики. По досвіду з куа то проблем практично не було, а ось з нашим братом ....
Там теба щоб дев вмів в теорію досліду, та хоч знав що в H0 0 маленька ).
Та на собесах питають про О а вот про цю ... це треба на парах було хоч слухати, або вміти в саморозвиток )
Ото звідти і росте коріння ігнору )

деякі дефекти ніколи не будуть виправлені

Або буде визваний дядяько(або тіточка) яка прийде та порядок наведе )

ИМХО странно париться что какой-то баг не пофикшен, почему меня вообще это должно волновать?

якщо із-за цього багу клієнт розірве договір, бо втратить багато грошей, а ви втратите свою роботу, ви будете «париться»?

Лол) Если баг не пофикшен, то это решение клиента и он сам на себя берет все риски.

ви втратите свою роботу

ну лол так лол :)))

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

ми женемося не за кількістю, а за якістю

...багів?

Пробачте, не втримавсь :)

а цей вираз також має право на існування. якість бага — то ціле містецтво)

Скорочу до змісту: тому що за політику «сховати голову в пісок» нікого не карають. У стейкхолдерів зазвичай нема компетенції, щоб оцінити ризики та прямий вплив багів. А система зворотного зв′язку, так само як і QA, не мають влади. Через те їх самих розглядають як джерело проблем.

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

грустно наверное работать в компании, где платят зарплату за найденные баги, написанные строчки кода, нарисованные диаграммы, и т.д. )

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