Тестування програмного забезпечення

Цикл розробки програмного забезпечення
Програміст за роботою
Діяльність та кроки
Вимоги ·  Специфікація Архітектура ·  Дизайн Реалізація ·  Тестування Розгортання ·  Підтримка
Методології
Гнучка ·  Чистого приміщення DSDM ·  Iterative ·  RAD ·  RUP Spiral ·  Водоспад ·  XP ·  Scrum Lean ·  V-Model ·  FDD ·  TDD
Допоміжні дисципліни
Конфігураційне керування Документування Якість ПЗ Управління проектами User experience design
Інструменти
Компілятор ·  Зневаджувач Профілювальник GUI designer ·  IDE

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

Вступ

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

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

Зазвичай, поняття якості обмежується такими поняттями, як коректність, надійність, практичність, безпечність, але може містити більше технічних вимог, які описані в стандарті ISO 9126. Склад і зміст супутньої документації процесу тестування, визначається стандартом IEEE 829–1998 Standard for Software Test Documentation. Існує багато підходів до тестування програмного забезпечення, але ефективне тестування складних продуктів — це по суті дослідницький та творчий процес, а не тільки створення і виконання рутинної процедури.

Історія розвитку тестування програмного забезпечення

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

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

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

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

На початку 1990-х в поняття «тестування» стали включати планування, проектування, створення, підтримку і виконання тестів і тестових оточень, і це означало перехід від тестування до забезпечення якості, що охоплює весь цикл розробки ПЗ. У цей час починають з'являтися різні програмні інструменти для підтримки процесу тестування: більш просунуті середовища для автоматизації з можливістю створення скриптів і генерації звітів, системи управління тестами, ПЗ для проведення навантажувального тестування. У середині 1990-х з розвитком Інтернету і розробкою великої кількості веб-додатків особливу популярність стало отримувати «гнучке тестування» (за аналогією з гнучкими методологіями програмування).

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

Основні поняття та визначення

Тестування — це одна з технік контролю якості, що включає в себе

• Планування робіт (Test Management)
• Проектування тестів (Test Design)
• Виконання тестування (Test Execution)
• Аналіз отриманих результатів (Test Analysis).

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

Валідація (Validation) — це визначення відповідності розроблюваного програмного забезпечення між очікуваннями і потребами користувача, вимогам до системи.

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

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

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

Баг/Дефект Репорт (Bug Report) — це документ, що описує ситуацію або послідовність дій (Steps), що призвела до некоректної роботи об'єкта тестування (Misbehavior), із зазначенням причин та очікуваного результату (Expected Result).

Тестове Покриття (Test Coverage) — це одна з метрик оцінки якості тестування, що представляє із себе щільність покриття тестами вимог або коду, що виконується.

Деталізація Тест Кейсів (Test Case Specification) — це рівень деталізації опису тестових кроків і необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.

Час Проходження Тест Кейса (Test Case Pass Time) — це час від початку проходження кроків тест кейса до отримання результату тесту.

Методи тестування

Статичне та динамічне тестування

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

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

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

Тестування "білої скриньки"

Відома: внутрішня структура програми.
Досліджуються: внутрішні елементи програми і зв'язки між ними.

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

Особливості тестування "білої скриньки"

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

У цьому випадку формуються тестові варіанти, в яких:

• Гарантується перевірка всіх незалежних маршрутів програми.
• Знаходяться гілки True, False для всіх логічних рішень.
• Виконуються всі цикли (в межах їх кордонів і діапазонів).
• Аналізується правильність внутрішніх структур даних.

Недоліки тестування "білої скриньки":

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

Переваги тестування "білої скриньки» пов'язані з тим, що принцип «білої скриньки» дозволяє врахувати особливості програмних помилок:

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

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

Тестування "чорної скриньки"

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

Основне місце програми тестів «чорної скриньки» - інтерфейс ПЗ.

Ці тести демонструють:

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

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

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

• Набір, утворений такими вхідними даними, які приводять до аномалій у поведінці програми (назвемо його IT);
• Набір, утворений такими вхідними даними, які демонструють дефекти програми (назвемо його OT).

Будь-який спосіб тестування «чорної скриньки» повинен:

• Виявити такі вхідні дані, які з високою ймовірністю належать набору IT;
• Сформулювати такі очікувані результати, які з високою імовірністю є елементами набору OT.

Принцип «чорної скриньки» не альтернативний принципом "білої скриньки". Скоріше це доповнює підхід, який виявляє інший клас помилок.

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

• Некоректних чи відсутніх функцій;
• Помилок інтерфейсу;
• Помилок у зовнішніх структурах даних або в доступі до зовнішньої базі даних;
• Помилок характеристик (необхідна ємність пам'яті і т.д.);
• Помилок ініціалізації та завершення.

Подібні категорії помилок способами «білої скриньки" не виявляються.

Види тестування програмного забезпечення

Класифікація за ознаками

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

• Ручне тестування (manual testing)
• Автоматизоване тестування (automated testing)
• Напівавтоматизоване тестування (semiautomated testing)

За ступенем підготовленості до тестування:

• Тестування по документації (formal testing)
• Тестування ad hoc або інтуїтивне тестування (ad hoc testing) — тестування без тест плану та документації, що базується на методиці передбачення помилки та власному досвіді тестера.

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

• Тестування чорного ящика (black box)
• Тестування білого ящика (white box)
• Тестування сірого ящика (grey box)

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

• Компонентне (модульне) тестування (component/unit testing)
• Інтеграційне тестування (integration testing)
• Системне тестування (system/end-to-end testing)

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

• Альфа-тестування (alpha testing)
  • Тестування при прийманні або Димове тестування(smoke testing)
  • Тестування нової функціональності (new feature testing)
  • Регресивне тестування (regression testing)
  • Тестування при здачі (acceptance testing)
• Бета-тестування(beta testing)

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

• Функціональне тестування (functional testing)
• Тестування продуктивності (performance testing)
  • Навантажувальне тестування (load testing)
  • Стрес-тестування (stress testing)
  • Тестування стабільності (stability/endurance/soak testing)
• Тестування зручності використання або Юзабіліті-тестування (usability testing)
• Тестування інтерфейсу користувача (UI testing)
• Тестування безпеки (security testing)
• Тестування локалізації (localization testing)
• Тестування сумісності (compatibility testing)

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

• Позитивне тестування (positive testing)
• Негативне тестування (negative testing)

Опис видів тестування

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

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

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

Основною метою якого являється перевірка коректної роботи продукту в певному середовищі. Середовище може включати в себе наступні елементи:

• Апаратна платформа
• Мережеві пристрої
• Периферія (принтери, CD/DVD-приводи, веб-камери та ін.);
• Операційна система (Unix, Windows, MacOS, ...)
• Бази даних (Oracle, MS SQL, MySQL, ...)
• Системне програмне забезпечення (веб-сервер, фаєрвол, антивірус, ...)
• Браузери (Internet Explorer, Firefox, Opera, Chrome, Safari)

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

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

Регресивне тестування

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

Регресивне тестування (за деякими джерелами) включає:

• new bug-fix — перевірка виправлення знайдених дефектів;
• old bug-fix — перевірка, що виявлені раніше й виправлені дефекти не відтворюються в системі знову;
• side-effect — перевірка того, що не порушилася працездатність працюючої раніше функціональності, якщо її код міг бути зачеплений під час виправлення деяких дефектів в іншій функціональності.

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

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

Функціональні вимоги включають в себе:

• Функціональна придатність
• Точність
• Можливість до взаємодії
• Відповідність стандартам і правилам
• Захищеність

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

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

• Всі види тестування продуктивності:
  • навантажувальне тестування
  • стресове тестування
  • тестування стабільності і надійності
  • об'ємне тестування
• Інсталяційне тестування
• Тестування зручності користування
• Тестування на "відказ" та відновлення
• Конфігураційне тестування

Деструктивне тестування

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

Тестування швидкодії

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

В тестуванні швидкодії виділяють такі напрямки:

• навантажувальне
• стрес
• тестування стабільності
• конфігураційне

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

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

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

Модульне тестування

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

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

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

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

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

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

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

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

• компонентний інтеграційний рівень (Component Integration testing). Перевіряється взаємодія між компонентами системи після проведення компонентного тестування;

• системний інтеграційний рівень (System Integration Testing). Перевіряється взаємодія між різними системами після проведення системного тестування.

Підходи до інтеграційного тестування:

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

• зверху вниз (Top Down Integration). У першу чергу тестуються компоненти верхнього рівня ієрархії об'єктів з використанням заглушок замість компонентів більш низького рівня;

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

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

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

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

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

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

Тестові скрипти

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

Покриття коду

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

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

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

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

Приймальне тестування виконується на підставі набору типових тестових випадків і сценаріїв, розроблених на підставі вимог до даного додатку. Рішення про проведення приймального тестування приймається тоді, коли: продукт досяг необхідного рівня якості; замовник ознайомлений з Планом приймальних Робіт (Product Acceptance Plan) або іншим документом, де описаний набір дій, пов'язаних з проведенням приймального тестування, дата проведення, відповідальні тощо.

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

Дивіться також

• Якість програмного забезпечення
• Технологія розробки програмного забезпечення
• Зворотне семантичне трасування
• JUnit
• Багтрекер

Література

• Лайза Криспин, Джанет Грегори Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд = Agile Testing: A Practical Guide for Testers and Agile Teams. — М.: «Вильямс», 2010. — 464 с. — (Addison-Wesley Signature Series). — 1000 прим. — ISBN 978-5-8459-1625-9
• Канер Кем, Фолк Джек, Нгуен Енг Кек Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений. — Киев: ДиаСофт, 2001. — 544 с. — ISBN 9667393879
• Калбертсон Роберт, Браун Крис, Кобб Гэри Быстрое тестирование. — М.: «Вильямс», 2002. — 374 с. — ISBN 5-8459-0336-X
• Синицын С. В., Налютин Н. Ю. Верификация программного обеспечения. — М.: БИНОМ, 2008. — 368 с. — ISBN 978-5-94774-825-3
• Бейзер Б. Тестирование чёрного ящика. Технологии функционального тестирования программного обеспечения и систем. — СПб.: Питер, 2004. — 320 с. — ISBN 5-94723-698-2

Посилання

• IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004 (англ.)
• The Test Management Guide — A to Z and FAQ Knowledgebase (англ.)
• Текст лекцій до курсу «Технології розробки і тестування програм» Дідковська М. В.
• Про Тестинг — Тестирование Программного Обеспечения (рос.)
• Портал специалистов по тестированию и обеспечению качества ПО(рос.)
• Портал об автоматизированном тестировании ПО(рос.)
• Качество программного обеспечения(рос.)
• Портал об автоматизированном тестировании ПО(рос.)
• Я — QA | Скажи багам нет!(рос.)