Які бувають етапи та види тестування: докладний розбір

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

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

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

Чому важливо тестувати програми

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

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

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

Автотестування на JavaScript з нуля

Які бувають етапи тестування

Як правило, у більшості проектів етапи тестування схожі. Давайте по черзі їх розберемо.

Опрацювання вимог до продукту

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

Аналіз вимог

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

Розробка стратегії та плану тестування

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

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

Читайте також: Гід за професією тестувальник: чим займається фахівець у сфері QA, скільки заробляє і що треба знати

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

На цьому етапі на основі вимог та аналізу тестувальники створюють тестові випадки, тест-плани, звітність та іншу документацію, яка використовуватиметься під час тестування. Тестова документація визначає, які тести будуть проведені, як буде зібрано результати та як буде оцінено якість ПЗ.

Тестування

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

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

Експлуатація та підтримка

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

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

Читайте також: Які навички потрібні тестувальнику та як їм стати

QA-інженер з нуля до автоматизатора

Які бувають види тестування

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

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

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

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

За характером сценаріїв

Сценарій у тестуванні - це опис того, як користувач взаємодіятиме з готовим продуктом. До цієї групи входять два види тестування: позитивні сценарії та негативні.

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

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

За критеріями запуску програми чи коду

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

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

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

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

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

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

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

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

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

По об'єктам тестування

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

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

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

Функціональне тестування поділяється на підвиди:

Unit-тестування (також модульне тестування) - Проводиться під час створення вихідного коду. На цьому етапі тестуються окремі компоненти програми. Тестувальники пишуть тести, щоб переконатися, що кожен компонент майбутньої програми працездатний і дає правильні результати за різних вхідних даних.
Інтеграційне тестування. На наступному етапі тестується те, як компоненти майбутньої програми взаємодіють між собою.
Системне тестування (End-to-end тестування). На цьому етапі фахівці тестують усі компоненти програми як єдину програму. Тестувальники перевіряють, що продукт коректно обробляє різні сценарії та ситуації.
Приймальне тестування. На останньому етапі продукт тестує вже клієнт чи замовник. Вони перевіряють, чи відповідає проект їхнім очікуванням та вимогам. А ще переконуються, що програма дає правильні результати та працює без помилок.

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

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

Читайте також: Я знав, що бути тестувальником моє покликання: історія Кирила Куртова

Нефункціональне тестування поділяється на підвиди:

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

За рівнем знання системи

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

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

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

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

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

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

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

Під групу "за ступенем знання системи" також підходить ще кілька видів тестування:

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

За часом проведення тестування

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

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

Підсумок

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

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

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

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

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

Познайомтеся із тестуванням безкоштовно

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

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

Розбираємось у тестовій документації

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

Політика якості (Quality policy)

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

Політика тестування (Test policy)

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

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

Стратегія тестування (Test strategy)

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

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

План тестування (Test plan)

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

План тестування також визначає критерії початку та завершення тестування та може містити оцінку ризиків проекту.

Технічне завдання (Technical specification)

Базовий документ для перевірки функціоналу ІТ-продукту. Саме виходячи з нього складають стратегію та план тестування.Технічне завдання містить вимоги ПЗ. У тестах можна перевірити, чи виконуються ці вимоги, і цим визначити, наскільки якісним вийшло ПЗ.

Також QA-фахівці можуть проводити тестування самих вимог.

Історії користувача (User Story)

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

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

Матриця простежуваності вимог (Requirements Traceability Matrix)

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

Тест-кейс (Test Case)

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

Тестовий набір/комплект (Test Suite)

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

Сценарій тестування (Test Scenario)

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

Чек-лист (Check List)

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

Баг-репорт/Звіт про дефекти (Defect Report)

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

Звіт про тестування (Test Report)

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

Резюме

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

Автор Михайло Кулішов

Михайло, професійний партнерський маркетолог, є засновником компанії South Media OÜ, яка була створена у 2018 році та базується в Таллінні.З 2016 року Михайло поїхав із Фінляндії і жив як справжній «цифровий кочівник» в IT-індустрії, мандруючи світом лише з ноутбуком. Михайло працює та пише статті, пов'язані з IT-індустрією.

Види тестування за ступенем формалізації

Наскільки сильне тестування спирається на документацію? Чи можна тестувати без неї і лише на основі свого досвіду? А чи взагалі без знань тестувати можна?

Так, знову та й ще раз так. Давайте розбиратися, як це можливо.

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

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

Тестування на основі тест-кейсів (scripted testing, test case based testing) - формалізований підхід, у якому тестування проводиться на основі заздалегідь підготовлених тест-кейсів, наборів тест-кейсів та іншої документації.

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

Докладніше прочитати про цей вид тестування можна у статті “Основи тестування. Тест-кейси та чек-листи.”.

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

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

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

Існує навіть спеціальний сценарний підхід, що називається сесійним тестуванням (Session-based testing). Як альтернатива сценаріям при виборі дій з додатком іноді можуть використовуватися чек-листи, і тоді цей вид тестування називають тестуванням на основі чек-листів (checklist-based testing).

Якщо при тестуванні на підставі тест-кейсів ми не відхиляємось, то у випадку з дослідницьким тестуванням ми самі вирішуємо куди відхилятися і в якому напрямку рухатись.

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

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

Вільне тестування

Вільне (інтуїтивне) тестування (ad hoc testing) — повністю неформалізований підхід, у якому передбачається використання ні тест-кейсів, ні чек-листів, ні сценаріїв.

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

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

Не плутайте дослідне та вільне тестування.

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

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

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

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

Який метод тестування не вимагає написання тестової документації