Локалізація дефекта та його повторне відтворення

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

Визначення дефекту.

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

Якщо ви виявили баг, не варто негайно заводити його в баг трекер з описом «нічого не працює!». Відтворіть дефект повторно. Знову відтворюється? А тепер мінімізуйте кількість кроків для відтворення, та переконайтесь, що немає нічого зайвого.

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

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

Щоб заводити дефекти правильно, необхідні технічна кваліфікація та розуміння архітектури продукту, що тестується. Якщо ми говоримо про веб-тестування, то слід вказати в баг-репорті код помилки, який повертає сервер, подивитись подробиці за допомогою «Firebug» та надати детальну інформацію.

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

По-перше, ви повинні бути впевнені в тому, що насправді виконуєте ті ж кроки, що й минулого разу. Можливо щось було упущено.

Основні причини, чому дефект не відтворюється повторно:

1. Дефект відтворюється тільки при першому запуску додатка. Для повторного відтворення необхідно знову виконати інсталяцію додатка.
2. Використовуються старі дані системи, в які не були внесені зміни в процесі тестування.
3. Швидкість відтворення дефекта. Швидкість виконання кроків для відтворення повинна бути ідентичною.

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

• версію системи;
• версію компонентів;
• стан системи та даних.

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

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

• Скрінкаст (англ. screen - екран,  broadcasting - трансляція) – це запис відеозображення з екрана комп’ютера чи іншого цифрового пристрою. Це один із найбільш ефективних варіантів поділитися тим, що відбувається на екрані монітора. Таким чином тестувальнику легко наочно показати помилки в роботі будь-якого програмного продукту. Знімають скрінкасти спеціальними програмами, наприклад: Snagit, Movavi Screen Capture, Jing, Reflector, ADB Shell Screenrecord, AZ Screen Recorder.
• Live-логування – це зняття системних логів в режимі реального часу. Лог-файли (журнал подій, Log) - це файли, що містять системну інформацію роботи сервера або комп’ютера в хронологічному порядку, в які вносяться певні дії користувача або програми. Для цього можуть використовуватися наступні програми: Visual Studio для Windows, iMazing для iOS, XCode для MacOS, Android Debug Monitor для Android.
• Створюйте нотатки. Зберігайте все, що ви знаєте про дефект, який виник. Тоді вся потрібна інформація буде у вас під рукою, коли ви підключите розробників до роботи над цією проблемою.
• Рекордер дій. Існують програми, які дозволяють повторювати всі записані рухи мишки та дії, виконані на клавіатурі ПК. Прикладом такої програми є Advanced Key and Mouse Recorder. Нажаль даний метод актуальний лише для десктопних платформ, для мобільних платформ аналогічних програм поки що немає.

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

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

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

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

У випадках, коли здається, що помилку відтворити неможливо, необхідно:

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

Корисно також використовувати деякі наслідкові методи виконання тестування програмного забезпечення. 

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

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