Тестування ПЗ (види тестування)

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

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

Тестування — це порівняння очікуваного результату з актуальним, і цих порівнянь може бути безліч. Всі перевірки можна згрупувати по категоріям.

Класифікація тестування

•   За об’єктом тестування:

  • функціональне тестування (functional testing);

  • дослідницьке тестування (exploratory testing);

  • тестування продуктивності (performance testing);

  •   навантажувальне тестування (load testing);

  • димне тестування (smoke testing);

  •   стрес-тестування (stress testing);

  •   тестування стабільності (stability / endurance / soak testing);

  • тестування зручності використання (usability testing);

  • тестування інтерфейсу користувача (ui testing);

  • тестування безпеки (security testing);

  • тестування локалізації (localization testing);

  • тестування сумісності (compatibility testing).

• За залежністю від цілей тестування:

  • функціональне тестування (functional);

  •  нефункціональне тестування (non-functional);

  • тестування пов’язане зі змінами.

• За знанням системи:

  • тестування чорної скриньки (black box);

  • тестування білої скриньки (white box);

  • тестування сірої скриньки (gray box).

• За ступенем автоматизації:

  • ручне тестування (manual testing);

  • автоматизоване тестування (automated testing);

  • напівавтоматизоване тестування (semiautomated testing).

• За ступенем ізольованості компонентів:

  • компонентне (модульне) тестування (component / unit testing);

  • інтеграційне тестування (integration testing);

  • системне тестування (system / end-to-end testing).

• За часом проведення автоматизації:

  • Альфа-тестування (alpha testing):

  • тестування нової функціональності (new feature testing);

  • регресійне тестування (regression testing);

  • тестування при здачі (acceptance testing);

  • Бета-тестування (beta testing).

• За позитивністю сценаріїв:

  • позитивне тестування (positive testing);

  • негативне тестування (negative testing).

• За ступенем підготовки:

  • тестування за документацією (formal testing);

  • Ad Hoc Testing (інтуїтивне) тестування (ad hoc testing).

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

Функціональне тестування 

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

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

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

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

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

• масштабованість – визначає максимальне навантаження (запити, нові користувачі, задачі), яке може витримати програма;

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

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

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

Це тестування рекомендується проводити на початковому етапі проєктування SDLC (Software Development Life Cycle - Життєвий цикл розробки програмного забезпечення), що дає більше інформації про очікування користувачів.

Важлива естетика і дизайн. Те, наскільки добре виглядає продукт, зазвичай визначає, наскільки добре він працює. У користувачів не мають виникати такі питання як: “Що мені натиснути далі?”,  “Який значок або слово що означає?”, “Що станеться, якщо я натисну це?”. Також перевіряється, щоб повідомлення про помилки відображалися вчасно та були зрозумілими. Розробка програмного забезпечення, тестування зручності використання виявляє помилки зручності використання в системі на ранніх етапах циклу розробки та може врятувати продукт від збою.

Тестування інтерфейсу користувача

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

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

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

Тестування локалізації 

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

• у якому кутку звичне розташування кнопок,

• з якого місця на сторінці користувачі звикли починати читати,

• до яких кольорів чи символів люди звикли або які не бажають бачити.

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

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

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

Тестування чорного ящика

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

Загальні кроки для проведення будь-якого типу тестування чорної скриньки:

• Спочатку перевіряються вимоги та характеристики системи.

• Тестувальник або тестувальниця вибирає дійсні вхідні дані (позитивний тестовий сценарій), щоб перевірити, чи SUT (System under test) обробляє їх правильно. Крім того, деякі недійсні вхідні дані (негативний тестовий сценарій) вибираються для перевірки того, що SUT здатний їх виявити.

• Тестувальник або тестувальниця визначає очікувані результати для всіх цих входів.

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

• Тестові випадки виконано.

• Тестувальник або тестувальниця програмного забезпечення порівнює фактичні результати з очікуваними.

• Дефекти, якщо такі є, усуваються та перевіряються повторно.

Тестування білого ящика 

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

Тестування білого ящика передбачає перевірку програмного коду для наступного:

• Внутрішні отвори безпеки

• Порушені або погано структуровані шляхи в процесах кодування

• Потік конкретних вхідних даних через код

• Очікуваний результат

• Функціональність умовних циклів

• Тестування кожного оператора, об'єкта та функції на індивідуальній основі (unit тести)

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

Тестування сірого ящика 

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

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

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

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

Тестування сірого ящика виконується з наступних причин:

• Забезпечує сукупні переваги як тестування чорної скриньки, так і тестування білої скриньки;

• Поєднує внесок розробників і тестувальників і покращує загальну якість продукту;

• Зменшує накладні витрати на тривалий процес тестування функціональних і нефункціональних типів;

• Дає розробнику достатньо вільного часу для виправлення недоліків;

• Проводиться з точки зору користувача, а не з точки зору дизайнера.

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

Техніки, які використовуються для тестування в сірому ящику це:

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

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

• Тестування ортогонального масиву або OAT — забезпечує максимальне покриття коду з мінімальною кількістю тестів.

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

Тестові випадки для тестування сірого ящика можуть бути пов’язані з:

• графічним інтерфейсом користувача,

• безпекою,

• базами даних,

• браузером,

• операційною системою, тощо.

Компонентне тестування

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

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

Тестування компонентів виконується невдовзі після завершення модульного тестування розробниками та випуску збірки для команди тестування. Ця збірка називається збіркою UT ( Unit Testing Build - збірка модульного тестування).

Вхідним критерієм для тестування компонентів є мінімальна кількість компонентів, які будуть включені в UT, повинна бути розроблена та протестована.

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

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

Інтеграційне тестування зосереджується на перевірці передачі даних між цими модулями. Тому його також називають «I & T» (інтеграція та тестування), «тестування рядків» і іноді «тестування потоків».

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

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

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

• Інтерфейси програмних модулів з базою даних можуть бути помилковими.

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

• Неадекватна обробка винятків може спричинити проблеми.

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

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

Тестування системи передбачає тестування програмного коду для:

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

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

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

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

Основними видами діяльності, пов’язаними з наскрізним тестуванням, є:

• Вивчення вимог до наскрізного тестування.

• Налаштування тестового середовища та вимоги до апаратного / програмного забезпечення.

• Описання всіх процесів системи та її підсистем.

• Описання ролей і обов'язків для всіх систем.

• Методологія та стандартизація тестування.

• Наскрізне відстеження вимог і проєктування тестових випадків.

• Вхідні та вихідні дані для кожної системи.

Ручне тестування 

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

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

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

Напівавтоматичне тестування 

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

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

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

Бета-тестування 

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

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

Ключова різниця між альфа- та бета-тестуванням:

• Альфа-тестування виконується тестувальниками й тестувальницями в організації, тоді як бета-тестування виконується кінцевими користувачами.

• Альфа-тестування виконується на сайті розробника, тоді як бета-тестування виконується на сайті клієнта.

• Тестування надійності та безпеки не виконується поглиблено під час альфа-тестування, проте вони перевіряються під час бета-тестування.

• Альфа-тестування передбачає тестування як Whitebox, так і Blackbox, тоді як бета-тестування в основному включає тестування Blackbox.

• Альфа-тестування потребує тестового середовища, а бета-тестування не потребує тестового середовища.

• Альфа-тестування вимагає тривалого циклу виконання, тоді як бета-тестування вимагає лише кількох тижнів виконання.

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

Димове тестування 

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

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

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

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

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

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

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

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

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

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

Негативне тестування 

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

Тестування документації 

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

Аd hoc (дослідницьке) тестування 

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

Висновок

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

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