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

Сьогодні в рамках рубрики «QA поради новачкам» ми поговоримо про те, як правильно описувати кроки відтворення дефекту (бага).

Кроки відтворення – це інформація, необхідна для відтворення дефекту. Вони повинні бути мінімальними для повторення помилки.

Основні правила опису кроків відтворення дефекту (бага):

Кроки для відтворення (англ. Steps to Reproduce, або STR) тісно пов'язані з отриманим фактичним результатом.

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

Структура опису кроків виглядає так:

Як правило, при описі кроків відтворення необхідно відповідати на питання: «Що необхідно зробити?», при цьому не вказувати особисті звертання. Починати кроки слід з дієслова, це акцентує увагу на дії.

Наприклад:

Кроки потрібно вказувати так, щоб кожна людина могла відтворити зазначені дії, тому починати варто з найважливішої дії, наприклад:

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

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

Наприклад:

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

Наприклад, адреса тестової версії такого сайту може виглядати як https://www.rc.site.com/ або https://www.dev.site.com/ і тоді посилання на production версію сайту в першому кроці може тільки заплутати:

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

Саме ж оточення потрібно вказувати в полі «Environment» (Jira) або «Additional information» (Mantis) у вигляді:

Зареєстрований користувач або незареєстрований користувач

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

При цьому не потрібно уточнювати параметри доступу до реальних акаунтів з наступних причин:

• у розробника повинен бути ряд тестових акаунтів в кожному оточенні;
• в 95% випадків дефект відтворюється під різними тестовими акаунтами (дуже рідко потрібен доступ до одного конкретного акаунту);
• в 50% випадків дефект відтворюється для зареєстрованого користувача, але відсутній для незареєстрованого (noname) користувача.

Інші умови, що впливають на опис кроків відтворення дефекту

Іноді для відтворення дефекту потрібен ряд умов (повинен бути створений певний набір тестових даних, користувач повинен володіти особливими правами, система повинна бути приведена в певний стан).

В такому випадку перші кроки можуть бути винесені в блок «Передумови», наприклад:

Кількість кроків відтворення

Правилом гарного тону є опис достатньої кількості кроків для повного відтворення дефекту. Для кожної тестованої системи або веб-сайту кількість пунктів в блоці «Кроки відтворення» може відрізнятися.

У більшості випадків необхідно дотримуватися мінімальної/максимальної межі: від 2 до 7- 8 кроків відтворення дефекту.  

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

Наприклад:

Сподіваємося, що ці міні-правила допоможуть вам якісніше, швидше і професійніше описувати дефекти.

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