Нічого не забути: універсальна схема для тестування веб-додатків

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

За 12 років у тестуванні було вивчено багато різних технік, методик, випробувано безліч інструментів, але мене не покидало відчуття, що я могла щось упустити, що можна було перевірити глибше. І тут мені знову знадобилася «методика списків», тільки на цей раз мене на цю думку наштовхнув чудовий тестувальник і для мене — гуру тестування, Олексій Лупан. У своєму блозі він якось поділився списками перевірок деяких функцій. З тих пір я веду власні списки, кожен раз доповнюючи їх новими і новими перевірками, тестовими випадками і т. д.

Вже кілька років я навчаю тестувальників і можу вам з упевненістю назвати три найбільш поширених питання своїх студентів:

скільки отримують тестувальники?
які шанси, що мене візьмуть на роботу відразу після навчання?
які технології та інструменти я повинен вивчити?

Перші 2 питання, мабуть, зараз пропустимо :) А ось що стосується третього — моя відповідь завжди ставить їх у глухий кут: «Ніяких конкретно». IT-індустрія — це дуже швидко розвивається сфера, де технології та інструменти з'являються і зникають швидше, ніж ми встигаємо про них дізнатися, вивчити і застосувати. Кількість їх велика, і багато хто просто дублюють один одного, додаючи невеликі плюшки. Тому я не можу їм видати список інструментів і технологій і сказати — ось це панацея.

Якщо ти Java, C#,NET програміст, тобі потрібно знати Java, C#,NET. Якщо ти тестувальник, тобі потрібно знати теорію тестування і те, що буде використовуватися на твоєму проекті.

Я змінила близько 10 проектів, і всі вони були різними — веб, десктоп, ігри, e-commerce. Кожен проект використовував різні технології і вимагав своїх підходів. Тому доводилося навчатися разом з кожним проектом чогось нового. Але у всіх додатків є щось загальне — це принцип роботи і підхід до тестування.

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

Так, а при чому тут списки? — запитаєте ви. А при тому, що якщо взяти цю схему за основу, а потім «нанизати» на неї додаткові перевірки списків — ви отримаєте повноцінну, різнобічну тестування програми і позбудетеся від цього болісного відчуття, що ти щось забув.

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

GUI — >Functional — >Usability — >Security — >Performance (Load/Stress/Recovery) — >Configuration

Розглянемо детальніше:

GUI

GUI — у будь-якого досліджуваного предмета і веб-додатки є зовнішній вигляд, тому тестування графічного інтерфейсу або просто, зовнішнього вигляду — це перше, що ми можемо зробити. Порівняти його з вимогами та/або з форматуванням і все. Або не всі? А як щодо верстки?

Верстка — розміщення елементів веб-додатки (зображення, текст, кнопки, відео...) у відповідності з макетом або вимогами.

Перевіряємо:

наявність всіх елементів;
їх розмір і колір;
розташування відносно один одного.

Всі? — Ні :) У верстки є ще безліч параметрів і елементів, які ми дуже часто забуваємо перевірити.

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

Вимірювання розмірів елемента— якщо це має значення, то поміряти розміри елемента і порівняти їх зі специфікацією можна за допомогою, наприклад Page Ruler .

Правильність шрифтів(назва, розмір, колір) — WhatFont .

Кольори інтерфейсу— ColorZilla .

Контент— перевірити на наявність орфографічних і граматичних помилок (SpellChecker ).

Поява курсору— досить часто ми забуваємо перевірити, з'являється взагалі і як виглядає курсор в полях вводу, на клікабельних елементах.

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

Позначення можливості перенесення елементів.

Кодування(UTF8...).

Стандарти HTML/CSS— досить непогані рішення для швидкої перевірки пропонує W3C .

Заголовкипо всьому додатком повинні бути приведені до одного стандарту (приклад ).

Titleсторінки — про нього ми теж часто забуваємо, також як і розробники :)

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

Масштабованість— особливо це важливо при тестуванні на смартфонах і планшетах. Де користувач часто змінює масштаб екрану (Window Resizer ), а також режим адаптивного дизайну (наприклад FireFox Developer Edition).

Кросбраузерність— одна і та ж сторінка може виглядати по-різному в різних браузерах (приклад ).

Перевіряємо Scroll.

Браузерні розширення, які можуть впливати на зовнішній вигляд програми (наприклад, AdBlock) — пробуємо включити і вимкнути.

Перевірити контент при відключених (режим WebDeveloper ) зображеннях, flash, JavaScript.

Всі? — Ні :)

Локалізація — що ми знаємо про це? Зазвичай наші знання зводяться до невиразним «ну, це мова», «кодування», «розкладка», ще рідше «геолокація». Що ще ми так часто забуваємо перевіряти в рамках тестування локалізації?

Перевіряємо тестовий зразок на правильність перекладу — тут, звичайно, добре б підключити перекладача або носія мови, але за браком таких, беремо тестовий зразок і переводимо через будь онлайн-перекладач (ну і всі ми пам'ятаємо, як прекрасно і весело читати опис товарів російською мовою на AliExpress).
Довжина перекладених слів — кількість символів в перекладеному слові може бути набагато більше (приклад ), що може привести до «розповзання» інтерфейсу при перекладі.
Скорочення/абревіатури — існують правила, за якими їх або перекладають, або транслітерують, або залишають як є.
Валюта.
Параметри шрифту можуть значно відрізнятися в залежності від мови введення.
Перевірити роботу пошуку у всіх локалізаціях — приміром, на AliExpress результати пошуку одного і того ж слова «смартфон» дають різний результат за кількістю знайдених товарів, причому різниця обчислюється десятками тисяч.
Мета-інформація (keywords/title/description) — настільки незначне для користувача, невидиме, але таке важливе для пошукових машин і просування сайту в google та інших пошукових системах.
RTL (right to left languages) — мови c зворотним написанням (арабська, іврит) мають свої особливості: числа пишуться зліва направо, значки та іконки віддзеркалюються, назви програм не переводяться, немає переносів, кнопки редагування Backspace або Delete працюють навпаки.

Functional

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

Визначити основні функції предмета або додатка досить просто — потрібно розуміти його призначення. Задайте собі питання — а для чого потрібен олівець? Фіранка? Інтернет-магазин? Для чого нам на сайті потрібна форма логіну? Для чого нам кнопка «Купити»? І тоді всі функції програми відкриваються, як на долоні.

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

Наприклад:

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

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

Але і тут ми можемо дещо забути. Часто забуваються перевірки функціональних елементів додатка:

Кнопки:

Enter повинна спрацьовувати як submit;
Tab повинен переводити курсор на наступний елемент.

Поля введення:

trimming («забирання») прогалин у полях вводу;
порожнеча/прогалини в поле вводу;
всі способи редагування (Insert, Delete, Пробіл, Ctrl+C/V/X/Z і т. д.);
дробу ( 1.5 | 1,5 | ?).

Пошук:

wildcard symbols (* | ?);
написання пошукового запиту разом | окремо | через дефіс повинно вести до одного результату;
введення тексту в іншій розкладці.

Повідомлення про помилки:

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

Календар:

31 червня;
29 лютого + не високосний рік;
минуле/майбутнє (наприклад, купити квиток на вже минув число).

Час:

синхронізація з сервером (на сервері додатка може бути виставлено інший час, відмінне від таймзоны користувача);
тимчасові зони.

E-mail:

логін (63 символу) @ домен (253 символу (може бути ip)).

Спливаючі вікна/підказки:

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

Usability

За зовнішнім виглядом і функціональністю слід зручність (Usability). Не менш важлива частина, так як від неї залежить, чи буде затребуваний ваш продукт взагалі. Про які моменти потрібно пам'ятати при тестуванні usability веб-додатки?

Відповідає додаток очікуванням кінцевого користувача;
Логічність інтерфейсу;
Найпотрібніше «зверху»;
Продумана навігація;
Локалізація (так, так, вона відноситься і сюди теж);
Сумісність з іншим софтом (соцмережі) та залізом;
Швидкість роботи додатку;
Інформативність (повідомлення/обов'язкові поля);
Можливість скасування дій користувача;
Help — повинна бути інструкція, як працювати з додатком;
Можливість друку (якщо потрібно).

Security

Тестування безпеки:

Починаємо завжди з складання матриці рівнів доступу;
Конфіденційність — ніхто не може отримати доступ до даних несанкціоновано;
Цілісність даних:
а) можливість відновити дані у повному обсязі при їх пошкодженні;
б) доступ на зміну інформації тільки певної категорії користувачів.

Performance

Продуктивність:

Імітуємо навантаження користувачами (JMeter );
Пробуємо завантажити великі обсяги даних, файли, медіа;
Навантажуємо БД;
Знижуємо швидкість інету (NetLimiter );
Знижуємо швидкість передачі даних (Throttling);
Тестуємо відновлення системи після падінь.

Configuration

Конфігураційне тестування. Тут все теж просто:

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

Пам'ятка

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

GUI	макет контент кодування елементи (колір, розмір, розташування) локалізація стандарти HTML/CSS масштабованість курсор заголовки шрифти фавикон scroll кросбраузерність
Functional	робота кнопок електронна пошта реєстрація/авторизація поля введення час і дата повідомлення про помилки пошук спливаючі вікна/підказки заповнення форми календарі взаємодія всіх модулів системи
Usability	навігація відповідність цілям програми друк логічність локалізація help інформативність сумісність з іншими програмами очікування кінцевого користувача швидкість роботи
Security	матриця рівнів доступу протоколи передачі даних конфіденційність інформації протоколи криптування доступність інформації авторизація
Performance	навантаження імітація кількості користувачів БД навантаження стабільність «важкий» медіа-контент швидкість виконання запитів до БД стрес швидкість інтернету коректні повідомлення про помилки відновлення об'єм завантажуваних файлів відновлення даних системи
Configuration	сторонній софт «залізо» сумісність з іншими браузерами OS

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

Зовнішнє — > Внутрішне — >Стійкість — >Взаємодія

Зовнішнє — перевірка зовнішнього вигляду і функцій, які доступні тільки для пересічного користувача (GUI, Usability).

Внутрішнє — всі функції додатка (Functional).

Стійкість — сюди ми віднесемо стійкість програми до навантажень і до спроб порушити його безпека (Security, Performance (load/stress/recovery)).

Взаємодія — робота додатки з іншим софтом і залізом (Configuration).

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

Опубліковано: 05/02/18 @ 11:44
Розділ Блоги

SEO Блог