Як правильно оформлювати вкладення до баг-репортів на курсах з тестування програмного забезпечення

Вкладення або «Attachments» є одним з головних атрибутів баг-репорту, тому на наших курсах з тестування є ряд вимог до їх оформлення. Дані вимоги є обґрунтованими та відповідають загальним вимогам оформлення баг-репортів на реальних проєктах. Тож давайте розглянемо більш детально, з якими помилками в оформленні вкладень можна зіткнутись під час проходження курсу та як їх уникнути.

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

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

Чому наявність вкладень є обов’язковою?

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

Якщо з обов’язковою наявністю вкладень у баг-репорті розібрались, то як бути з тим, який саме вид вкладень потрібно вибрати для завантаження?

Як визначитися з видом вкладень?

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

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

Прикріплювати даний скріншот у баг-трекері Mantis слід безпосередньо у розділ «Upload Files» баг-репорту.

Нижче наведено приклад правильно оформленого скріншота бага верстки зі зміщеним елементом. 

Summary: The «Email» line is shifted within the width of the «Store Info» section in the footer of the site.

Приклад правильно оформленого скріншота для бага верстки

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

Приклад відео бага, коли доречно додавати саме відео бага

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

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

Приклад бага креша на сайті Amazon

Приклад помилки з кодом відповіді сервера

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

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

Зняття логів у iOS

Зняття логів на Android-пристроях .

На нашому курсі «Тестування: основи і практика» під час виконання домашніх завдань по лекціям 6 чи 7, де можуть зустрітись креші, прикріплення лог-файлів є бажаним, але не обов’язковим.

Щоб завантажити лог-файл, знятий із сайту або застосунку, який тестується, до баг-репорту, потрібно завантажити цей файл на файлообмінник, наприклад Dropbox, Screencast або Google Drive (більш детально про файлообмінники та пов’язані з ними нюанси описано нижче), відкрити доступ перегляду до файлу «Для всіх» та додати посилання на ці логи з файлообміннику в атрибут баг-репорту «Additional information». 

Приклад прикріпленого посилання на лог-файл у баг-репорті в розділі «Additional information», розміщеного у файлообміннику Dropbox

Також важливо не забути додати відео підтвердження аварійного завершення роботи застосунка/гри безпосередньо у розділ «Upload Files», лише одних знятих та прикріплених логів недостатньо.

Як оформити скріншот/відео правильно?

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

1. Зняття скріншотів/відео багів потрібно робити тільки за допомогою спеціальних програм, встановлених на ПК або мобільний пристрій, в залежності від того, на чому тестується продукт. Більш детально про приклади таких інструментів для ПК можна ознайомитись в статті нашого блогу. Не можна робити фото/відео екрану ПК на мобільний пристрій, оскільки це спотворює відображення. Те ж саме стосується і тестування на мобільних пристроях – не варто робити фото/відео іншим пристроєм.

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

Правильні варіанти зняття скріншотів і виділення багів на скріншотах

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

Приклад неправильного скріншота багу без адресного рядка

Приклад правильного скріншота з адресним рядком

3. На скріншоті не повинна відображатись панель закладок браузера, навіть якщо на ній є тільки 1-2 закладки. Дані панелі потрібно вимикати в налаштуваннях браузера. Це також стосується панелі управління Windows, заднього фону робочого столу, вікон програвачів відеофайлів, сторонніх повідомлень – їх не має бути видно на скріншоті/відео з багом. Зайві елементи перевантажують зображення, оскільки в першу чергу кидаються в очі.

Приклади неправильних скріншотів з панелями закладок та панеллю управління Windows

Приклад правильних скріншотів без панелей закладок та без панелі управління Windows

4. На скріншоті має бути відображено лише 1 вкладку браузера – зі сторінкою сайту, на якій знайдено баг. Аналогічно попередньому пункту наявність зайвих вкладок перевантажує непотрібною інформацією, а також незрозуміло, чи є якась із відкритих вкладок пов’язаною з багом (наприклад, коли в кроках відбувається перехід за новими посиланнями).

Приклад неправильного скріншота із зайвими вкладками браузера

Приклад правильного скріншота без зайвих вкладок браузера

5. На скріншоті обов’язково потрібно виділяти елемент з дефектом або саму помилку тільки червоним прямокутником і вказувати на нього тільки червоною стрілкою. Обов’язково має бути і прямокутник і стрілка. Колір виділення елементів на вкладеннях може відрізнятись тільки в одному випадку. Якщо до тестового продукту надається макет (як має бути правильно), то можна зробити складний скріншот з двох простих, де на одному з них буде відмічено тільки зеленим прямокутником і тільки зеленою стрілкою правильний варіант відображення елементу/місця, а на іншому скріншоті буде виділено червоним прямокутником і червоною стрілкою елемент/місце з помилкою. Цих 2 скріншоти слід об’єднати в 1 складний скріншот та прикріпити його до баг-репорту. Не потрібно 2 або більше скріншотів завантажувати окремо до баг-репорту, навіть, якщо вони описують один і той же баг, але в різних браузерах наприклад.

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

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

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

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

Приклад правильно оформленого складного скріншота

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

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

Правильно оформлений складний скріншот бага з трьох браузерів

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

Приклад неправильного виділення на скріншоті (велика кількість виділених елементів з однаковим багом)

Приклад правильного оформлення скріншота з виділеним одним елементом з багом

9. Додавати прямокутник і стрілку потрібно тільки на скріншоти, відео оформлюються без виділень.
10. На відео не має бути жодних сторонніх шумів/звуків, за виключенням ситуації коли потрібно голосом пояснити, що натискається (частіше зустрічається у відео багів на мобільних пристроях під час тестування застосунків).
11. На скріншоті необхідно додавати червону стрілку і прямокутник, використовуючи вбудовані засоби графічного редактора, наприклад, Snagit або інший. В жодному разі не можна малювати прямокутник і стрілку від руки, в таких простих редакторах як Paint, Ножиці. Це виглядає неохайно, непрофесійно і потребує більших витрат часу на оформлення.

Неправильні варіанти виділення багів на скріншотах

Правильний варіант виділення багу на скріншоті

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

Приклад занадто товстого та тонкого виділення багу на скріншоті

Приклад виділення бага в межах здорового глузду

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

Приклад неправильно оформленого скріншота без курсора на елементі з багом «hover state»

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

14. Не можна знімати відео у форматі gif-анімації, оскільки її неможливо ставити на паузу, коли це необхідно під час перегляду. Для перегляду таких відео потрібно більше часу, ніж зазвичай, тому gif-анімації є небажаними. Варто звернути увагу на такі формати відео, як «.avi», «.mp4», «.mkv» та використовувати їх.
15. Під час зняття відео багів на мобільних пристроях потрібно вмикати відображення тапів (жестів) у застосунку, яким знімається відеозапис екрана або ж коментувати голосом, що саме слід зробити, (проте без сторонніх звуків/шумів). Таким чином зручніше і зрозуміліше відслідкувати дії, які виконуються до моменту появи бага та співставити дії на відео з кроками, описаними в баг-репорті.

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

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

16. Якщо зняте відео є достатньо об’ємним і не задовольняє максимально можливий розмір для завантаження файлу в розділі «Upload Files» до баг-репорту, то в такому випадку слід попередньо завантажити дане відео на файлообмінник, наприклад, Dropbox, Screencast або Google Drive, відкрити до нього доступ перегляду «Для всіх» та додати посилання на цей файл в файлообміннику в атрибут баг-репорту «Additional information». Не варто додавати дане посилання в розділ «Activities» під баг-репортом.

Неправильно додане посилання на відео з багом в розділ «Activities» під звітом

Правильно додане посилання на відео з багом в розділ «Additional information», попередньо завантажене на файлообмінник

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

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

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

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