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

1.1.2. Тестування та налагодження (debugging)

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

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

Типовий процес налагодження в цьому випадку включає:

• Відтворення помилки
• Діагностику (знаходження першопричини) •
• Усунення причини

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

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

1.2. Чому потрібне тестування?

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

1.2.1. Як зробити тестування успішним

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

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

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

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

1.2.2. Тестування та забезпечення якості (QA)

Хоча люди часто використовують терміни «тестування» та «забезпечення якості» (QA) як взаємозамінні, тестування та QA — це не одне й те саме. Тестування є формою контролю якості.

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

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

Результати випробувань використовуються QA та QC. У QC вони використовуються для усунення дефектів, тоді як у QA вони забезпечують зворотній зв’язок про те, наскільки добре виконуються процеси розробки та тестування.

1.2.3. Помилки, дефекти, збої та першопричини

Люди роблять помилки (errors), які породжують дефекти (несправності, defects, bugs, faults), які, у свою чергу, можуть призвести до збоїв (failures). Люди роблять помилки з різних причин, таких як нестача часу, складність робочих продуктів, процесів, інфраструктури чи взаємодії, або просто тому, що вони втомилися чи не мають належного навчання.

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

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

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

1.3. Принципи тестування

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

1. Тестування показує наявність, а не відсутність дефектів. Тестування може показати наявність дефектів в тестовому об’єкті, але не може довести, що дефектів немає (Buxton 1970). Тестування знижує ймовірність того, що дефекти залишаться невиявленими в об’єкті тестування, але навіть якщо дефектів не буде виявлено, тестування не може підтвердити правильність об’єкта тестування.
2. Вичерпне тестування неможливе. Перевірити все неможливо, за винятком тривіальних випадків (Manna 1978). Замість того, щоб намагатися провести вичерпне тестування, слід використовувати методи тестування (див. розділ 4), визначення пріоритетів тестових випадків (див. розділ 5.1.5) і тестування на основі ризику (див. розділ 5.2), щоб зосередити зусилля на тестуванні.
3. Раннє тестування економить час і гроші. Дефекти, усунені на ранній стадії процесу, не призведуть до подальших дефектів у похідних робочих продуктах. Вартість якості буде знижена, оскільки пізніше в SDLC виникатиме менше збоїв (Boehm 1981). Щоб виявити дефекти на ранній стадії, як статичне тестування (див. розділ 3), так і динамічне тестування (див. розділ 4) слід починати якомога раніше.
4. Дефекти групуються разом. Невелика кількість системних компонентів зазвичай містить більшість виявлених дефектів або відповідальна за більшість операційних збоїв (Enders 1975). Це явище є ілюстрація принципу Парето. Прогнозовані кластери дефектів і фактичні кластери дефектів, які спостерігаються під час тестування або під час експлуатації, є важливими вхідними даними для тестування на основі ризику (див. розділ 5.2).
5. Тести зношуються. Якщо ті самі тести повторювати багато разів, вони стають все більш неефективними у виявленні нових дефектів (Beizer 1990). Щоб подолати цей ефект, може знадобитися модифікувати існуючі тести та тестові дані, а також написати нові тести. Однак у деяких випадках повторення тих самих тестів може мати позитивний результат, наприклад, у автоматизованому регресійному тестуванні (див. розділ 2.2.3).
6. Тестування залежить від контексту. Немає єдиного універсального підходу до тестування. Тестування проводиться по-різному в різних контекстах (Kaner 2011).
7. Помилка про відсутність дефектів. Очікувати, що перевірка програмного забезпечення забезпечить успішну роботу системи, є помилкою (тобто помилковим уявленням). Ретельне тестування всіх зазначених вимог і усунення всіх виявлених дефектів все одно може призвести до створення системи, яка не відповідає потребам і очікуванням користувачів, яка не сприяє досягненню бізнес-цілей замовника та є гіршою порівняно з іншими системами-конкурентами. На додаток до верифікації також має бути проведена перевірка (Boehm 1981).

1.4. Тестові дії, тестове програмне забезпечення та ролі тестування

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

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

Стандарт ISO/IEC/IEEE 29119-2 надає додаткову інформацію про процеси тестування.

1.4.1. Тестові дії та завдання

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

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

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

Аналіз тестування включає аналіз основи тестування для виявлення функцій, які можна перевірити, а також для визначення пріоритетів, пов’язаних умов тестування разом із відповідними ризиками та рівнями ризику (див. розділ 5.2). Тест-основа та тест-об’єкти також оцінюються для виявлення дефектів, які вони можуть містити, і для оцінки їх тестування. Тестовий аналіз часто підтримується використанням тестових методик (див. розділ 4). Аналіз тестів відповідає на питання «що тестувати?» з точки зору вимірних критеріїв покриття.

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

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

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

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

1.4.2. Процес тестування в контексті

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

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

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

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

1. Робочі продукти з планування тестування включають: план тестування, графік тестування, реєстр ризиків, а також критерії входу та виходу (див. розділ 5.1). Реєстр ризиків – це перелік ризиків разом із імовірністю ризику, впливом ризику та інформацією про пом’якшення ризику (див. розділ 5.2). Графік тестування, реєстр ризиків і критерії входу та виходу часто є частиною плану тестування. Робочі продукти з планування тестування включають: план тестування, графік тестування, реєстр ризиків, а також критерії входу та виходу (див. розділ 5.1).

2. Продукти моніторингу та контролю тестування включають: звіти про хід тестування (див. розділ 5.3.2), документацію контрольних директив (див. розділ 5.3) та інформацію про ризики (див. розділ 5.2).

3. Робочі продукти тестового аналізу включають: (пріоритезовані) умови тестування (наприклад, критерії прийнятності, див. розділ 4.5.2) і звіти про дефекти щодо дефектів у основі тестування (якщо не виправлено безпосередньо).

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

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

6. Робочі продукти виконання тесту включають: журнали тестування та звіти про дефекти (див. розділ 5.5).

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

1.4.4. Відстеження (Traceability) між тестовою основою та тестовим програмним забезпеченням

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

• Відстеження тестових випадків до вимог може підтвердити, що вимоги охоплені тестовими випадками.

• Простежуваність результатів випробувань щодо ризиків може бути використана для оцінки рівня залишкового ризику в об’єкті випробувань.

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

1.4.5. Ролі в тестуванні

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

Керівник тестування (The test management role) бере на себе загальну відповідальність за процес тестування, команду тестування та керівництво тестовою діяльністю. Роль управління тестуванням головним чином зосереджена на діяльності з планування тестування, моніторингу та контролю тестування та завершення тестування. Спосіб виконання ролі керування тестуванням залежить від контексту. Наприклад, у Agile-розробці програмного забезпечення деякі завдання керування тестуванням може виконувати команда Agile. Завдання, які охоплюють кілька команд або всю організацію, можуть виконувати менеджери тестування поза командою розробників.

Роль тестування (The testing role) бере на себе загальну відповідальність за інженерний (технічний) аспект тестування. Роль тестування в основному зосереджена на аналізі тестів, дизайні тестів, реалізації та виконанні тестів.

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

1.5. Основні навички та хороші практики під час перевірки

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

1.5.1. Загальні навички, необхідні для тестування

Хоча такі навички є загальними, вони особливо актуальні для тестувальників:

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

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

1.5.2. Вся команда у роботі

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

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

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

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

1.5.3. Незалежність тестування

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

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

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

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