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

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

За 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.

Всі? — Ні :)

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

Functional

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

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

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

Наприклад:

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

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

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

Кнопки:

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

Пошук:

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

Календар:

Час:

E-mail:

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

Usability

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

Security

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

Performance

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

Configuration

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

Пам'ятка

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

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
Розділ Блоги

Рекомендуємо:

Ruby/Rails дайджест #14: розгортаємо Rails-додаток на AWS і Azure, огляд Active Storage в Rails 5.2.0
Product Management дайджест #1: три українських продукту стали кращими на Product Hunt
Січень 2018 — финстрип за інфо-сайтів, майже 30К грн в міс
Чому варто замислитися про функціональному програмуванні: плюси, мінуси і застосування
Огляд IT-ринку праці: Полтава