Тестування сайтів та SAAS додатків

У більшості випадків тестування інтернет-додатків – це складніший процес, ніж тестування звичайного програмного забезпечення. Складність обумовлена:

  1. Специфіка роботи з веб-додатками в тому, що до цих програм відкритий публічний доступ, тому необхідно особливо ретельно організовувати захист даних, що передаються користувачем;
  2. Архітектура веб-додатків. Зазвичай додаток має таку архітектуру:
  3. веб-сервер;
  4. сервер із додатком;
  5. база даних.

Проблеми тестування веб-додатків

Розподілені компоненти системи збільшує труднощі тестування:

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

Ми вирішуємо проблеми функціонального тестування веб-додатків, розробляючи такі набори тестів, які:

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

Побудова якісного процесу тестування

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

Інструменти та сценарії тестування веб-додатків

Boundary Value Testing - використання граничних значень. Техніка тест дизайну, покликана допомагати тестувальнику вибирати найбільш ефективні значення діапазонів значень. Вона застосовується на всіх рівнях тестування: unit, integration, system, system-integration test levels. Ця техніка задоволена проста і включає 3 кроки: визначення діапазону значень; визначення меж діапазонів; створення тест кейсів (3-4 на кожний кордон);

Equivalence Class Testing - розбиття на класи еквівалентності. Ця техніка використовується для написання тестів для вхідних та вихідних даних, які обробляються додатком однаково або обробка яких призводить до одного й того самого результату. Вона резонно зменшує кількістьстворюваних тестів. Використовувати її можна на всіх рівнях тестування: unit, integration, system, and system-integration test levels;

Decision Table Testing - таблиці вимог. Техніка для фіксування вимог та опису дизайну програми. Decision Tables описують логіку програми ґрунтуючись на умовах/властивості стану системи. Цими таблицями дуже зручно описувати бізнес-логіку програми, якщо на додаток, що тестується, немає адекватної документації. Подання вимог у простій та компактній формі служить відмінною основою для тесту кейсів;

Use Case Testing – тестування варіантів використання. Варіанти використання – це опис послідовності дій, які може здійснювати система у відповідь зовнішні впливи користувачів чи інших програмних систем. У процесі тестування варіанти використання дозволяють оцінити точність реалізації вимог і дозволяють провести покрокову перевірку цих вимог.

State-Transition Testing - опис станів. Ця техніка, як і decision tables testing, чудовий інструмент для фіксування вимог та опису дизайну програми. Але на відміну від decision tables testing, ця техніка описує, як ці стани програми можуть змінюватися. Діаграми визначають всі події, що виникають під час роботи програми, і як додаток реагує на ці події. Існує два види візуального подання цих подій:

  • State-Transition Diagrams (діаграми). У цьому поданні кожен стан системи позначається кругом, стрілками показуються можливі переходи в інші стани, під стрілкою спочатку записують опис події, що виходить із позасистеми, а потім дію системи у відповідь на цю подію;
  • State-Transition Tables (таблиці). З використанням цього підходу створюється таблиця що складається з чотирьох стовпців: поточний стан (Current State); подія (Event); дія (Action); наступне стан (Next State). У цій таблиці визначаються всі можливі State-Transition варіанти (і не лише валідні).

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

  • В першу чергу;
  • Більш ретельно.

Pairwise Testing - попарне тестування. Ця техніка застосовується у разі великої кількості комбінацій, які необхідно протестувати, причому виняток будь-яких комбінацій виглядає ризиковано. І якщо кількість комбінацій настільки велика, то, швидше за все, не вистачить ресурсів, щоб спроектувати та пройти тест кейси. При використанні Pairwise Testing перевіряються комбінації пар значень змінних, а чи не всі комбінації значень всім змінних. Ця техніка суттєво зменшує кількість комбінацій для тестування. Існують два способи її реалізації:

Orthogonal Arrays – підхід полягає у розробці двовимірного масиву комбінацій значень вхідних даних з наступними властивостями:

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

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

AllPairs Algorithm - ця комбінаторна техніка була спеціально створена для Pairwise Testing. Суть її полягає у виборі таких комбінацій змінних, щоб існували всі можливі комбінації значень кожної пари змінних. При використанні даного способу також використовують спеціальні утиліти, що дозволяють будувати всі пари змінних AllPairs Algorithm по таблиці з усіма змінними та їх значеннями;

Постановка задач з використанням scrum методологій

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

  • Відбір тестів (вибір правил та критеріїв відбору);
  • Обробка елементів із нечіткими вимогами;
  • Поділ завдань між членами команди;
  • Вибір метрик оцінки результатів тестування та якості роботи;
  • Формування відповідної звітності.
  • Тестування у нечіткому процесі розробки.