Author: adminsimplerec

Рівні тестування – це групи тестових дій, які організовуються та керуються разом. Кожен рівень тестування — це екземпляр процесу тестування, що виконується стосовно програмного забезпечення на певному рівні розробки, від окремих одиниць або компонентів до повних систем. Рівні тестування пов’язані з іншими діями в рамках життєвого циклу розробки програмного забезпечення. Виділяють такі рівні тестування:

• Тестування компонентів
• Інтеграційне тестування (інтеграція компонентів, інтеграція систем)
• Тестування системи
• Приймальне тестування

Рівні тестування характеризуються такими ознаками:

• Конкретні цілі
• База тестування, на яку посилаються для отримання тестових кейсів
• Тестовий об’єкт (тобто те, що тестується)
• Типові дефекти та збої
• Специфічні підходи та відповідальність

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

Тестування компонентів

Цілі компонентного тестування

Тестування компонентів (також відоме як модульне або юніт тестування) зосереджується на компонентах, які можна тестувати окремо. Цілі тестування компонентів включають:

• Зменшення ризику
• Перевірка того, чи функціональна та нефункціональна поведінка компонента відповідає специфікації
• Забезпечення впевненості в якості компонента
• Виявлення дефектів у компоненті
• Запобігання виходу дефектів на вищі рівні тестування

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

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

Тестова база

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

• Детальний дизайн
• Код
• Модель даних
• Характеристики компонентів

Об’єкти тестування

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

• Компоненти, вузли або модулі
• Код і структури даних
• Класи
• Модулі бази даних

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

Конкретні підходи та відповідальність

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

Наприклад, розробка, керовану тестуванням (TDD). Розробка, орієнтована на тестування, є високоітеративною та базується на циклах розробки автоматизованих тестових кейсів, потім створення та інтеграції невеликих фрагментів коду, а потім виконання тестів компонентів, виправлення будь-яких проблем і рефакторинг коду. Цей процес триває до тих пір, поки компонент не буде повністю зроблено та всі компоненти не пройдуть тестування. Розробка, орієнтована на тестування, є прикладом підходу «спочатку тестування». Хоча розробка, керована тестуванням, виникла в eXtreme Programming (XP), вона поширилася на інші форми Agile, а також на послідовні життєві цикли.

Інтеграційне тестування

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

• Зменшення ризику
• Перевірка того, чи функціональна та нефункціональна поведінка інтерфейсів відповідає дизайну та специфікаціям
• Забезпечення впевненості в якості інтерфейсів
• Пошук дефектів (які можуть бути в самих інтерфейсах або всередині компонентів чи систем)
• Запобігання виходу дефектів на вищі рівні тестування

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

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

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

Тестова база

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

• Проєктування програмного забезпечення та системи
• Діаграми послідовності
• Специфікації інтерфейсу та протоколу зв’язку
• Варіанти використання (Use cases)
• Архітектура на рівні компонентів або системи
• Робочі процеси
• Визначення зовнішнього інтерфейсу

Об’єкти тестування

Типові тестові об’єкти для інтеграційного тестування включають:

• Підсистеми
• Бази даних
• Інфраструктуру
• Інтерфейси
• API
• Мікросервіси

Типові дефекти та збої

Приклади типових дефектів і несправностей для тестування інтеграції компонентів включають:

• Неправильні дані, відсутні дані або неправильне кодування даних
• Неправильна послідовність або час викликів інтерфейсу
• Невідповідність інтерфейсу
• Необроблені або неправильно оброблені збої зв’язку між компонентами
• Неправильні припущення щодо значення, одиниць або меж даних, що передаються між компонентами

Приклади типових дефектів і збоїв для тестування системної інтеграції включають:

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

Конкретні підходи та відповідальність

Тести інтеграції компонентів і тести інтеграції системи повинні зосереджуватися на самій інтеграції. Наприклад, у разі інтеграції модуля A з модулем B тести повинні зосереджуватися на зв’язку між модулями, а не на функціональності окремих модулів, оскільки це повинно бути розглянуто під час тестування компонентів. У разі інтеграції системи X із системою Y тести повинні зосереджуватися на зв’язку між системами, а не на функціональності окремих систем, оскільки це повинно бути розглянуто під час тестування системи. Застосовуються як функціональні, так і нефункціональні типи тестів.

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

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

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

Стратегії інтеграції

Тестування великого вибуху – це підхід до інтеграційного тестування, за якого всі компоненти або модулі об’єднуються разом, а потім тестуються як єдине ціле. Ця стратегія може підійти для невеликих систем. Але вона має суттєві недоліки, оскільки під час її застосування важко локалізувати дефекти. Також для її використання потрібно завершити всі модулі, це лишає менше часу на тестування. Є також проблема пріоритетності, оскільки тестується все разом.

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

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

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

Тестові джгути (Test harness)

Test Harness — це набір заглушок, драйверів та інших допоміжних інструментів, необхідних для автоматизації виконання тестів. Тестовий джгут виконує тести за допомогою тестової бібліотеки та створює звіти про тестування. Тестовий пакет містить усю інформацію, необхідну для компіляції та запуску тесту.

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

Заглушка (Stub): Викликається модулем, який тестується.

Драйвер : Викликає модуль, який тестується.

Тестування системи

Цілі тестування системи

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

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

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

Тестове середовище в ідеалі має відповідати кінцевому цільовому або робочому середовищу.

Тестова база

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

• Специфікації вимог до системи та програмного забезпечення (функціональні та нефункціональні)
• Звіти про аналіз ризиків
• Варіанти використання (Use cases)
• Епіки та історії користувачів
• Моделі поведінки системи
• Діаграми стану
• Системні інструкції та посібники користувача

Об’єкти тестування

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

• Додатки
• Апаратні/програмні системи
• Операційні системи
• Система, що тестується (SUT)
• Конфігурація системи та конфігураційні дані

Типові дефекти та збої

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

• Неправильні розрахунки
• Неправильна або несподівана функціональна або нефункціональна поведінка системи
• Неправильний контроль або потоки даних у системі
• Нездатність належним чином і повністю виконувати наскрізні функціональні завдання
• Збій належної роботи системи в системному середовищі
• Помилка роботи системи, як описано в системі та посібниках користувача

Конкретні підходи та відповідальність

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

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

Приймальне тестування

Цілі приймального тестування

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

• Встановлення впевненості в якості системи в цілому
• Перевірка того, що система повна і працюватиме належним чином
• Перевірка того, що функціональна та нефункціональна поведінка системи відповідає специфікаціям

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

Загальні форми приймального тестування включають наступне:

• Користувацьке приймальне тестування
• Операційне приймальне тестування
• Контрактне та регулятивне приймальне тестування
• Альфа- і бета-тестування.

Користувацьке приймальне тестування (UAT)

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

Операційне приймальне тестування (OAT)

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

• Тестування резервного копіювання та відновлення
• Встановлення, видалення та оновлення
• Аварійне відновлення
• Керування користувачами
• Завдання з технічного обслуговування
• Завдання завантаження та міграції даних
• Перевіряє наявність вразливостей у безпеці
• Тестування продуктивності

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

Контрактне та нормативне приймальне тестування

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

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

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

Альфа і бета тестування

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

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

Тестова база

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

• Бізнес-процеси
• Вимоги користувача або бізнесу
• Норми, юридичні договори та стандарти
• Варіанти використання або історії користувачів
• Системні вимоги
• Документація щодо системи або користувача
• Процедури встановлення
• Звіти про аналіз ризиків

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

• Процедури резервного копіювання та відновлення
• Процедури аварійного відновлення
• Нефункціональні вимоги
• Операційна документація
• Інструкції з розгортання та встановлення
• Цільові показники
• Пакети баз даних
• Стандарти або правила безпеки

Типові тестові об’єкти

Типові тестові об’єкти для будь-якої форми приймального тестування включають:

• Система, що тестується
• Конфігурація системи та конфігураційні дані
• Бізнес-процеси для повністю інтегрованої системи
• Системи відновлення (для безперервності бізнесу та тестування аварійного відновлення)
• Процеси експлуатації та обслуговування
• Форми
• Звіти
• Існуючі та перетворені виробничі дані

Типові дефекти та збої

Приклади типових дефектів для будь-якої форми приймального тестування включають:

• Системні робочі процеси не відповідають вимогам бізнесу чи користувача
• Бізнес-правила реалізовані неправильно
• Система не відповідає договірним або нормативним вимогам
• Нефункціональні збої, такі як вразливість системи безпеки, недостатня продуктивність під час високих навантажень або неправильна робота на підтримуваній платформі

Конкретні підходи та відповідальність

Приймальне тестування часто є обов’язком клієнтів, бізнес-користувачів, власників продуктів або операторів системи, а також можуть бути залучені інші зацікавлені сторони.

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

• Приймальне тестування програмного продукту COTS можуть відбуватися після його встановлення або інтеграції
• Перед тестуванням системи може проводитися приймальне тестування нового функціонального вдосконалення

Конкретні підходи та відповідальність

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

В цьому відео поговоримо про:
00:00 Рівні тестування
04:55 Тестування компонентів
10:20 Інтеграційне тестування
24:11 Тестування систем
30:07 Приймальне тестування

До цієї групи зазвичай відносять:

• Підтверджувальне тестування – Confirmation testing (ISQTB)
• Регресійне тестування – Regression testing (ISTQB)
• Димове тестування – Smoke testing
• Тестування працездатності – Sanity testing
• Тестування супроводу – Maintenance testing

Тестування супроводу вже було розглянуто у пості про тестування зручності супроводу. Тому зосередимося на перших чотирьх типах тестування.

Підтверджувальне тестування та Регресійне тестування

Коли в систему вносяться зміни або для виправлення дефекту, або через нову чи змінену функціональність, слід провести тестування, щоб підтвердити, що зміни виправили дефект або реалізували функціональні можливості належним чином і не спричинили жодних непередбачуваних несприятливих наслідків.

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

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

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

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

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

Підтверджувальне тестування означає повторне тестування дефекту або помилки, щоб переконатися, що його було усунуто. Якщо дефект не усунуто, то його потрібно відкрити заново (reopen). Якщо дефект виправлено, то його закривають.

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

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

Методи регресійного тестування

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

• Повторно протестувати все: Це один із методів регресійного тестування, зокрема із застосуванням набору регресійних тестів. У цьому випадку всі тести в наявному тестовому сегменті або наборі потрібно виконати повторно. Це дорогий спосіб, оскільки вимагає багато часу та ресурсів.
• Вибір тестів для тестування регресії: це техніка, за якої виконуються деякі вибрані тести з набору тестів. Це допомагає перевірити, чи впливає змінений код на програмне забезпечення чи ні. Тут тестові кейси поділяються на дві частини. Повторно використовувані тестові кейси можна використовувати в наступних циклах регресії, тоді як застарілі тестові кейси – ні.
• Пріоритезація тестових випадків: залежить від впливу на бізнес, критичності та частоти використання.

Вибір тестів для регресії

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

Ефективний набір регресійних тестів можна створити, вибравши такі типи тестів:

• Тестові кейси модулів, які часто містять дефекти.
• Тестові кейси для функцій, які часто використовуються
• Тестові кейси, які перевіряють ключові характеристики продукту
• Тестові кейси функцій, які зазнали змін.
• Інтеграційні набори
• Складні тестові кейси
• Тестові кейси граничних значень
• Негативні тести

Позитивне / Негативне тестування

За принципами роботи з додатком тестування можна поділити на:

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

Автоматизація регресії

Selenium – популярна платформа з відкритим кодом, яка використовується для автоматизації веб-браузерів. Його ключовий компонент, Selenium WebDriver, надає простий API для взаємодії з веб-елементами, що дозволяє розробникам автоматизувати такі завдання, як натискання кнопок, заповнення форм і навігація сторінками. Завдяки підтримці кількох мов програмування та браузерів Selenium широко використовується для веб-тестування та автоматизації.

Watir – що розшифровується як Web Application Testing in Ruby, є системою тестування з відкритим вихідним кодом, яка фокусується на автоматизації веб-браузерів за допомогою мови програмування Ruby. Він пропонує зручний та інтуїтивно зрозумілий API, який використовує виразний синтаксис Ruby для взаємодії з веб-елементами та імітації дій користувача, таких як натискання кнопок і заповнення форм. Ключова відмінність Watir полягає в його повній інтеграції з Ruby, що робить його улюбленим вибором для тестувальників і розробників, які віддають перевагу Ruby.

IBM DevOps Test UI (Ra­­­­tional Functional Tester) – це автоматизований інструмент функціонального та регресійного тестування для графічного інтерфейсу користувача та тестування на основі даних. Він підтримує низку програм, включаючи веб-додатки, .Net, Java, Siebel, SAP тощо. Платний.

Katalon Studio – це рішення для автоматизованого тестування, яке використовує фреймворки Selenium і Appium для веб-тестування, тестування API, мобільних пристроїв і комп’ютерів. Має обмежену безкоштовну версію.

TestComplete –  розроблений компанією SmartBear Software, є автоматизованим інструментом тестування інтерфейсу користувача, який дозволяє створювати автоматизовані функціональні тести для настільних, веб- та мобільних додатків. Платний.

Smoke testing та Sanity testing

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

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

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

Наприклад, якщо функція, що відповідає за розрахунки видає результат 2*2=3, тоді наврядчи є сенс тестувати більш складні операції, такі як розрахунок складних відсотків, наприклад.

Smoke	Sanity
Перевіряє стабільність нової збірки	Перевіряє стабільність нових функцій або змін коду в існуючій збірці
Охоплює ключові функції наскрізними перевірками	Охоплює певні модулі, у код яких внесено зміни
Може виконуватися як тестувальниками, так і розробниками	Зазвичай виконується тестувальниками
Часто визначаються як підтип приймального тестування (є позиції, що можна відносити до регресійного тестування)	Підтип регресійного тестування

В цьому відео поговоримо про:
00:00 Типи тестування пов’язані зі змінами
03:00 Підтверджувальне та регресійне тестування
06:30 Методи регресійного тестування
08:16 Вибір тестів для регресії
09:38 Позитивне та негативне тестування (ліричний відступ)
10:51 Автоматизація регресії
15:59 Smoke testing та Sanity testing

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

Вгадування помилок (Error guessing)

Вгадування помилок — це техніка, яка використовується для передбачення появи помилок, дефектів і збоїв на основі знань тестувальника, зокрема:

• Як програма працювала в минулому
• Якого типу помилки, як правило, допускаються
• Збої, які виникли в інших програмах

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

Як додаток працював у минулому?

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

Які помилки зазвичай виявляють?

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

Які збої виникли в інших програмах?

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

Підводні камені

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

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

Вгадування помилок буде ефективним, якщо:

• Тестувальник має досвід роботи зі схожими програмами.
• Існує достатньо даних про поведінку та помилки програми
• Ускладнено застосування формальних методів через, наприклад, неповноту чи неточності у вимогах

Дослідницьке тестування (Exploratory testing)

У дослідницькому тестуванні тести одночасно розробляються, виконуються та оцінюються під час виконання тесту. Тестування використовується, щоб дізнатися більше про тестовий об’єкт, глибше вивчити його і створити тести для неперевірених областей.

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

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

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

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

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

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

1. Створіть таксономію помилок (класифікацію)	• Класифікуйте загальні типи несправностей, виявлених у минулих проєктах • Проаналізуйте першопричину проблем або несправностей • Знайдіть ризики та розробіть ідеї для тестування програми.
2. Тестовий чартер	• Що і як тестувати • Тестові ідеї є відправною точкою дослідницького тестування • Тестовий чартер допомагає визначити, як кінцевий користувач може використовувати систему
3. Інтервали часу	• Цей метод передбачає спільну роботу пари тестувальників не менше 90 хвилин • У цьому 90-хвилинному сеансі не повинно бути перерв • Таймбокс можна продовжити або скоротити на 45 хвилин • Цей сеанс заохочує тестувальників реагувати на відповідь системи
4. Перегляд та аналіз результатів	• Оцінка дефектів • Навчання з тестування • Аналіз зон покриття • Зведення вихідних результатів • Порівняйте результати з чартером

Тестування засноване на контрольних списках (Check-list based teting)

У тестуванні на основі контрольного списку тестувальник розробляє, реалізує та виконує тести, щоб охопити умови тестування з контрольного списку.

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

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

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

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

За відсутності детальних тестових кейсів тестування на основі контрольного списку може надати вказівки та певний ступінь узгодженості для тестування.

В цьому відео поговоримо про:
00:15 Техніки засновані на досвіді
02:28 Вгадування помилок
07:49 Дослідницьке тестування
13:57 Тестування на основі контрольного списку