Тестування UI сайту

"У нас були зміни лише на UI-ї, повністю регресію проганяти не будемо." - казали вони.

У Джеррі Вайнберга був чудовий розділ про "колиско́ві слова", і "лише" - одне з них. Щоразу як тестер чує "лише" - тестер починає нервувати. Або навпаки, радіти, бо в повітрі запахло багами :-)

Хочу поділитися своїми намітками про те, що треба брати до уваги, тестуючи "лише UI" якогось сайту (не прив’язано до платформи).

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

Умовно-статичне тестування

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

Динамічне тестування

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

Бізнес-логіка

Звичайно, ключовим тут є сенс усієї нашої системи, тобто бізнес-фічі - функції, завдяки наявності яких існує наша система. Але у всіх вони свої, тому заповнюйте цей пункт самі :-)

Клієнт-серверна архітектура

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

• сервер
• браузер
• користувач із своїми даними

Тестові дані на сервері

Під тестовими даними тут і далі я розумію, насамперед, набори рядків, як от List of naughty strings і т.ін.

Тестові дані, що вже мають бути в системі під час тестування, можна попередньо внести на "сервер":

• нашої бази даних,
• у зовнішні файли, що їх наша система обробляє під час виконання,
• до API третіх сервісів, що їх використовує наша система для відображення.

Тестові дані користувача

Тестові дані, які може вводити чи на які може впливати користувач бувають такі:

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

Розміри вікна браузера

Звичайно, до змінних, доступних користувачеві, належить і розмір броўзера. Я б хотів виділити такі розміри:

• Desktop
• Mobile/Responsive
• Щось поміж цих двох
• Дууууже широкий / Повний екран на великому моніторі.
• Вузький за висотою, щоб добре роздивитись роботу вертикального скролу; корисно при тестуванні постійного довантаження довгих списків.

Рівні кешу

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

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

Спробую загалом описати широко розповсюджені види кешу, що можуть бути в більшості систем.

Браузер

Якщо вам треба потестувати свіжу юзер-сесію, використовуйте анонімний режим у браузері. Але не зловживайте цим, якщо вас цікавлять не тільки нові, а й старі користувачі, що вже мають набір старих кешованих ресурсів.

• HTML+JS+CSS 
• Обидва ці види файлів у більшості сучасних фреймворків можуть піддаватися:
• аґреґації (aggregation), тобто збір та об’єднання багатьох файлів, щоб зменшити кількість мережевих з’єднань та прискорити завантаження сторінки
• мініфікації (minification), тобто видалення з коду всіх символів, які не впливають на синтаксис: зайві пробіли, переводи рядків, зайві крапки з комою. Ці перетворення роблять код майже не чита́ним.
• Браузер кешує мініфіковані-аґреґовані файли, бо саме їх йому передає сервер.
•  Медіа-вміст
• Картинки та інші медіа-файли теж кешуються.
• Local Storage
•  деяка інформація, що використовується скриптами на сторінці, може зберігатися у локальному сховищі (майже як куки, тільки із розширеною функціональністю. Більше див. на вікі Web_Storage)
• Я сам мав проблеми із цим у Jira під Firefox. Доки не знайшов як його почистити, не вантажились та зависали сторінки. Був суцільний жах!

Веб-сервер

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

Кеш аплікації

На якому би фреймворку не був побудований ваш сайт, він має свій власний спосіб покешувати що треба і не треба. 

• Функціональний кеш.
• На цьому рівні теж існує окремі кеші для JS+CSS+HTML кожної фічі/області/модулю.
• Кешування окремих сторінок
• В деяких фреймворках трапляються інструменти окремого кешування певних сторінок. Ці інструменти, в свою чергу, дозволяють виключати певні модулі на закешованих сторінках із кешування. Заплутана історія :-) Але нам важливо знати, що таке буває.

Казка: Одна високонавантажена сторінка була закешована на віки вічні всіма видами кешу, які тільки трапляються в природі (на рівні фреймворку). І народився в той час один дуже сміливий модуль. Хоч він і був дуже маленький на вигляд, із одним єдиним рядком тексту десь посередині сторінки, але той рядок він складав дуже цікавим способом ще й із прямого запиту в базу. І все працювало, і не було нікому жодного горя, поки вони, та сторінка і той модуль, не зустрілися. І сайт ліг. І був день дебагу і рол-беку. І з’ясувалося тоді, що той модуль був не простий, а настільки гордий, що мав явну позначку "ніколи не кешувати" (бо дуже особливі запити, і по-іншому, мабуть, у розробника не виходило зробити його аж настільки особливим). І подивився  на це відділ маркетингу, і відмовився від аж на стільки особливих фіч. І їх знову розділили, ту сторінку і той модуль.

Мораль: Інколи лоад-тестінг треба включати у регрешен сьўіт.

• Кеш бази даних
• Це дуже несподівана для мене річ. Він, нібито, завжди є. Але баги, пов’язані саме із цим видом кешу, я бачив лише двічі, і вже не пам’ятаю, що там було :-) Тому я маю підозру, що посилання кимось на кеш бази даних, як на причину дивної поведінки, це відмазка. Нормально (чи навіть "Правильно"?) написаний код не має стикатися із цим кешом, він має бути внутрішньою справою вашої DBMS. (Це тільки моє відчуття, і це не стосується спеціальних систем із тонким настроюванням).

AJAX

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

Оскільки про саму бізнес логіку говорити абстрактно не має сенсу, наведу кілька порад, що треба мати на увазі, тестуючи сторінки, багаті на аджакс:

• Чи повністю відповідає частина, що приїхала з аджаксом, усій сторінці? (структура, колонки, мова перекладу і т.ін.)
• Що на що впливає?
• Побудуйте собі (в якомусь вигляді) діаграму залежностей ваших запитів один від одного. 
• Уявіть, що один із них не пройшов.
• ...
• PROFIT!!!11
• Поробіть кілька послідовних запитів з оновлення залежних блоків. На якійсь ітерації воно з’явиться.
• Асинхронність.
• Відповідь на якийсь запит може йти дуже довго. Чи інші у черзі готові стільки чекати?
• А що як якийсь запит, на який всі сподіваються, взагалі не отримає відповіді?
• "На вимогу".
• Навмисно не відправляйте якийсь запит.
• Чи відправте багато разів той самий.

 В принципі, кожен енд-поінт використаний в AJAX, має бути покритий тестами API (в тому числі автоматизованими) ще до того, як ви почнете перевіряти навішений на цей енд-поін UI. При ручному тестуванні API мені допомагає Postman. Але тестування API - це окрема тема.

Ось і все, що треба мати на увазі, тестуючи UI якогось сайту. Нагадайте, якщо щось забув!