1. Клієнт, сервер і база даних
2. Особливості архітектури: «під прицілом» клієнт
3. Веб-сервер: «геть клієнт, тест без нього»
4. База даних: «зберігати не можна видалити»
5. Чим ще відрізняється веб-додаток від десктопного: більше особливостей - більше проблем!
6. Практичні поради: ще раз про насущне
7. Висновки і напуття

Чи доводилося вам тестувати веб-додатки? Практично будь-який фахівець з тестування програмного забезпечення з досвідом понад рік дасть ствердну відповідь на це питання, адже існують цілком об'єктивні причини такого стану справ:

• на даний момент в мережі Інтернет діє понад мільярд сайтів, і користуються ними більш 3,5 млрд. людей по всьому світу (за даними Міжнародного союзу електрозв'язку на липень 2016 року);
• в Росії більше 70% дорослого населення є інтернет-користувачами, а загальний оборот коштів на російському ринку інтернет-торгівлі за перше півріччя 2016 року зріс на 26% в порівнянні з аналогічним періодом 2015 року та досяг 405 млрд. рублів.

При погляді на ці нечувані цифри стає зрозумілим, чому в світі розробляється так багато нових веб-додатків. Цей процес призводить до необхідності залучення великої кількості фахівців. Те, що веб (в широкому сенсі) буде продовжувати нарощувати темпи свого розвитку, підтверджується і набирає силу «мейнстрімом»: все «переїжджає» в хмари. Хмарні технології стають новою реальністю сучасного Інтернету: навіть колись звичні нам десктопні Word і Excel сьогодні представлені у вигляді веб-альтернатив від Microsoft. Виходячи зі сказаного, можна стверджувати, що потреба в хороших інженерів по забезпеченню якості, що спеціалізуються на веб-продуктах, буде тільки зростати.

Представлена ​​увазі читачів стаття присвячена питанням особливостей тестування веб-додатків. Буде правильним почати розповідь з основ і визначитися, що саме ми розуміємо під поняттям «веб-додаток» і які нюанси в реалізації цих програм додають роботу тестувальникам.

Клієнт, сервер і база даних

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

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

Веб-додаток представлено наступними складовими ( «сторонами»):
1. Клієнт.
Як правило, клієнт - це браузер, але трапляються й винятки (в тих випадках, коли один веб-сервер (ВР1) виконує запит до іншого (ВС2), роль клієнта грає веб-сервер ВС1). У класичній ситуації (коли роль клієнта виконує браузер) для того, щоб користувач побачив графічний інтерфейс програми у вікні браузера, останній повинен обробити отриману відповідь веб-сервера, в якому буде міститися інформація, реалізована із застосуванням HTML, CSS, JS (найбільш використовувані технології ). Саме ці технології «дають зрозуміти» браузеру, як саме необхідно «отрисовать» все, що він отримав у відповіді.

2. Сервер.
Веб-сервер - це сервер, що приймає HTTP-запити від клієнтів і видає їм HTTP-відповіді. Щоб уникнути можливої ​​плутанини, відзначимо, що веб-сервером називають як програмне забезпечення, яке виконує функції веб-сервера, так і безпосередньо комп'ютер, на якому це програмне забезпечення працює. Найбільш поширеними видами ПО веб-серверів є Apache, IIS і NGINX. На веб-сервері функціонує тестоване додаток, яке може бути реалізовано з застосуванням найрізноманітніших мов програмування: PHP, Python, Ruby, Java, Perl та ін.

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

База даних - досить широке поняття, яке використовується не тільки в сфері інформаційних технологій. В контексті моєї статті це - інформаційна модель, що дозволяє упорядковано зберігати дані про об'єкт або групі об'єктів, що володіють набором властивостей, які можна категоризувати. Бази даних функціонують під управлінням так званих систем управління базами даних (далі - СУБД). Найпопулярнішими СУБД є MySQL, MS SQL Server, PostgreSQL, Oracle (всі - клієнт-серверні).

Також існують вбудовані і файл-серверні СУБД. Для загального розвитку зазначу лише одну популярну вбудовану СУБД - SQLite, яка використовується в деяких браузерах, Android API, Skype і інших відомих додатках. Взаємодія з перерахованими СУБД засноване на спеціальній мові структурованих запитів - SQL.

Тепер, зібравши в голові певний архітектурний пазл, пропоную розглянути його з точки зору тестування ПО. Трохи пізніше ми розглянемо і те, як всі складові «спілкуються» між собою.

Особливості архітектури: «під прицілом» клієнт

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

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

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

Що необхідно перевіряти при кросбраузерності тестуванні:

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

У тестуванні потребують всі основні (серед користувальницької аудиторії) браузери, але особливу увагу необхідно приділити IE, якщо він входить в їх число. Саме в ньому дуже часто виникають проблеми, які відсутні в інших браузерах: так, в IE додатково рекомендується звертати особливу увагу на масштабованість, фокус полів і роботу JS.

Окремо рекомендую не забувати про всякого роду валідаторах верстки, наприклад https://validator.w3.org/ . Навіть якщо у вас недостатньо знань, щоб оцінити відповідність верстки стандартам, можна використовувати для цього автоматичні засоби і, проаналізувавши результат, вказати розробникам на найсерйозніші «помилки». Не варто забувати, що іноді валідатори звертають увагу на самі «дріб'язкові дрібниці», які ніхто і ніколи виправляти не буде. Якщо ви і заводите баг-репорти на подібного роду зауваження, то зручніше буде зібрати їх в єдиний документ і прикріпити до репорту. До такого роду «дрібниць» можна віднести всілякі рекомендації, які не мають свого впливу на відображення і функціонування контенту.

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

Як же не пропустити дефекти в формах на продакшен? Розглянемо кілька простих кроків:
1. Ретельно перевіряємо обов'язковість заповнення полів і наявність відповідного маркування у них.
2. Заповнивши і відправивши форму, переконуємося в тому, що з даними відбувається саме те, що заплановано. Якщо дані повинні бути внесені в базу даних, перевіряємо, чи коректно завершився процес (в кінці кінців, про це можна попросити розробника, якщо не вистачає своїх знань SQL або прав доступу до БД).
3. Використовуємо чит-листи для тестування форм, наприклад чит-лист реєстрації від Олексія Лупана або чит-лист по Web UI контролю від Ігоря Любина.
4. Перевіряємо, виводяться чи зрозумілі користувачеві інформаційні повідомлення про необхідність заповнення порожніх полів після спроби відправити форму.
5. Звертаємо увагу на реалізацію екранування символів в полях форм, які є потенційним джерелом вразливостей для програми та користувачів. Екранування має здійснюватися на рівні не тільки клієнта, але і сервера, відключити який в клієнті досить просто (наприклад, за допомогою спеціальних плагінів, що знімають всі можливі обмеження в кілька кліків, таких як Web Developer Toolbar - Forms).
6. Переконуємося, що після заповнення форми користувачеві приходить підтверджуючий лист із зазначенням відповідного відправника, а саме тіло листа відповідає вимогам (в тому числі і на працездатність посилань).
7. Використовуємо допоміжні спеціальні інструменти для тестування форм (наприклад, Web Developer Toolbar).

Текст, як основне джерело інформації при роботі через клієнт
Як не крути, але особлива цінність мережі Інтернет полягає в тому, що вона є практично безмежним джерелом інформації. Частина цієї інформації представлена ​​у вигляді текстів, з якими, знову ж таки, користувач взаємодіє за допомогою клієнта. Більшість веб-ресурсів в тому чи іншому обсязі вимагають перевірки текстів на предмет відсутності граматичних помилок і друкарських помилок.

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

Так, ми не завжди маємо достатньо часу для вичитування всіх текстів, але в таких ситуаціях на допомогу приходять «SpellCheker-и» (програми для перевірки орфографії, онлайн або у вигляді плагінів для браузерів), наприклад, Яндекс.Спеллер .

Веб-сервер: «геть клієнт, тест без нього»

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

Інсталяція на веб-сервер
Отже, перш ніж приступити до тестування , Ми повинні встановити (інсталювати) веб-додаток на веб-сервер. Власне, в цьому є подібність з перевіркою десктоп-додатків, але існує і відмінність в нюансах, які необхідно врахувати і протестувати, особливо якщо це стосується ПО, розповсюджуваного для локальної інсталяції на веб-сервери користувачів.

У чому ж полягають ці нюанси?

1. Велика частина веб-додатків вимагає для інсталяції специфічних знань в адмініструванні ОС. Спробуйте встановити додаток на декількох веб-серверах. В оптимальному випадку це будуть найпопулярніші технології серед ваших користувачів, для встановлення переліку яких буде потрібно попереднє дослідження.
2. інсталюємо веб-додаток, звертайте увагу на те, чи дійсно додаток встановлюється в зазначену вами директорію, базу даних, використовує обраний вами префікс і дотримується інші конфігураційні моменти.
3. Переконайтеся, що додаток можна встановити як з localhost, так і віддалено.
4. Якщо процес інсталяції є інтерактивним, і кожен вибір користувача на певному етапі впливає на подальші дії, то необхідно буде пройти всі гілки, так як саме інсталяція є першим кроком користувача в роботі з вашим додатком.
5. Не забувайте про негативні тестах: перевірки в умовах недостатності ресурсів (місця на диску, оперативної пам'яті) або привілеїв, переривання процесу установки під час активної його фази (наприклад, відправляючи сервер в перезавантаження).

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

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

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

База даних: «зберігати не можна видалити»

Ще однією раніше розглянутої складової веб-додатків є база даних, в якій додаток зберігає всю необхідну інформацію. Для того, щоб база даних служила гідним сховищем інформації для вашого застосування, при тестуванні необхідно звертати увагу на такі основні моменти:
1. вносяться через інтерфейс інформація повинна бути збережена в базі даних в незмінному (первісному) вигляді.
2. Збережена в базі даних інформація повинна відображатися в будь-якій частині програми однаково (якщо іншого не вимагає бізнес-логіка програми).
3. Назви таблиць і структура БД повинні відповідати проектній документації.
4. Потрібно стежити за тим, щоб запити не обробляється занадто довго, а кількість з'єднань було достатнім. Моніторинг стану БД - один з важливих моментів тестування.
5. Варто враховувати, що видалення запису в БД не завжди супроводжується повним видаленням суті. Іноді використовується так зване «псевдоудаленіе», і потрібно перевірити, чи правильно воно виконується.
6. Порожню БД на тестовому стенді рекомендується або заповнювати згенерували випадковими даними, або знімати дамп з продакшена і після обфускаціі даних «заливати» їх в тестируемую БД. Іноді кваліфікація тестувальника (або інша причина) не дозволяє виконати цей процес самостійно: в такому випадку рекомендується звернутися за допомогою до фахівців інфраструктури або розробникам.

Запити: do you speak computish?
Всі складові веб-додатки повинні взаємодіяти між собою, і відбувається це завдяки HTTP (s). Без HTTP наша багатостороння система не функціонувала б в принципі, так як HTTP - це протокол передачі даних, що займає одне з основних місць в нашій клієнт-серверній архітектурі.

Взаємодія здійснюється через повідомлення (запити і відповіді): на відправлений запит від клієнта повинен прийти відповідь сервера. Класичний запит / відповідь складається з 3 складових:

• стартова рядок;
• Заголовок;
• тіло повідомлення.

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

Найпопулярнішими методами є GET, HEAD і POST:

1. Метод GET. Використовується для запиту вмісту, розміщеного на сервері (наприклад, GET / path / resource? Param1 = value1¶m2 = value2 HTTP / 1.1).
2. Метод HEAD. За своєю суттю не відрізняється від вищезгаданого методу, однак відповідь сервера на такий запит позбавлений «тіла», а практичне застосування орієнтоване на полегшене використання з метою отримання мінімальної інформації про сервер / продукті або його статус.
3. Метод POST. Даний метод використовується для передачі даних на сервер, однак його основа «ховається» в тіло, що відрізняє його від GET. Під час публікації цієї статті, наприклад весь текст буде поміщений в тіло POST-запиту; після обробки його сервером на сайт буде додано статтю.

Існують і інші методи: PUT, DELETE, CONNECT, TRACE, PATCH і т. Д.

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

Класичними додатками, які можна використовувати для генерації запитів, є Fiddler або Postman . Використовуючи Fiddler, можна з легкістю відстежувати всі запити від клієнта і відповіді, переглядати їх деталі, а також вносити свої зміни і відправляти модифіковані запити на сервер, оцінюючи поведінку системи в такому випадку.

На що звертати увагу в запитах?

1. Чи правильний метод використовується для того чи іншого запиту? Якщо ви відправляєте повідомлення, а на сервер йде тільки GET-запит, то щось тут явно не так.
2. Здавалося б, клік по одній і тій же функціональної клавіші генерує один і той же запит. Але є прецеденти, коли клік по кнопці приводив до ситуації, в якій JavaScript переписував запит поруч знаходиться кнопки, таким чином змінюючи її призначення.
3. Вникайте в відправляються запити. У них досить легко розібратися, особливо якщо це GET - вони логічно зрозумілі навіть пересічному користувачеві. Аналіз запитів - це можливість виявити сховався дефект набагато швидше, ніж здійснюючи його пошук в інтерфейсі.
4. моніторьте трафік на предмет запитів на інші (не ваші) сервера. Приклад з життя: фронтенд сайту робив фріланс-розробник, по завершенню роботи якого ми взялися за тестування. Я маю звичку моніторити весь трафік тестової програми: це дозволило виявити, що вищезгаданий розробник безсоромно сховав у «фронт» сайту запити, які працювали на благо його особистого інтернет-магазину.
5. монітор трафік, уважно стежте за кодами станів. Ми докладніше зупинимося на цьому пункті.

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

Всі коди можна поділити на групи (соті, двохсоті, трьохсот, чотирьохсоті і п'ятисот) кожна група-«сотня» несе свій тип інформації.

Більш детально з кодами стану можна ознайомитися на Wikipedia .

На практиці, використовуючи при тестуванні спеціальні додатки (той же Fiddler), ви без зусиль зможете впорядкувати свої запити і відповіді за кодом стану і відібрати, наприклад, все 400-е і 500-е з подальшим їх аналізом. Таким чином дуже швидко «відловлюються» дефекти з «відвалилися» стилями, скриптами, файлами, функціями програми і т.п.

Чим ще відрізняється веб-додаток від десктопного: більше особливостей - більше проблем!

Розрахована на багато користувачів сутність веб-додатків
Широта аудиторії додатків накладає свій відбиток на специфіку роботи.
1. Один додаток одночасно може використовуватися величезною кількістю людей. Ми вже розглядали питання навантажувального тестування, але також слід звернути увагу на те, що в число користувачів можуть входити представники різних культур, мов і релігій. Нам необхідно пам'ятати про це, особливо якщо мова йде про тестування міжнародного додатка.
2. Кожен користувач може мати свої рівні доступу. В ідеальному варіанті тестувальник створює для себе матрицю рівнів доступу і тестує кожен доступ окремо.

По кліку на картинку відкриється повна версія.
3.

Користувачі з одним рівнем доступу можуть звертатися до одних і тих же сутностей, що призводить до конкурентного доступу. Тестується це досить просто. Для прикладу розглянемо систему, що має справу з договорами, які можна створювати, публікувати, редагувати, анулювати. Алгоритм роботи такий: під декількома вікнами в режимі інкогніто авторізуемся в додатку під користувачами з різними рівнями доступу; далі обрану для тесту сутність відкриваємо на редагування, а під другий обліковим записом цю ж сутність пробуємо перевести в статус «Анульовано» - на цьому етапі повинен спрацювати контроль на конкурентний доступ. Операція анулювання блокується, а користувачу видається повідомлення про те, що сутність редагується іншим користувачем (поведінку і пріоритет дій визначаються відповідно до вимог і особливостями продукту, але логіка не змінюється).
4. Широта аудиторії говорить про те, що за монітором може перебувати людина, що має злий намір щодо вашого ПО.

Мережеві пристрасті: веб-додаток в різних умовах передачі даних
Веб-додатки активно використовують мережу, і це є джерелом можливих проблем. Такий, наприклад, є використання додатки в умовах низької швидкості передачі даних (в браузер Google Chrome, наприклад, вбудована функція Throttling, яка дозволяє сильно занижувати швидкість передачі даних), в умовах втрати пакетів або при відключенні мережі під час активної фази роботи програми (спосіб імітації: спочатку робимо швидкість передачі даних за допомогою Throttling мінімальної, а потім перериваємо мережеве з'єднання під час обробки запиту).

У будь-якому з описаних вище випадків програма має працювати коректно. При «падінні» запиту (time out) або іншої проблеми ми повинні, перезагрузив сторінку, знову отримати повністю працює веб-додаток без будь-якого натяку на щойно пережита «шкоди». Для всіх чи функцій програми необхідно подібні тести? Ні в якому разі! В майбутньому можете орієнтуватися на свій досвід, а на перших етапах в цих питаннях краще проконсультуватися з розробниками.

Тестування безпеки веб-додатки: спаси, сохрани, захисти
Тестування безпеки - окремий напрямок тестування, яке вимагає від фахівця фундаментальних знань технічного характеру і хорошою профільної кваліфікації. Я зазначу ряд загальних моментів, які можуть допомогти будь-якому тестувальника знаходити класичні уразливості, не допускаючи їх вихід на продакшен. Питання безпеки додатків регламентуються OWASP Guide , CHECK , ISACA , NIST Guideline, OSSTMM .

Існує ряд принципів безпеки, до яких відносяться конфіденційність, цілісність і доступність:
1) Конфіденційність - обмеження доступу до тієї чи іншої інформації для певної категорії користувачів (або навпаки надання доступу лише обмеженій категорії).
2) Цілісність включає в себе:
а) можливість відновити дані в повному обсязі при їх пошкодженні;
б) доступ на зміну інформації тільки певної категорії користувачів.
3) Доступність - ієрархія рівнів доступу і чітке їх дотримання.

Перерахуємо класичні уразливості сучасних веб-додатків:
1. XSS - генерація на сторінці продукту скриптів, які становлять небезпеку для користувачів продукту;
2. XSRF - вразливість, при якій користувач переходить з довіреної сторінки на шкідливу, де крадуться представляють цінність для користувача дані;
3. Сode injection (PHP, SQL) - ін'єкція частини виконавчого коду, яка робить можливим отримати несанкціонований доступ до програмного коду або базі даних і вносити в них зміни;
4. authorization bypass - це вид уразливості, при якому можна отримати несанкціонований доступ до облікового запису або документам іншого користувача;
5. переповнення буфера - явище, якого можна досягти у шкідливих цілях, по своїй суті являє використання місця для запису даних далеко за межами виділеного буфера пам'яті.

При тестуванні рекомендую використовувати чит-листи вразливостей XSS Filter Evasion Cheat Sheet и MySQL SQL Injection Cheat Sheet .

Практичні поради: ще раз про насущне

Починаємо тестувати ні з тестування: з чого почати?

Я хочу акцентувати вашу увагу на необхідності узгодити всі ключові аспекти з відповідальними особами (аналітиками, проектними менеджерами, розробниками) ще до початку тестування. Необхідно заздалегідь з'ясувати наступні моменти:

• мета тестування (з їхньої точки зору);
• види тестування, які необхідно провести;
• специфіку програми та його цільову аудиторію;
• перелік пристроїв, на яких необхідно проводити тестування;
• список ОС і браузерів для тестування;
• дозволи екранів на яких необхідно перевірити додаток;
• чи передбачені вимоги до різного роду формам, чи є стайл-гайд, актуальне ЧТЗ ;
• необхідність надання конкретної документації за результатами тестування (звіт, чек-листи, тест-кейси і т. д.).

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

Ніколи думати, потрібно тестувати!
Будь-яке тестування вимагає змістовного підходу із застосуванням технік тест-аналізу і тест-дизайну. В іншому випадку ви ризикуєте назавжди залишитися «monkey-тестером», цінність праці якого буде мізерна. В цілому, ключові положення тест-аналізу і тест-дизайну застосовні як до тестування десктоп-додатків, так і до веб-у, але з суттєвим застереженням: ви повинні враховувати всі згадані в статті нюанси. Окремо хочу акцентувати увагу на тому, що без стійкого розуміння методик і способів застосування тест-аналізу і тест-дизайну тестувати якісно ПО практично неможливо.

Розглянемо класичний набір методик тест-дизайну, які можна застосовувати при тестуванні веб-додатків:

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

Подай ключ «на 13»
В даний час існує величезна безліч різноманітних інструментів, які спрощують життя всім учасникам розробки нового ПЗ. Отже, не варто забувати про те, що крім розвитку особистих якостей, технічних знань і навичок, ми повинні вміти добре користуватися допоміжними інструментами, кожен раз відчуваючи все нові і нові.

Зазначу лише деякі з них:

• Ресайзер - оперативне зміна усіляких налаштувань розмірів відображення, перегляд метрик, перемикання орієнтацій відображення.
• Opera Mobile Classic Emulator - класичний однойменний емулятор.
• Mobile Phone Emulator - класичний емулятор.
• Fiddler - ПО для відстеження всього вашого трафіку. Я завжди супроводжую будь-яке тестування його фонової роботою, а потім сортую по помилках і аналізую трафік. Також за допомогою цієї програми можна відправляти помилкові запити на сервер з потрібними вам параметрами.
• Xenu Link Evaluator (альтернатива - Black Widow) - «чекер» веб-додатки на предмет наявності в ньому «битих» посилань. Також можна використовувати його для формування карти додатки.
• Skipfish - активний сканер вразливостей веб-додатків.
• OpenVAS - безкоштовний сканер вразливостей.
• Nikto - веб-сканер, перевіряючий веб-сервери на найчастіші помилки, що виникають зазвичай через людський фактор.

Висновки і напуття

Підводячи підсумки, я хочу ще раз акцентувати увагу читача на те, що «веб» розвивався, розвивається і буде розвиватися, а кількість використовуваних технологій, як і різноманітність дефектів, - збільшуватися. Можливо, колись прийде захід ери «веб-а», але це не станеться в найближчі 5-10 років, тому знання основ і розуміння суті веб-додатків просто безцінне. Будь-тестувальник рано чи пізно торкнеться «веб-у» своєї професійної «руйнівної» рукою, але тільки хороший фахівець отримає з цього максимально наближений до необхідного результат.

Важливо пам'ятати, що тестування ПО ставить перед кожним набрав стрункі ряди сфери забезпечення якості ПО такі завдання, які практично неможливо вирішувати однозначно і за чітким алгоритмом. Тестування - це філософія, творчість, політ думки, заснований на чітких і беззастережних технічних аспектах. Мабуть, тільки тестувальникам доводиться одночасно бути розробником, системним аналітиком, користувачем, замовником (для якого першочерговий інтерес - фінансовий чи інший успіх продукту), фахівцем в предметної області і навіть DBA .

Кожен з цих навичок QA Engineer повинен розвивати постійно, і тоді він зможе уникнути багатьох можливих проблем і залишитися затребуваним висококваліфікованим професіоналом. Зупинка в розвитку для фахівця зі сфери забезпечення якості фактично прирівнюється до професійної смерті (як мінімум, «клінічної» в тому випадку, якщо прагнення до нових знань з часом повертається). Рух це життя. Всім добра!