Життєвий цикл тестування ПЗ (STLC - Software Testing Lifecycle)
PreviousЖиттєвий цикл розробки програмного забезпечення (SDLC - Software Development Lifecycle)NextМоделі розробки ПЗ
Last updated
Last updated
STLC - це процес тестування, який включає певну послідовність кроків, щоб гарантувати досягнення цілей в області якості. У процесі STLC кожна дія виконується планомірно та систематично. Кожен етап має різні цілі та результати. У різних організацій різні етапи STLC, проте основа залишається незмінною.
Кожна фаза STLC має критерії початку та закінчення :
Критерії входу (entry criteria): Набір загальних та специфічних умов для продовження процесу з певним завданням, наприклад, фаза тестування. Мета критеріїв входу - запобігання початку завдання, яке може вимагати більше (безкорисних) зусиль, ніж усунення не пройдених критеріїв входу. (Gilb and Graham)
Критерії виходу (exit criteria): Набір загальних і специфічних умов, узгоджених заздалегідь із заінтересованими сторонами, щоб процес міг офіційно вважатися завершеним. Мета критеріїв виходу – запобігання можливості, коли завдання вважається завершеним, проте ще існують окремі незавершені частини завдання. Критерії виходу використовуються для звітності, а також для планування того, коли зупинити тестування. (Gilb and Graham)
Фази STLC
STLC має кілька взаємозалежних фаз і загалом дуже схожий на SDLC. Ці фази є послідовними і називаються:
Аналіз вимог (Requirement Analysis): один із найважливіших етапів, тому що саме на ньому можна майже безкоштовно виправити недоліки проекту. Етап аналізу вимог також визначає потенційну потребу в автоматизованому тестуванні та дозволяє проводити економічні розрахунки витрат на робочу силу на основі оцінки проекту. На цьому ж етапі обговорюються та документуються критерії початку та закінчення тестування.
Entry Criteria: BRS (Business Requirement Specification)
Deliverables: список всіх вимог, що перевіряються, техніко-економічне обґрунтування автоматизації (якщо застосовно);
Планування тестування (Test Planning): цьому етапі формується план тестування, тобто. ми визначаємо дії та ресурси, які допоможуть досягти цілей тестування (учасники та їх ролі, інструменти, оточення). Під час планування ми також намагаємося визначити метрики, метод збирання та відстеження цих метрик. План складають виходячи з вимог, тестової стратегії та аналізу ризиків.
Entry Criteria: Requirements Documents;
Відповідні: Test Strategy, Test Plan, і Test Effort estimation document.
Розробка тест-кейсів (Test Case Development): передбачає використання ручного та автоматизованого тестування для досягнення повного охоплення функціональності програмного забезпечення, при цьому процес базується на заздалегідь встановлених вимогах. Найчастіше тест-кейси для автоматичного тестування пишуться окремо, оскільки кейси для ручного тестування описані як шпаргалок (cheat sheets).
Entry Criteria: Requirements Documents (Updated version);
Deliverables: Test cases, Test Scripts (if automation), Test data.
Налаштування тестового середовища (Test Environment Setup): у плані тестування чітко вказано, яке тестове середовище слід використовувати. На цьому етапі STLC налаштовуються операційні системи та віртуальні машини, розгортаються інструменти тестування, такі як Selenium, Katalon Studio, а також тестове середовище та бази даних проекту. Ми також звертаємося з запитами до DevOps та адміністраторів, якщо потрібна підтримка.
Entry Criteria: Test Plan, Smoke Test cases, Test Data;
Deliverables: Test Environment. Smoke Test Results.
Виконання тестів (Test Execution): тести виконуються на основі готової тестової документації та правильно налаштованого тестового середовища. Усі результати тестування реєструються у Системі управління тестуванням. Негативно пройдені тести, в яких фактичний результат відрізняється від очікуваного, реєструються як помилки та передаються команді розробників на доопрацювання з наступною перевіркою після виправлення.
Entry Criteria: Test Plan Document, Test Cases, Test Data, Test Environment;
Deliverables: Test case execution report, Defect report, RTM.
Завершення циклу випробувань (Test Cycle Closure): остаточне створення звітів про тестування для клієнта. Вони повинні включати витрачений час, відсоток виявлених помилок та позитивних результатів тестування, загальну кількість виявлених та виправлених помилок. Що стосується відділу тестування, то це момент для аналізу його роботи, підбиття підсумків, аналізу його продуктивності та можливості внести пропозиції щодо покращення якості тестування.
Entry Criteria: Test Case Execution report (переконайтеся, що немає відкритих high severity defects), Defect report;
Deliverables: Test Closure report, Test metrics.
Різниця STLC та SDLC
STLC і SDLC тісно пов'язані один з одним, але вони одночасно переслідують різні завдання з однією і тією самою метою, а саме:
збір вимог у бажаній формі та розробка заявленої функціональності (SDLC);
аналіз вимог, допомога клієнту та команді розробників та підтвердження якості реалізованої функціональності (STLC).
Загальна мета – задоволення клієнта та отримання максимально можливого балу на етапах верифікації та валідації.
Чому тестування розбите на окремі етапи?
Відповідь з ISTQB Foundation Level Exam: Кожен етап має свою мету.
У більшості випадків тестування розбивається на кілька етапів залежно від розвитку самого коду та прагнення ефективного використання ресурсів. Давайте розглянемо приклад програми, яка включає як служби REST, так і веб-інтерфейс, в agile команді, яка надає набір user stories, які в кінцевому підсумку будуть розгорнуті як виробничий випуск.
Якщо команда слідує Acceptance Test Driven Development (ATDD), то члени команди спільно працюватимуть над дизайном тестів історій. Це відбувається на початок розробки (одна з характеристик ATDD). Допустимо, Мері - розробник, який напише код для служб REST, і припустимо, що вона практикує розробку через тестування (TDD). Вона будує модульні тести, по одному спочатку дозволяючи тесту не пройти, а потім пише достатньо коду для проходження тесту. Коли є достатньо тестів для задоволення всіх вимог до історії і ці тести проходять, тоді розробка і модульне тестування завершуються. Потім Мері може написати автоматизовані тести, які включають базу даних та, можливо, інші залежності поза її кодом. Це інтеграційні випробування. Оскільки команда використовує ATDD, вона вже має набір приймальних тестів, тому вона започатковує свої автоматизовані тести на них. Коли код Мері перевіряється та об'єднується у спільну галузь розробки, у процесі складання виконуються автоматичні регресійні тести, щоб переконатися, що існуючі функціональні можливості не були порушені роботою Мері. Ці тести часто є просто набір автоматичних приймальних випробувань, що проводяться протягом місяців або років.
Якщо Сем є розробником інтерфейсу користувача, можливо, він також пише модульні тести для деяких частин свого коду. Коли його робота буде завершена, він може також написати автоматизовані інтеграційні тести, хоча в його тестах можуть бути відсутні сценарії даних, оскільки вони охоплюються тестами Мері, і він більше зосередиться на використанні самого інтерфейсу користувача. Це все ще автоматизовані приймальні тести, але ціль полягає в тому, щоб уникнути зайвої надмірності існуючих тестових прикладів. Як і у випадку з кодом Мері, коли код Сема перевіряється і об'єднується в загальну гілку, автоматично виконується набір регресії інтерфейсу користувача.
Після того, як Сем і Мері закінчать, Джо, QA-інженер, може провести деяке ручне приймальне тестування всієї історії, а також деяке дослідницьке тестування, щоб переконатися, що божевільна поведінка користувача не призводить до божевільної поведінки програми. Ця комбінація автоматичних та ручних тестів складає приймальне тестування історії. По завершенні низки історій набір змін впроваджується в інтегроване середовище для остаточного тестування. Це може бути приймальне тестування вищого рівня, а також додаткове регресійне тестування. Додаткове приймальне тестування може виконуватися інженерами із забезпечення якості, які стежать за тим, щоб набір історій забезпечував узгоджений робочий процес для користувачів і, зрештою,
Заключне регресійне тестування проводиться поверх раніше запущеного пакета автоматизованої регресії. Можливо, ця програма має деякі функції, які просто вимагають людського втручання, або, можливо, це остаточна оцінка іншої групи тестувальників, які стежать за дотриманням стилю та стандартів поведінки.
Як видно з цього робочого процесу, багато з цих кроків було б неефективно виконати раніше, ніж вони описані вище. Автоматичні тести є винятком, оскільки вони можуть часто виконуватися багаторазово протягом усього процесу. Проте більшість інших «етапів» тестування - це природний розвиток, заснований на розвитку випуску.
Джерела:
Дод. матеріал: