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

Здоровий глузд — завше КОРОЛЬ!!! Кожного разу, коли щось робите, переконайтеся, що Ви знаєте, що робите.

    Беручи цитату до уваги — найкращий варіант мати тестовий сценарій (-ї) якому, неначе дорожнім знакам, можна слідувати у процесі тестування системи. Бо щось несподіване станеться рано чи пізно. Так, так!!! Саме тоді почнуться веселощі та «танці із бубном»… і тест план із тестовим сценарієм стануть у нагоді у якості орієнтира.

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

Отже, припустімо… Ви думаєте, що знайшли Bug

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

 ФАКТ: Якщо Ваша помилка не відтворюється, вона ніколи не буде виправлена!

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

ПАМ’ЯТАЙТЕ: Кількість кроків до дії повинна бути мінімальна, перевіряйте аби зайвих маніпуляцій не було.

А ось кілька речей, які Ви повинні пам’ятати перед відтворенням багу:

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

     Починаючи із цього  місця, Ви на 100% впевнені, що знайшли помилку? І як кажуть фахівці QA: “Тільки добре задокументована ​​помилка є помилкою!”, що означає наступний наступний крок — гарно її представити.

Розпочинаєте BUG рапортування з:

Заголовок

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

Мітки / теги

     Мітки / теги теж надзвичайно корисні для фільтрації звітів про помилки, якщо Ви використовуєте JIRA, або схожу систему відслідковування помилок (bug tracking system, або ще називають bug tracking software, bug reporting tools)

     Важливо, попередити всю команду про використовувані Мітки / теги. Хороша практика, узгодити написання усіх великих та малих літер. Приклад, щоб уникнути різнобою: GUI, Gui, gui.

Детальний опис (Description)

     У деяких баг-трекерах поле «Детальний опис» (Description) є, а в деяких — не має. Якщо це поле наявне, опишіть у ньому проблему більш детально — уточніть деталі, які довелося опустити в заголовку.

     Якщо у формі запису про помилку немає окремого поля «Version» (версія продукту, середовища, яке використовується під час тестування), то вкажіть версію тут. Переконайтеся, чи перераховано у списку все що може бути важливим — версію Операційної Системи, версію браузера та, звичайно ж, версію програми, яку тестуєте!

Кроки відтворення багу (Steps to Reproduce)

    Далі вказуйте порядок тестових кроків крок за кроком аби bug було легко відтворити. Хороша практика розбивати кроки відтворення на пункти і підпункти.

Це дає 2 головних переваги:

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

Доречно, прикріпити зображення та Log files і вказати, наприклад:

Крок 2 => Натисніть кнопку => Перегляньте прикріплене зображення.

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

Мова опису у Bug Report -і

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

Що зробили? (Steps required to reproduce the problem)

Де? Що? За яких умов? Коли отримали? (Actual results)

Що очікували отримати? (Expected results)

    Застосовуйте правильну термінологію при використанні назв елементів користувальницького інтерфейсу (editbox, listbox, link, text area, button, menu, popup menu, title bar, system tray і т.д.), дій користувача (click link, press the button, select menu item і т.д.) і отриманих результатів (window is opened, error message is displayed, system crashed і т.д.).

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

ПОРАДА: Перечитуйте ЗАВЖДИ, за собою, те що написали!

URL-адреса

    Якщо Ви тестуєте або використовуєте веб-сторінку, переконайтеся, що Ви вказали правильне посилання в описі помилки. Автоматичне неправильне зазначення URL-адреси нерідко було причиною багатьох проблем у багатьох qa -engineers.

Комбінуйте засоби та інструменти, аби відловити якомога більше багів

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

По одному полю у Bug Report на кожну помилку!

    Часто Ви знайдете декілька проблем на одній сторінці, і у Вас природно виникне спокуса відкрити єдине повідомлення для всіх помилок — не робіть цього! Ймовірність, що програміст розробник побачивши довгий список із 5 багів виправить тільки 3. Решта проігнорує, подумавши, що йдеться про одне й теж. Відкривайте звіт до кожного багу із яким Ви зіткнулися окремо!

Очікувана VS фактична поведінка

    Ясно означає ВАЛІДАЦІЮ, Ви підтверджуєте, що ваші очікування відповідають правильній поведінці продукту. Коротше кажучи, порівняйте як програма має працювати належним чином. Фактична поведінка, тобто розбіжності якраз і визначають проблему.

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

Застосували автоматизоване тестування?

ПЕРЕКОНАЙТЕСЯ: Що Ви не забули вказати використання Вашого автоматизованого скрипта у кроках тестування.  

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

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

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

Використовуйте шаблони Bug Report

     Одним з найбільш корисних речей, які ви можете зробити для своєї команди, є створення Bugs шаблону  у інструменті відстеження дефектів. Це допоможе уникнути забування важливих даних в описі помилок. Фактична / очікувана поведінка зазвичай забувається, разом із середовищем. В інтернеті Ви можете знайти багато прикладів складних детально розписаних bug report шаблонів. Для кращого розуміння ми тут представляємо найпростіший bug report шаблон.

Bug report шаблон
Приклад Bug report шаблону

ПАМʼЯТАЙТЕ: Іншим користувачам, окрім команди QA тестерів, коли вони побачать Bug report повинно бути все зрозуміло без зайвих слів також.

Слідкуйте щоби ступінь серйозності багів встановлювався правильно

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

ДО УВАГИ: У одних програмах деякі дефекти не мають значного впливу на функціональність, але водночас у інших програмах той самий дефект може бути катастрофічним.

     Ступінь серйозності суворості багу встановлюється test engineer, тоді як пріоритет встановлюється product owner and/or scrum master..
Щось на зразок цього:

Запит на нову функцію або зміну функціональності існуючої функції.

     Регулярно перевіряйте помилки, які Ви подали. Якщо вони застрягли в “Відкритому” стані, спробуйте зв’язатися з призначеним розробником і дізнатись, чи йому потрібна допомога у відтворенні знайденого Вами багу. Особливо якщо це критичний баг, переконайтеся, що розробник розуміє терміновість. Крім того, дізнайтеся, чи розробник усвідомлює, чи для нього той баг є помилкою (таке теж трапляється), чи не перебуває у відпустці (у цьому випадку Вам потрібно буде bug перепризначити).

А виправили знайдений Bug?

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

     Зі сторони може виглядати вкрай нудним таке «дотошне до смерті» описування навіть найменшої помилки. Але навички складання баг-репортів приходять з досвідом.

     Щасливого полювання! 

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.