Специфіка вебтестування UI та розмітки. Поради для початківців

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт! Мене звати Артем, і я Middle QA Engineer у Langate Software. Думаю, ви розумієте, наскільки важливим зараз стало тестування UI та розмітки в цілому, адже воно напряму впливає на продажі, відгуки та статус проєкту. Користувачі сайтів та додатків з кожним роком стають все вибагливішими та прискіпливішими.

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

Трошки теорії

Щоб зрозуміти, чому наш сайт «пливе» або зникла кнопка, варто зрозуміти, а як і з чого будується взагалі вебсторінка. Оскільки ми говоримо про UI та розмітку, ми торкнемося frontend-частини вебсторінки. В основі frontend класичної вебсторінки стоять три «кити»:

  • HTML — це мова розмітки, фундамент усієї нашої вебсторінки, саме тут ми закладаємо наші блоки, текстові поля, посилання та кнопки тощо. Якщо відкрити голий html-файл у браузері, ми побачимо просто набір тексту, посилань і табличок, що йдуть поспіль.
  • CSS — опис зовнішнього вигляду нашої сторінки, ми можемо знайти розміри, кольори, відступи і т.д. Саме при додаванні CSS до html файлу і його відкритті в браузері ми побачимо сторінку адекватного або, майже адекватного, виду.
  • JavaScript — скриптова мова програмування, що дозволяє додати нашому сайту динаміки: анімована карусель картинок, ефектів, взаємодія з користувачем і т.д. Відкривши html файл вже з доданим до нього js ми побачимо повноцінний та зовні гарний результат.

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

Про проблеми та особливості

Для початку — розберімося, в чому ж ключова відмінність вебпрограми від, скажімо, десктопних або мобільних. Я виділив би кілька таких ключових відмінностей:

  • Перша та головна проблема — це мільярд відмінностей у платформі, на якій наш гіпотетичний користувач може відкрити сайт. Це може бути ноутбук, може бути телефон або якийсь тв-бокс, у всіх пристроїв різне залізо, різна роздільна здатність екрана тощо.
  • Продовжується вона браузерами: візьмемо найпопулярніші з сайту StatCounter і отримаємо вже як мінімум 6 штук — Chrome, Safari, Edge, FireFox, Samsung Internet, Opera. Оскільки відображення не повинно змінюватися від використовуваного браузера, це займатиме додатковий час на перевірки. Наведу приклад: колись працював над браузерною грою, і там дуже рідко, але все ж гравці скаржилися на мерехтіння у певному вікні. Через якийсь час ми виловили цей баг — він дуже рідко з’являвся саме у FireFox.

  • Конфігурація — не можна забувати, що багато браузерів мають вбудовані розширення. Наприклад, блокувальник реклами в Opera. Так само встановлені користувачем розширення (візьмемо, наприклад, AdBlock), розширення та інше також можуть вплинути на відображення контенту. Наведу приклад: клієнт скаржився, що у нього не з’являється вікно, що має випадати, але після перевірки на своїх девайсах такої проблеми ми не спостерігали. З’ясувалося, що у клієнта стояв звичайний adblock, який чомусь вирішив, що спливаюче вікно — реклама, і блокував елемент цього вікна.
  • Кількість користувачів — до сайту одночасно може підключатися величезна кількість людей, і навантаження на сервер зросте, відповідно, це впливає на швидкість завантаження не в позитивну сторону.

Якщо зараз, усвідомивши цю інформацію, спробувати уявити кількість комбінацій (браузер + девайс) — стане страшнувато. Навіть якщо ми візьмемо сферичний ПК у вакуумі: платформа Windows, роздільна якість 1080p — це 6 однакових тестів у всіх популярних браузерах, часу на це піде чимало.

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

Вирішити цю проблему покликана технічна специфікація нашого продукту, в ідеалі там буде така необхідна нам інформація: підтримувані браузери, діапазон параметрів, що підтримується. Так, цілком імовірно, що технічної специфікації на проєкті не буде — тоді можна уточнити це питання «на словах». Інакше не можна гарантувати, що якийсь Петя, відкривши наш сайт на xiaomi mi a2 lite, побачить його у належному вигляді.

Кросбраузерність

Зараз поговоримо про браузери. Якщо заглибитися в корінь, не все так страшно і більшість з вищеописаних (за винятком Safari і FireFox) є chromium based, тобто зроблені на основі браузера з відкритим вихідним кодом Chromium. Вони переважно показують контент однаково.

Ще буває, що потрібна сумісність зі старими версіями Internet Explorer, в яких багато нових стандартів html/css/js не підтримуються і видно їх не буде. Це теж бажано уточнювати та звертати на це особливу увагу.

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

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

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

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

Тестування мобільної версії сайту

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

Під час тестування мобільної версії сайту важливо звернути увагу на:

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

Інструменти

Розглянемо, за допомогою чого ми тестуватимемо UI і розмітку, або що нам буде корисно при цьому.

  1. Найголовнішим інструментом для тестування вебу в цілому є браузерні інструменти розробника — Chrome Dev Tools у Chromium based браузерів, Firefox DevTools (очевидно, в якого браузера) і Web Inspector у Safari. Важко переоцінити важливість та корисність даних інструментів. Корисно буде детальніше вивчити їхні можливості, для цього можна скористатися документацією.
  2. BrowserStack і йому подібні можуть допомогти перевірити кросбраузерність та відображення на мобільних пристроях.
  3. Figma якщо її використовують на проєкті — це те місце, де ми можемо порівняти кольори, стилі, розміри тощо; для нас вона стала таким собі стандартом для створення дизайну.
  4. Корисні плагіни:
  • Responsive Viewer — дозволяє порівнювати або перевіряти вебсторінку одночасно на декількох вікнах;
  • PerfectPixel — допомагає протестувати pixel perfect верстку. Дозволяє накласти зображення фоном;
  • Dimensions — включає курсор-перехрестя для перевірки відступів між HTML-елементами;
  • CSS Peeper — такий собі мікроінспектор, корисний для швидкої перевірки елементів і стилів, щоб не лізти в DevTools.

Висновок

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

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
ви розумієте, наскільки важливим зараз стало тестування UI та розмітки в цілому

Взагалі неважливо. Марнотрацтво ресурсів. Тільки якщо продукт — це і є сам UI. Наприклад якась публічна бібліотека компонентів\ui-kit тощо. Тоді так — має сенс.

веб сайти, напевно більше половина IT галузі це написання гівно-сайтів.
так що для таких важливо.

BrowserStack раніше давай можливість користуватися фрі, але зараз то платно. Тому зараз треба обгрунтовати, навіщо він потрібен команді тестування)

Підкажіть як дебажити JS? На практиці ви користуєтесь якимись командами в консолі? Чи пробуєте підставити дані, які виходять за межі валідації?

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

на рахунок данних, так це буде негативний кейс

можна дивитися розмiри за допомогою devtools, але за допомогою perfect pixel одразу видно найменші невідповідності, це просто прискорює перевірки

Підписатись на коментарі