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

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

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

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

Лише для функціональних помилок ви побачите додаткове поле під назвою Серйозність: низька, висока та/або критична. Рівень серйозності вказує на терміновість вашого звіту та залежить від багатьох факторів. Щоб дізнатися про різні рівні серйозності, перегляньте наступну статтю Функціональні помилки.

Поле Серйозність не відображатиметься для інших типів помилок.

Заголовок звіту про помилку має підсумовувати проблему, щоб читач отримав загальне уявлення про помилку, просто прочитавши назву помилки. Їм не потрібно читати весь звіт, щоб зрозуміти, в чому проблема. Заголовок звіту про помилку має бути точним і водночас не надто довгим. Він має містити інформацію: що це за помилка, де вона сталася та коли вона спрацьовує? Тож, коли ви пишете назву звіту про помилку, завжди пам’ятайте: Що? Де? Коли?

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

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

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

Неправильно: Помилка відображається на сторінці кошика.
​Правильно: «Помилка 500» буде показано на сторінці кошика після того, як користувач натисне кнопку «Оформити замовлення».

Неправильно: Користувач не може додати товар до кошика
​Правильно: "Неочікувана помилка" відображалася на сторінка з детальною інформацією про товар, коли користувач вибрав розмір і натиснув кнопку «Додати в кошик».

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

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

URL-адреса має бути дійсною.

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

ction.

Перший крок має містити вказівку для доступу до URL-адреси цільової сторінки, надану клієнтом у розділі «Доступ», якщо ви тестуєте веб-сайт, або вказівку для відкриття програми (з її назвою), якщо ви тестуєте програму для мобільних пристроїв. Усі подальші кроки мають описувати ваші дії від початкового кроку до того моменту, коли виникає помилка – які кнопки ви натискаєте, за якими посиланнями переходите та що вводите. Ваш останній крок має описати дію, яку ви виконуєте, яка викликає помилку. Пам’ятайте, що «спостереження» — це не дія користувача.

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

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

Що не так із наведеними вище прикладами: перший крок має містити вказівку доступу до URL-адреси цільової сторінки, а не лише саму URL-адресу. Третій крок недостатньо детальний і містить занадто багато дій в одному кроці. Другий і четвертий кроки зайві і не потрібні для розуміння помилки.

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

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

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

Неправильно: Помилка відображається на сторінці кошика після натискання кнопки Оформити замовлення.
​Правильно: Коли користувач додав якийсь товар у Кошик і спробував перейти на сторінку Оформлення замовлення, він помітив, що не зможе цього зробити. «Помилка 500 – Внутрішня помилка сервера – Вибачте, щось пішло не так» буде показано, коли натиснуто кнопку "Оформити замовлення" в меню з правої сторони.
​
​Неправильно: Користувач не може додати товар у кошик, відображається помилка.
​Правильно: Після того, як користувач відкрив сторінку з деталями «Test IO – Product 1», вибрав розмір: 36 і натиснув кнопку "Додати в кошик", у верхньому правому куті з’явиться банер із повідомленням про помилку «Несподівана помилка». PDP, і товар не додається в кошик.

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

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

Неправильно: Користувач може перейти до оформлення замовлення
​Правильно: Після додавання продукту в кошик і натискання кнопки "Оформити замовлення" користувач повинен бути правильно перенаправлений на сторінку "Оформити замовлення", де він зможе додати інформацію про доставку та оплату та оформити замовлення.

​Неправильно: Товар має бути успішно доданий до кошика.
​Правильно: Якщо вибрати розмір: 36 для «Тестовий IO - продукт 1» і натиснути кнопку "Додати в кошик", продукт має бути успішно доданий у кошик. У цьому процесі користувач не повинен зіткнутися з помилками.

Щоб дізнатися, який тип вкладення потрібно прикріпити до вашої помилки та які правила застосовуються, перегляньте таку статтю: Вимоги до вкладень звіту про помилку.

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

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

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

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

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

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