Category: Тестування ПЗ

Серія міжнародних стандартів ISO/IEC 25000, також відомих як Системні та програмні вимоги якості і оцінка (System and Software Quality Requirements and Evaluation), визначає характеристики, якими оцінюється якість програмного продукту.

Стандарт ISO/IEC 25010 містить термінологію для визначення, вимірювання та оцінки якості систем та програмних продуктів. Він визначає вісім характеристик якості програмного забезпечення, серед яких: функціональна придатність, рівень продуктивності, сумісність, зручність використання, надійність, безпека, зручність супроводу, портативність.

Стандарт ISO/IEC 25010 є ґрунтовним переглядом стандарту ISO/IEC 9126. У новий стандарт додано додаткові характеристики та підхарактеристики, які детальніше описують процес якості програмного продукту, а також введені уточнення та перегрупування характеристик для більш ясного їх розуміння.

Якість програмного забезпечення –  це здатність програмного продукту, згідно з вказаними умовами, задовольняти встановлені потреби. (ISO 25000:2014).

Функціональна придатність (Functional Suitability)

Функціональна придатність (Functional Suitability) включає функціональну повноту, функціональну правильність, функціональну відповідність.

Функціональна повнота (Functional completeness) — ступінь покриття сукупності функцій всіх визначених завдань і цілей користувача.

Функціональна коректність (Functional correctness) — ступінь забезпечення продуктом чи системою необхідного рівня правильних результатів.

Функціональна відповідність (Functional appropriateness) — ступінь, з яким функції сприяють виконанню завдань і досягненню цілей.

Ефектиність продуктивності (Performance efficiency)

Ефектиність продуктивності (Performance efficiency) включає часові характеристики, використання ресурсів, місткість.

Часові характеристики (Time behaviour) — ступінь відповідності вимогам про час відповіді, час обробки і показники пропускної здатності продукта або системи.

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

Місткість (Capacity) — ступінь відповідності вимогам граничних значень параметрів продукта або системи.

Сумісність (Compatibility)

Сумісність (Compatibility) включає співіснування та  функціональну сумісність.

Співіснування (Co-existence) — здатність продукта сумісно функціонувати з іншими незалежними продуктами у спільній середі з розділенням спільних ресурсів і без негативного впливу на будь-який інший продукт.

Функціональна сумісність (Interoperability) — здатність двох або більше систем, продуктів або компонентів обмінюватис даними і використовувати такі дані.

Зручність використання (Usability)

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

Можливість визначення придатності (Appropriateness recognizability) — можливість користувача зрозуміти чи підходить продукт або система для їхніх потреб.

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

Керованість (Operability) — наявність в продукті або системі атрибутів, які забезпечують просте управління та контроль.

Захист від помилок користувача (User error protection) — рівень системного захисту користувачів від помилок.

Естетика користувацького інтерфейсу (User interface aesthetics) — ступінь задоволеності користувача інтерфейсом взаємодії.

Доступність (Accessibility) — можливість викорситання продукту або системи для досягнення певної мети у вказаному контексті використання широким колом осіб з різними можливостями.

Надійність (Reliability)

Надійність (Reliability) включає зрілість, готовність, відмовостійкісь, відновлюваність.

Зрілість (Maturity) — ступінь відповідності системи, продукта або компонента при нормальній роботі вимогам надійності.

Готовність (Availability) — ступінь працездатності і доступності системи, продукта або компонента.

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

Відновлюваність (Revoverability) — здатність продукта або системи відновити дані та необхідний стан системи у випадку переривання або збою.

Безпека (Security)

Безпека (Security) включає неможливість заперечення, цілісність, конфіденційність, відстежуваність, автентичність.

Неможливість заперечувати (Non-repudiation) — впевненість, що хтось не може заперечувати дійсність чогось. Себто можливісь беззаперечно довести факт події або дії таким чином, що цей факт не можна заперечити.

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

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

Відстежуваність (Accountability) — ступінь, до якої дії об’єкта можуть бути відстежені однозначно.

Автентичність (Authenticity) — ступінь достовірності, відповідності об’єкта або ресурса необхідному об’єкту або ресурсу.

Зручність супроводу (Maintainability)

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

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

Можливість багаторазового використання (Reusability) — ступінь, в якій актив може бути використаний в декількох системах чи при створенні інших активів.

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

Можливість модифікацій (Modifiability) — ступінь простоти ефективної та раціональної зміни продукту або системи без додавання дефектів та зниження якості продукта.

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

Портативність (Portability)

Портативність (Portability) включає можливість адаптації, можливість встановлення, можливість заміни.

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

Можливість встановлення (Installability) — ступінь простоти ефективного, раціонального, успішного встановлення або видалення продукта або системи в заданому середовищі.

Можливість заміни (Replaceability) — здатність продукта замінити інший конкретний програмний продукт для досягнення тих самих цілей в тих же умовах.

Вимоги до програмного забезпечення

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

Розробка вимог

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

Метою розробки вимог є розробка та підтримка складного, описового документа “Специфікація системних вимог”.

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

• Техніко-економічне обґрунтування
• Збір вимог
• Специфікація вимог до програмного забезпечення
• Перевірка вимог програмного забезпечення

ТЕО (техніко-економічне обґрунтування)

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

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

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

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

Збір вимог

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

Специфікація вимог до програмного забезпечення

SRS — це документ, створений системним аналітиком після збору вимог від різних зацікавлених сторін.

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

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

Перевірка вимог програмного забезпечення

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

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

Процес виявлення вимог

Процес виявлення вимоги містить наступні фази:

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

Методи виявлення вимог

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

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

Інтерв’ю (співбесіди)

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

• Структуровані (закриті) інтерв’ю, де кожна окрема інформація, яку потрібно зібрати, вирішується заздалегідь, вони чітко слідують шаблону та предмету обговорення.
• Неструктуровані (відкриті) інтерв’ю, де інформація для збору не вирішується заздалегідь, більш гнучкі та менш упереджені.
• Усні опитування
• Письмові інтерв’ю
• Індивідуальні співбесіди, які проводяться між двома людьми за столом.
• Групові інтерв’ю, які проводяться між групами учасників. Вони допомагають виявити будь-які відсутні вимоги, оскільки задіяно багато людей.

Опитування

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

Анкети

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

Розбір задачі

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

Аналіз домену

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

Мозковий штурм

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

Прототипування

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

Спостереження

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

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

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

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

• Ясною
• Правильною
• Послідовною
• Зрозумілою
• Можливою для внесення модифікацій, змін
• Можливою для перевірки
• Пріоритизованою
• Однозначною
• Відстежуваною

Функціональні та нефункціональні вимоги

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

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

В цьому відео поговоримо про якість ПЗ та вимоги
00:06 Якість ПЗ
06:17 Функціональна придатність
07:34 Ефектиність продуктивності
08:32 Сумісність
09:40 Зручність використання
12:21 Надійність
13:37 Безпека
17:25 Зручність супроводу
19:43 Портативність
20:45 Вимоги до ПЗ
22:11 Розробка вимог
23:18 Техніко-економічне обґрунтування
24:44 Збір вимог
25:10 Специфікація вимог до ПЗ
26:31 Перевірка вимог до ПЗ
27:48 Процес виявлення вимог
29:25 Методи виявлення вимог
33:22 Функціональні і нефункціональні вимоги

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

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

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

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

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

Тестування білої скриньки (White-Box) базується на структурі та виводить тести з реалізації або внутрішньої структури системи (наприклад, коду, архітектури, робочих процесів і потоків даних). Основна мета тестування білої скриньки – охопити базову структуру тестами до прийнятного рівня.

Тестування чорної скриньки (Black-box) базується на специфікаціях і одержує тести з зовнішньої документації щодо об’єкта тестування. Основна мета тестування чорної скриньки – перевірити поведінку системи на відповідність її специфікаціям.

Функціональне тестування (Functional) оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.

Нефункціональне тестування (Non-functional) оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, “наскільки добре поводиться система”. Основною метою нефункціонального тестування є перевірка характеристик якості нефункціонального програмного забезпечення (продуктивність, зручність використання, відновлення, сумісність, безпека).

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

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

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

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

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

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

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

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

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

В цьому відео поговоримо про типи та рівні тестування
00:05 Типи тестування
19:59 Рівні тестування

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

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

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

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

Аналіз вимог

Аналіз вимог є першим кроком життєвого циклу тестування програмного забезпечення (STLC). На цьому етапі команда із забезпечення якості вивчає вимоги, наприклад те, що має бути перевірено. Якщо чогось не вистачає або щось є незрозумілим, тоді команда із забезпечення якості зустрічається із зацікавленими сторонами, щоб краще зрозуміти вимоги.

Діяльність, яка виконується на етапі аналізу вимог, включає:

• Перегляд документа вимог до програмного забезпечення (SRD) та інших пов’язаних документів
• Опитування зацікавлених сторін для збору додаткової інформації
• Виявлення будь-яких двозначностей або невідповідностей у вимогах
• Виявлення будь-яких відсутніх або неповних вимог
• Виявлення будь-яких потенційних ризиків або проблем, які можуть вплинути на процес тестування
• Створення матриці відстеження вимог (RTM)

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

Планування тестування

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

Діяльність, яка виконується на етапі планування тесту, включає:

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

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

Розробка тестових кейсів

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

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

• Визначення тестів, які будуть розроблені
• Написання тестів, які є ясними, лаконічними та легкими для розуміння
• Створення тестових даних, які будуть використовуватися в тестових випадках
• Визначення очікуваних результатів для кожного тесту
• Перегляд і перевірка тестів
• Оновлення матриці відстеження вимог (RTM) для пов’язання вимог з тестовми випадками

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

Налаштування тестового середовища

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

Виконання тестування

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

Діяльність, яка виконується на етапі виконання тестування, включає:

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

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

Завершення тестування

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

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

Основні дії, які відбуваються на етапі завершення тестування, включають:

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

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

Тестовий процес

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

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

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

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

Тестовий аналіз часто підтримується використанням тестових методів. Аналіз тестів відповідає на питання «що тестувати?» з точки зору вимірних критеріїв покриття.

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

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

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

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

В цьому відео поговоримо про STLC
00:05 STLC
01:13 Фази STLC
02:16 Аналіз вимог
04:36 Планування тестування
06:59 Розробка тестових кейсів
09:04 Налаштування тестового середовища
10:24 Виконання тестування
12:32 Завершення тестування
16:36 Тестовий процес