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

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

Якому правилу це суперечить?

1. Невідповідність вимогам;
2. Порушення стандарту.

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

Чи варто це виправляти?

Іноді недосвідчений QA може задатися питанням, чи варто заходити так далеко, щоб знайти рішення.

Відповідь, напевно, так. Але за умови, що:

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

Якщо ви відчуваєте, що не можете зробити це добре, можливо, не варто навіть починати.

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

Використовуйте перевірочні запитання

Приклад
Ви працюєте в компанії з тестування програмного забезпечення, тестуєте веб-сайт і знаходите одне непрацююче посилання в меню. Що ви будете робити далі?

• Зробіть скріншот цього посилання? Фотографію мишки, яка натискає на непрацююче посилання? А потім внесіть всі фото і текстові дані в систему баг-трекінгу.
• Проаналізуйте, чи має бути посилання саме в цьому місці. Якщо так, то куди воно має вести? Потім ви робите примітку в баг-звіті, де пояснюєте, на якій саме сторінці ви знайшли помилку і за яким пошуковим запитом її (посилання) можна знайти в коді.
• Ви вивчаєте HTML-розмітку, запитуєте права адміністратора для доступу до файлів на продакшені та змінюєте досягнуте.
• Code, а потім випустіть новий HTML-документ.

Який висновок можна зробити?

Дотримуйтесь золотого правила 80-20, коли 20 відсотків зусиль приносять 80 відсотків прибутку.

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

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

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