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

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

По-перше, не розпорошуйтеся на дрібниці

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

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

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

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

[highlight dark=”no”]Помилка, за виправлення якої варто боротися, - це помилка, з якою може зіткнутися користувач і яка може суттєво вплинути на нього.[/highlight]

Показати помилку в дії

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

Розкажіть про свій користувацький досвід

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

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

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

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

Виділіть потенційний вплив помилки на всю команду

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

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

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