Рівень 10. Практичні аспекти WEB-тестування
Застосунки та плагіни для тестування вебу
Підготовка до тестування. Перш ніж ви зможете розпочати тестування, вам, як і будь-якому професіоналові у своїй справі, потрібні певні інструменти. Як будівельник приходить на будівництво зі своїми інструментами, так і тестувальник підходить до тестування. Встановіть собі всі ці програми та плагіни, щоб озброїтися перед великим ВЕБ-тестуванням. Далі я розповім вам, як ними користуватися.
Встановіть програму й спробуйте в ній розібратися. Вона схожа на вкладку Network в інспекторі Chrome, але має набагато більше функцій. Наприклад, можна обмежити швидкість інтернету.
Показує час завантаження веб-сторінки
- Fire Bug for Firefox
Оскільки стандартний інспектор FF доволі обмежений, тестувальники користуються застосунком-інспектором FireBug. Принцип той самий, що й у веб-інспектора.
Чудова програма, яка перевірить за вас усі посилання сайту
- MeasureIT for FF
Корисний аддон, шкода лише, що тільки для Firefox. Дозволяє точно виміряти розмір компонента в пікселях. Необхідний для перевірки відповідності реальних розмірів макетам.
Інші невеликі корисні для тестувальника застосунки ви знайдете в цьому списку.
Як користуватися веб-інспектором
Тестування веб-застосунків
Кілька тез про тестування веб-застосунків:
Під час тестування веб-застосунків потрібно протестувати:
- Стандартну функціональність
- Конфігурацію та сумісність
- Кросбраузерну підтримку функціоналу
- Виконати всі інші види тестів
Тестування веб-застосунків ускладнюється наявністю розподілених компонентів системи, що взаємодіють із застосунком (клієнта, сервера, мережі)
Помилки (або симптоми імовірних помилок) можна усунути виправленням коду або за допомогою переналаштування системи (клієнта, сервера чи мережі)
Контрольний список веб-стандартів

Вітаю, друже. Як відомо, досвіду професіонала можна досягти лише завдяки відмінній практиці. Сьогодні ми саме цим і займемося. Весь рівень присвячено практиці ВЕБ-тестування. Буде весело! Для початку ось два сайти, які ми тестуватимемо:
http://gorod.dp.ua/ сайт з мережі
http://www.qaacademy.net/ і наш сайт

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

1. Якість коду
Чи валідні (X)HTML-код і CSS-таблиці сторінок сайту?
- Валідний код браузер виведе швидше й краще, ніж невалідний
- Помилки в HTML-коді та CSS-сторінці призведуть до спотвореного відображення документа на екрані
Див. http://validator.w3.org/ (проведення валідації сторінки)
2. Чи добре структурований код сторінок?
- Семантично правильна розмітка передбачає використання html-елементів за їхнім прямим призначенням
- Добре структурований HTML-документ добре сприймається браузерами без підтримки таблиць стилів, текстовими браузерами, кишеньковими пристроями, пошуковими роботами тощо
Див. https://seositecheckup.com/ (перевірка структурованості сторінки)
3. Чи є на сайті «зламані» посилання?
- «Зламані» посилання розчаровують користувачів і потенційно відлякують ваших клієнтів від вашого сайту.
- «Зламані» посилання також можуть вплинути на те, як пошукові роботи індексуватимуть ваш сайт
Зламані посилання бажано перепровірити вручну, щоб переконатися, що це не захист від роботів і що для переходу за посиланням не потрібна авторизація.
Див. http://validator.w3.org/checklink (перевірка посилань)
4. Як у сайту зі швидкістю завантаження сторінок?
- «Не змушуйте мене чекати...» Саме таку думку висловлюють користувачі в усіх дослідженнях. Навіть користувачі з широкосмуговим каналом втомлюються від повільного завантаження. За статистикою, користувачі починають залишати сторінку вже після 5 секунд очікування.
Для цього потрібно встановити застосунок для Chrome/FF — page speed monitor і виміряти за його допомогою час завантаження
5. Чи видає браузер якісь помилки JavaScript під час роботи зі сторінкою?
- Будь-який браузер дозволяє ввімкнути налагоджувач, який виводитиме в консоль помилки щоразу, коли на сторінці виявлено збої або exceptions у JavaScript. Відкриваємо веб-інспектор, переходимо на вкладку console (консоль), серфимо сайтом і перевіряємо, чи не з'являються помилки. Часто веб-баги викидають консольні помилки, за якими програміст або ви зможете зрозуміти причину бага. Консольну помилку завжди заносять у баг-репорт.

Зрозумів, про що йдеться? Не складно? Тоді можемо рухатися далі. Відмінна робота, тестувальнику!
6. Доступність прихованих сторінок для користувачів.
Твоє завдання — перевірити доступність захищених сторінок сайту
а) Для зареєстрованого користувача
б) Для користувача без реєстрації
в) Очистити куки та перевірити відсутність доступу
7. Чи використовується атрибут «alt» у всіх значущих зображеннях?
- Кожен нетекстовий елемент має супроводжуватися текстовим описом. Побачити підпис зображення можна, навівши на нього мишку. Достатньо перевірити до 5 зображень.
Див. також http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-text-equivalent
8. Чи використовуються на сайті для шрифту відносні одиниці виміру замість фіксованих?
- У коді та в таблицях стилів СSS для вказівки розмірів елементів мають використовуватися відносні, а не абсолютні одиниці. Про фіксовані та відносні значення в шрифтах можна прочитати у цій статті.
Див. також http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-relative-units
http://www.webmascon.com/topics/coding/47a.asp
9. Чи змінюється якимось чином компонування сторінки під час збільшення масштабу?
- Компонування веб-сайту в будь-якому браузері за будь-якого збільшення розміру шрифту має залишатися незмінним
- Під час збільшення/зменшення масштабу всі компоненти мають змінюватися пропорційно, усі посилання — залишатися доступними, а кнопки — активними
10. Чи достатньо контрастні та яскраві кольори на сторінках сайту?
- Різниця між кольором фону та кольором тексту має бути достатньо контрастною, щоб не ускладнювати читання
- Не можна користуватися кольорами, що розташовані надто близько один до одного на колірному крузі (оптимально — відстань у ¼ кола)
- Під час перегляду сайту не повинна йти кров з очей, або хоча б колірна гама не повинна викликати психологічний дискомфорт.
11. Чи використовується лише колір для виділення критичної інформації?
- Уся важлива інформація, виділена кольором, має бути виділена й за відсутності кольору, наприклад за допомогою контексту або елементів логічної розмітки
(Застарілий тест, виконуйте на власний розсуд)
Доступність для пристроїв
12. Чи достатньо добре сайт працює і в сучасних, і в старих браузерах?
- Визначтеся, які браузери ви збираєтеся підтримувати і якою мірою. Не всі браузери однаково підтримують різні технології, розмітку тощо. Наприклад, Internet Explorer — це бич усіх розробників. Скажімо, наш сайт не підтримує IE 10 і старіші версії, а також Safari 7.0 і старіші, Opera, а також FF та Chrome старші приблизно за 20-ту версію. У цих браузерах можна побачити дикі, нестримні баги, тож будьте обережні. Проведіть тест в одному з них для наочності.
13. Чи можна працювати з матеріалами сайту за вимкненого CSS або в браузері без підтримки CSS?
- З застосунком можуть працювати люди, чий браузер не підтримує CSS або підтримку CSS вимкнено. Якщо сторінки правильно структуровано, у таких відвідувачів не виникне жодних проблем під час роботи з ними.
14. Чи коректно виглядає сайт під час друку?
- До будь-якого (X)HTML-документа можна прикріпити стиль для друку, і для цього не доведеться чіпати розмітку самого документа. Перевірте, як виглядає сайт під час друку: для цього достатньо під час друку зберегти сторінку як pdf-документ і переглянути його.
15. Чи працює сайт на мобільних пристроях?
- Наразі немає єдності в тому, як кишенькові пристрої підтримують веб-сторінки. Проте деякі рішення в компонуванні сторінок підтримуються на кишенькових пристроях краще, ніж інші. Підтримка кишенькових пристроїв залежить від цільової аудиторії вашого сайту. Перевірте сайт у мобільному режимі Сhrome та в браузері смартфона
16. Чи забезпечено сайт детальним набором метаданих?
- Метадані — дані про дані: каталоги, довідники, реєстри, бази метаданих, що містять відомості про склад даних, зміст, статус, походження, місцезнаходження, якість тощо. Метадані іноді розглядають як різновид давно усталеної практики бібліотечної каталогізації, але це не зовсім так. Скоріше це інформація для інтернет-роботів, пошуковиків та інших класифікаторів сайтів.
Перевіряти наявність метаданих тут:
Див. http://www.seocentro.com/tools/search-engines/metatag-analyzer.html
17. Чи працює сайт у вікнах різних розмірів?
Дуже важлива перевірка. Потрібно переконатися, що верстка сайту коректно все відображає під час зменшення вікна браузера (просто зменшити масштаб, потім зменшити вікно й оновити). Так само під час збільшення вікна на великому моніторі та за наявності прокручування вікна.

Основи веб-юзабіліті
18. Чи є на сторінці чітка візуальна ієрархія елементів?
- Важливу інформацію має бути виділено за допомогою розмірів, відступів і логічних зв'язків.
19. Чи легко відрізнити один рівень заголовків від іншого?
- Використовуйте заголовки, щоб розкрити структуру документів, і робіть це відповідно до специфікації.
Див. http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-logical-headings
20. Чи досить легко зрозуміти навігацію сайтом?
- Навігація вашого сайту має підказувати відвідувачеві, на якій сторінці сайту він зараз перебуває і куди може перейти далі.
21. Чи використовується однакова навігація на всіх сторінках сайту?
- Якщо на кожній сторінці вашого сайту навігація дотримується одного й того самого стилю, відвідувачам буде легше працювати із сайтом, і вони швидше знаходитимуть потрібну їм інформацію.
22. Чи використовується на сайті прийнятна й однорідна мова текстів?
- Ясна й проста мова матеріалів дає змогу ефективно вести діалог із відвідувачем. Не забувайте, що ваш сайт можуть читати користувачі, для яких ваша мова не є рідною.
23. Чи є в сайту мапа та сторінка з контактною інформацією? Чи легко їх знайти?
- Більшості мап сайтів не вдається розкрити багаторівневу структуру архітектури сайту. У тестах на юзабіліті користувачі часто ігнорують мапу сайту або просто не можуть її знайти. Складність мапи також є проблемою: мапа має бути саме мапою, а не головоломкою з навігації.
24. Якщо ваш сайт дуже великий, чи є на ньому інструмент пошуку?
- Для маленького сайту функція пошуку не особливо потрібна. Завжди знайдуться люди, які ніколи не користуються пошуком по сайту. Проте функція пошуку — це додатковий добрий інструмент навігації сайтом для відвідувачів.
25. Чи є на кожній сторінці сайту посилання на його головну сторінку?
- Багато користувачів, зарившись у глибини сайту, хочуть швидко потрапити на його головну сторінку. Головна сторінка — це наче відправна точка для таких користувачів, де вони знову збираються з силами, щоб пірнути в нові глибини сайту.
26. Чи підкреслені посилання?
- Щоб користувачі повністю сприймали посилання, текст посилань має бути оформлений іншим кольором і підкреслений. Відвідувачі не повинні метатися сторінкою в пошуках посилання.
27. Чи чітко виділено кольором посилання, які користувач уже відвідав?
- Найголовніше: якщо посилання, які користувач уже відвідав, чітко виділено, він не натисне на них випадково і не потраплятиме на ту саму сторінку, де вже побував.

Я тут подумав... Магістре, чи не забагато інформації? У мене вже плавляться мізки!
Кожна праця приносить свою винагороду. Нехай сила буде з тобою, майбутній великий тестувальнику!
Як виглядає Agile-дошка на роботі. Дуже зручно прикріплювати на дошку записки із завданнями та відповідальними за них.

Керування сайтом
28. Чи є в сайту зрозуміла й корисна сторінка помилки 404, яка працює з будь-якого рівня сайту?
- Як обробляється помилка 404 (сторінку не знайдено): користувач має знати, що сталося. Відвідувач не повинен «провалюватися в нікуди» і має знати, як вийти з цієї ситуації.
29. Чи використовуються на сайті дружні URL?
- Більшість пошукових серверів (за винятком, наприклад, Google) не індексуватимуть сторінки, в URL яких присутній символ «?» або будь-який інший символ (скажімо, «&» чи «=»).
- З погляду користувацького інтерфейсу найжахливішим є самі URL. Проте якщо вони короткі, логічні та самовиправні (автоматично перенаправляють на «правильні» адреси), з ними стає зручно працювати.
30. Самовиправні URL:
- Користувач браузера може ввести URL-адресу з помилкою, наприклад, замість «google.com» — «googel.com».
- Організації часто реєструють такі домени «з помилкою» і перенаправляють їх на «правильні» адреси.
- Наприклад, адреси «example.com» та «example.net» можуть обидві перенаправляти на єдиний домен або веб-сторінку «example.org».
31. Чи можна отримати доступ до сайту, набравши адресу без «www»?
- Завжди важливо, щоб відвідувач міг набрати назву вашого сайту без «www» і отримати до нього доступ.
32. Чи є в сайту піктограма для закладок?
- Відсутність піктограми для закладок (favicon) — графічного файлу із зображенням у кількох роздільностях — призводить до появи помилок 404, бо такі браузери, як IE, завжди запитують у сервера цю піктограму, коли користувач додає посилання на сайт до закладок. Якщо на вашому сайті цієї піктограми немає, у логи потрапить помилка «404 File not found». Тож наявність такої піктограми допоможе вам значно скоротити розмір файлу помилок.
Ти правий, Обі-Ване. Наш тестувальник усе вивчив, тепер він може спокійно битися з темною стороною веб-помилок!

Уф, важка була тема. Можеш пишатися собою: з цими знаннями ти зможеш здолати темні сили. І протестувати будь-який ВЕБ-застосунок!
Тези про тестування веб-застосунків
1. Коли ми бачимо помилку з боку клієнта, ми бачимо симптом помилки, а не її саму.
Наприклад, у процесі тестування веб-застосунку створюємо новий запис і отримуємо повідомлення про помилку: Microsoft OLE DB Provider for ODBC Drivers error '8004014'.
У процесі досліджень виявляється, що проблема в тому, що JavaScript на боці браузера не активний. Активація JavaScript усуває помилку.
2. Помилки бувають залежними від середовища і можуть не виникати в різних середовищах.
- Наприклад, під час спроби ввійти у веб-застосунок через GPRS-з'єднання зі швидкістю 56.2 кб/с ви отримуєте збої в реєстрації.
- Проте реєстрація в мережі, проведена в такому самому порядку, але з використанням швидкіснішого підключення, пройде успішно
- Отже, маємо помилку, пов'язану з пропускною здатністю мережі
Рекомендації:
Продублювати точну послідовність дій та умови середовища, в якому працюватиме застосунок, згідно з установленими вимогами до нормального середовища застосунку.
Аналіз помилок у веб-середовищі
Оскільки буває складно визначити, що спричинило помилку:
- чи це помилка коду, чи результат збою програмного забезпечення
- проблема в конфігурації з боку сервера
- проблеми несумісності
- проблеми з конфігурацією браузера або щось інше
пропонується проводити аналіз помилок у веб-середовищі методом виключення, тобто спробувати виключити такі моменти:
- Віртуальну директорію веб-сервера (IIS) не було встановлено належним чином
- Директорію застосунку не було сконфігуровано як слід для коректного виконання скриптів
- Веб-сторінку за замовчуванням не було встановлено належним чином
- (SQL-сервер) сервер баз даних неактивний (траплялося часто)
- Об'єкти DLL/COM відсутні або не були успішно зареєстровані
- Налаштування JavaScript на боці браузера було вимкнено
Чому важливо розуміти причину помилки?
Тому що ніхто не любить хибної тривоги. Часто буває так, що тестовий сервер (стенд) не було правильно сконфігуровано, або він дав збій, або відмовила база даних. На відміну від бойового сервера, за ним ніхто особливо не стежить, і часто-густо щось виходить з ладу. Особливо з огляду на часті експерименти та перезавантаження. Важливо не кричати одразу — «шефе, все пропало», а розібратися в причині помилки, адже збої в тестовій системі — це не баги, а проблеми середовища, з якими звертаються до системних адміністраторів, а не до програмістів.
Основні джерела помилок у веб-середовищі

Перед прочитанням слід зрозуміти, що тут помилка ≠ баг. У цьому контексті помилка — це певна проблема тестового середовища, яка заважає процесу тестування. Важливо відрізняти конфігураційні проблеми від реальних багів у системі. Далі докладніше про такі помилки.
Віртуальну директорію веб-сервера (IIS) не було встановлено належним чином:
- Коли віртуальну директорію сконфігуровано неправильно, запитувані файли, скрипти або дані не буде знайдено
- Зазвичай це проблема серверної конфігурації
Директорію застосунку не було сконфігуровано як слід для коректного виконання скриптів:
- Стандартна директорія сервера застосунків містить скрипти, які виконуються, коли їх викликає веб-сервер за запитом клієнта
- З міркувань безпеки веб-сервер можна сконфігурувати так, щоб він або дозволяв, або блокував виконання скриптів у межах окремих директорій
- І якщо сервер застосунків створено таким чином, що він містить скрипти, які підлягають виконанню, а веб-сервер сконфігуровано так, щоб блокувати їх виконання в цій директорії, застосунок не працюватиме
Веб-сторінку за замовчуванням не було встановлено належним чином:
- Веб-сервер не може знайти веб-сторінку за замовчуванням, і застосунок не працюватиме належним чином
SQL-сервер неактивний
- Сервер застосунків потребує підключення до вузла бази даних, розташованого на SQL-сервері, для того, щоб:
- Виконувати запити
- Зберігати процедури
- Отримувати доступ до даних
Якщо службовий процес сервера баз даних не запущено, то, очевидно, застосунок не працюватиме
Об'єкти DLL/COM відсутні або не були успішно зареєстровані
- Наприклад, інсталяційна програма не змогла скопіювати всі DLL-файли, що використовуються сервером застосунків, під час установлення
- Якщо будь-який DLL-файл, потрібний для роботи сервера застосунків, відсутній, застосунок не працюватиме
- Якщо застосунок намагається отримати доступ до COM-об'єкта, який не було успішно зареєстровано, застосунок також не працюватиме
Налаштування JavaScript на боці браузера було вимкнено
- Якщо налаштування JavaScript було вимкнено, то щойно застосунок просить браузер розблокувати JavaScript, виникає помилка
Налаштування браузера. Пошук помилок у скриптах
- Коли виникають помилки в JavaScript, що виконується на стороні клієнта, іноді важко встановити, у якому саме місці сталася помилка. Для полегшення аналізу помилки можна скористатися спеціальним налагоджувачем скриптів
- Для цього потрібно відкрити консоль помилок у браузері (див. навчальне відео)
- Потім потрібно відтворити помилку. Переглянути, які exception (винятки та помилки) виникнуть у консолі. У рядку з помилкою натиснути на посилання на JS-код, у якому виникла помилка.
- У вікні, що відкрилося, один із рядків буде виділено. Саме в ньому й сталася помилка. Скриншот помилки разом зі станом сайту необхідно прикріпити до бага. Також може бути корисним рядок коду, у якому виникла проблема, і повний текст помилки.
Відеозапис пошуку помилки в скрипті
Те чудове відчуття, коли виконав усі лиходійські плани
На що впливають налаштування браузера
У налаштуваннях браузера можна встановити такі параметри:
- Домашня сторінка: задати відображення сторінки під час запуску веб-браузера або під час вибору меню [Home]
- Перегляд: задати умови відображення вмісту сторінки під час її відкриття (зображення, анімації, JavaScript, Flash, заощадження пам'яті) Якщо для параметра [Заощадження пам'яті] встановлено значення [Увімк.], то для відображення веб-сторінки використовується менший обсяг пам'яті. У результаті можна відобразити веб-сторінки, що містять більший обсяг даних, проте якість зображення буде нижчою
- Підключення: задати спосіб вибору підключення, яке використовуватиметься під час
підключення до Інтернету - Проксі-сервер: ввести інформацію про налаштування проксі-сервера, використовувати або не використовувати проксі-сервер
- Cookie: указати спосіб роботи з файлами cookies — усі файли cookie дозволяються або блокуються, або щоразу під час запиту файлу cookie запитується дозвіл чи блокування
- Тимчасові файли: можна встановити розмір пам'яті для тимчасових файлів. Якщо розмір перевищено — файли автоматично видаляються
- Відмова від служби безпеки браузера
Налаштування браузера за замовчуванням
- Якщо проблему спричинено пошкодженими або несумісними параметрами чи додатковими компонентами браузера Internet Explorer, її зазвичай вдається розв'язати скиданням параметрів Internet Explorer
Панель зміни мови
Налаштування кешування
Налаштування вмісту
Налаштування мережі
Налаштування HTTPS/SSL
Які налаштування видаляються під час скидання (Advanced)

Немає часу розслаблятися, попереду на нас чекає ще одна важлива тема.
Огляд браузерів для тестувальника
Вашій увазі пропонується список основних браузерів. Кожен із них має бути встановлений у ВЕБ-тестувальника, це аксіома.
P.S. Версії постійно оновлюються, і вам потрібно мати останню версію браузера
- Google Chrome 49
- Internet Explorer 11/Edge
- Mozilla Firefox 45
- Safari 9.1 / лише MacOS
- Opera 36 / також вибула з числа топ-браузерів
Браузер Opera останнім часом має популярність близько 1% і випадає з підтримки основних ВЕБ-сервісів, що ще більше посилює його відставання.
Safari для Windows більше не підтримується виробником, а отже, не бере участі в тестуванні.
IE 10 і молодші версії Internet Explorer досі мають частку на ринку, що забезпечує розробникам регулярний головний біль, оскільки вони є браузерами з частковою підтримкою (принаймні для Galaxy QA Academy).
Крім того, з'явився новий «супербраузер» від Microsoft. Internet Explorer Edge, що постачається разом із Windows 10. Свіжий головний біль для всіх веб-розробників, бо він підтримує ті веб-технології, які хоче, а ще вам доведеться з'ясовувати: це баг у вашому функціоналі чи в його?
Популярність основних браузерів
Продуктивність браузерів
Напевно, тобі давно кортить дізнатися, який браузер крутіший і яким браузером користуватися як основним для роботи. Давай це з'ясуємо.
Одним із найважливіших параметрів браузерів є швидкість, яка впливає на загальне враження від швидкості роботи програми:
- Швидкість за «холодного» та «гарячого» старту
- Швидкість рендерингу CSS, скриптів, таблиць, графіки
- Швидкість роботи з кешем
- «Холодний» старт. Перше завантаження браузера відразу після старту системи, при цьому спеціальні утиліти попереднього завантаження не використовуються. У тесті визначення швидкодії фору отримує браузер IE, багато компонентів якого завантажуються одночасно з Windows
- «Гарячий» старт. Завантаження браузера вдруге
- Рендеринг таблиць. У цьому тесті вимірювалася швидкість завантаження локальної копії сторінки
- Обробка скриптів. Тест, у якому вимірюються різні параметри: обчислення математичних формул, DHTML-обробка рядка, кешування зображень, швидкість виконання маніпуляцій із таблицями, вікнами та вмістом сторінки
- Показ графіки. Тест показує, як браузер може працювати з безліччю з'єднань одночасно, а також наскільки швидко він здійснює рендеринг зображень
- Робота з кешем. Перевірка роботи браузерів із використанням кешу
Графік продуктивності браузерів
1. Споживання пам'яті ОЗП для 3 вкладок
2. Завантаження процесора % для 3 вкладок
3. Споживання пам'яті ОЗП для 30 вкладок
4. Завантаження процесора % для 30 вкладок
Свіжа інформація на сайті

Практика й тести
Вітаю ще раз, шукачу сили тестування. Як уже казав Чубакка, завдання рівня — пройти ВЕБ-чек-лист для двох сайтів і порівняти, які помилки будуть на кожному з них.
Зверніть увагу, що важливо обґрунтувати кожен із вибраних вами статусів і вказати причину в коментарі. Наприклад: версія для друку виглядає коректно, скриншот http://.... Надішли заповнену таблицю через форму.
І нехай буде з тобою дух тестування. Також гадаю, тобі не складе труднощів після цього пройти теоретичний тест
















