Must have при оформленні багів по мобільному тестуванню

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

Оточення (Environment)

Мобільне тестування передбачає декілька варіантів:

• тестування на реальному пристрої (найкращий варіант);
• тестування на емуляторі;
• тестування за допомогою інструментів розробника в браузері.

Розглянемо приклад опису оточення в баг-трекері Mantis при тестуванні на реальному пристрої. У даній системі використовуються такі поля введення: Platform, OS, OS Version. В даному випадку в полі Platform необхідно написати слово «Mobile», в полі OS вказати назву мобільної платформи (Android, iOS), в полі OS Version вказати версію операційної системи.

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

При тестуванні на емуляторі в полі Platform потрібно вказати назву емулятора, в полях OS та OS Version потрібно вказати платформу, яка емулюється, та її версію.

Приклад заповнення полів з оточенням при тестуванні на емуляторі

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

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

Тема (Summary)

Для того щоб розробник по темі баг-репорту зрозумів і звернув увагу на те, що баг знайдений на мобільному пристрої, в нашій компанії прийнято на початку теми вказувати слово [Mobile] та ОС, на якій проводилося тестування.

Наприклад: [Mobile] Android: Клавіатура відображається в портретній орієнтації на формі реєстрації після тапа на поле введення імені в ландшафтному режимі.

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

Кроки відтворення (Steps To Reproduce)

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

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

Додаткова інформація (Additional Information)

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

Приклад заповнення розділу з додатковою інформацією при тестуванні сайту

Приклад заповнення розділу з додатковою інформацією при тестуванні додатка

Прикріплені файли (Attached Files)

Також не потрібно забувати про скріншоти та відео, які демонструють наявність бага. Оформляти зображення потрібно за допомогою червоної стрілки і прямокутника, які акцентують увагу на знайдений дефект. Способи зняття скріншотів на мобільних пристроях докладно описані в лекції 6 курсу «Основи тестування ПЗ».

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