- STLC
1.Аналіз вимог (Requirement Analysis): один із найважливіших етапів, тому що саме на ньому можна майже безкоштовно виправити недоліки проекту. Етап аналізу вимог також визначає потенційну потребу в автоматизованому тестуванні та дозволяє проводити економічні розрахунки витрат на робочу силу на основі оцінки проекту. На цьому ж етапі обговорюються та документуються критерії початку та закінчення тестування.
Entry Criteria: BRS (Business Requirement Specification)
Deliverables: список всіх вимог, що перевіряються, техніко-економічне обґрунтування автоматизації (якщо застосовно);
2. Планування тестування (Test Planning): цьому етапі формується план тестування, тобто. ми визначаємо дії та ресурси, які допоможуть досягти цілей тестування (учасники та їх ролі, інструменти, оточення). Під час планування ми також намагаємося визначити метрики, метод збирання та відстеження цих метрик. План складають виходячи з вимог, тестової стратегії та аналізу ризиків.
Entry Criteria: Requirements Documents;
Відповідні: Test Strategy, Test Plan, і Test Effort estimation document.
3. Розробка тест-кейсів (Test Case Development): передбачає використання ручного та автоматизованого тестування для досягнення повного охоплення функціональності програмного забезпечення, при цьому процес базується на заздалегідь встановлених вимогах. Найчастіше тест-кейси для автоматичного тестування пишуться окремо, оскільки кейси для ручного тестування описані як шпаргалок (cheat sheets).
Entry Criteria: Requirements Documents (Updated version);
Deliverables: Test cases, Test Scripts (if automation), Test data.
4. Налаштування тестового середовища (Test Environment Setup): у плані тестування чітко вказано, яке тестове середовище слід використовувати. На цьому етапі STLC налаштовуються операційні системи та віртуальні машини, розгортаються інструменти тестування, такі як Selenium, Katalon Studio, а також тестове середовище та бази даних проекту. Ми також звертаємося з запитами до DevOps та адміністраторів, якщо потрібна підтримка.
Entry Criteria: Test Plan, Smoke Test cases, Test Data;
Deliverables: Test Environment. Smoke Test Results.
5. Виконання тестів (Test Execution): тести виконуються на основі готової тестової документації та правильно налаштованого тестового середовища. Усі результати тестування реєструються у Системі управління тестуванням. Негативно пройдені тести, в яких фактичний результат відрізняється від очікуваного, реєструються як помилки та передаються команді розробників на доопрацювання з наступною перевіркою після виправлення.
Entry Criteria: Test Plan Document, Test Cases, Test Data, Test Environment;
Deliverables: Test case execution report, Defect report, RTM.
6. Завершення циклу випробувань (Test Cycle Closure): остаточне створення звітів про тестування для клієнта. Вони повинні включати витрачений час, відсоток виявлених помилок та позитивних результатів тестування, загальну кількість виявлених та виправлених помилок. Що стосується відділу тестування, то це момент для аналізу його роботи, підбиття підсумків, аналізу його продуктивності та можливості внести пропозиції щодо покращення якості тестування.
Entry Criteria: Test Case Execution report (переконайтеся, що немає відкритих high severity defects), Defect report;
Deliverables: Test Closure report, Test metrics.
- SDLC
SDLC (Software development lifecycle) – це процес, який використовується індустрією програмного забезпечення для проектування, розробки і тестування високоякісного програмного забезпечення.
SDLC націлений на виробництво ПЗ, яке відповідає очікуванням клієнтів або перевершує їх, в найкоротші терміни завершує роботу і оцінює витрати.
Цей процес складається з шести основних фаз.
Фази SDLC
1. Планування системи
Фаза планування – найбільш важливий і критичний крок у створенні успішної системи. На цьому етапі:
- точно вирішується що саме потрібно зробити, розробити, які проблеми вирішити, які потреби закрити;
- визначаються проблеми, цілі і ресурси (таких, як персонал і витрати);
- вивчаються можливості альтернативних рішень шляхом зустрічей з клієнтами, постачальниками, консультантами та співробітниками;
- вивчається, як зробити продукт краще, ніж у конкурентів.
Після аналізу цих даних буде три варіанти: розробити нову систему, покращити існуючу або залишити систему як є.
На цьому етапі надзвичайно важлива комунікація з замовником.
2. Аналіз системи
Необхідно визначити і задокументувати вимоги кінцевого користувача системи – в чому його очікування і як їх здійснити.
Крім того, для проекту робиться техніко-економічне обґрунтування, яке з’ясовує, чи є проект організаційно, економічно, соціально, технологічно здійсненним.
Дуже важливо підтримувати хороший рівень комунікації з замовниками, щоб переконатися, що у вас є чітке бачення кінцевого продукту і його функцій.
Адже скільки людей, стільки й думок, важливо дійти до спільного знаменника.
3. Дизайн системи
Фаза дизайну настає після того, коли досягнуто хорошого розуміння вимог споживача і ви точно знаєте, що саме треба втілити.
Ця фаза визначає елементи системи, компоненти, рівень безпеки, модулі, архітектуру, різні інтерфейси і типи даних, якими оперує система. Дизайн системи в загальних рисах може бути зроблений ручкою на листку паперу – він визначає, як система буде виглядати і як функціонувати.
Потім робиться розширений, детальний дизайн, з урахуванням всіх функціональних і технічних вимог, як логічно, так і фізично.
4. Розробка, впровадження і розгортання
Ця фаза йде після повного розуміння системних вимог і специфікацій. Це і є власне процес розробки системи, коли її дизайн вже повністю завершено. В життєвому циклі розробки системи саме тут пишеться код, а також фаза впровадження може включати в себе конфігурацію і налаштування під певні вимоги і функції. На цій стадії система готова до установки у замовника, до запуску в робочий режим. Можливо, кінцевим користувачам буде потрібний тренінг, щоб вони освоїлися з системою і знали, як її використовувати.
Фаза впровадження може бути дуже довгою – це залежить від складності системи.
5. Дослідна експлуатація та інтеграція
Тут відбувається об’єднання різних компонентів і підсистем в єдину цілісну систему. В систему подаються різні вхідні дані і аналіз виходу, поведінки і функціонування.
Тестування стає все важливішим для задоволення споживача, при цьому воно не вимагає знань коду, конфігурації обладнання чи дизайну.
Тестування може виконуватися справжніми користувачами або спеціальною командою співробітників. Воно може бути систематичним і автоматизованим, з тим, щоб упевнитися, що актуальні результати роботи системи збігаються з передбаченими і бажаними
6. Підтримка системи
На цій фазі здійснюється періодична технічна підтримка системи, щоб переконатися, що вона не застаріла.
Сюди входить:
- заміна старого обладнання і постійна оцінка продуктивності
- здійснюються апдейти певних компонентів, щоб упевнитися, що система відповідає потрібним стандартам і новітнім технологіям, і не схильна до загроз безпеки.
Це шість основних стадій життєвого циклу розробки системи, і вони повторюються для кожного проекту.
- Bug life circle
4. Хороший чекліст – це документ, що описує те, що має бути протестовано. При цьому чекліст може бути абсолютно різного рівня деталізації. Наскільки детальним буде чекліст залежить від вимог до звітності, рівня знання продукту співробітниками та складності продукту.
Чекліст потрібен щоб:
- Не забути необхідні тести.
- Ділити завдання за рівнем кваліфікації.
- Зберігати звітність та результати тестування.
Чекліст містить:
- Список перевірок (з необхідним ступенем деталізації).
- Оточення перевірки:
– збірка, на якій проводилося тестування;
– тестове оточення (якщо є);
– інформація про тестувальників. - Результат перевірки.
Ще однією обов’язковою сутністю, з якою зустрічається кожен тестувальник, є Test Case (Тестовий випадок).
Test Case – це тестовий артефакт, суть якого полягає у виконанні деякої кількості дій та/або умов, необхідних для перевірки певної функціональності програмної системи, що розробляється.
Структура даного артефакту полягає в «трійці»:
Виконувана дія (Action) – Очікуваний результат (Expected result) – Фактичний результат (Test result).
Безпосередньо сам тестовий випадок складається з 3 частин:
- PreConditions (Передумови) – або список кроків, які приводять систему, що перевіряється, у стан, придатний для тестування, або список перевірок умов того, що система вже знаходитися в необхідному стані.
- Test Case Description (Опис тестового випадку) – список дій, за допомогою яких здійснюється основна перевірка функціоналу (після якої і порівнюється фактичний результат із очікуваним).
- PostConditions (Післяумови) – список дій, які повертають систему в початковий стан.
- Спосіб написання тест кейсів та їх структура може бути різна в кожній компанії або команді: мати різні глибини опису необхідних дій та результатів, мати різні структурні складові. Але, хороша структурованість та висока зручність шаблонів тестових випадків, може значно скоротити час рутинних заповнень форм та підвищити ефективність команди в цілому.
Тестова стратегія – набір основних принципів, які визначають розробку тестів та регулюють те, як буде здійснюватися процес тестування програмного забезпечення. Метою стратегії тестування є забезпечення системного підходу до процесу тестування з метою забезпечення якості, відстежування, надійності та кращого планування.
Різниця між тестовою стратегією і тест-планом
| Параметр | Тестова стратегія | Тест-план |
| Визначення | Тестова стратегія – це документ високого рівня, який містить вказівки та принципи, пов’язані з проведенням процесу тестування. | Тест-план – це документ, який охоплює обсяг та різні види діяльності, залучені в процес тестування. |
| Ціль | Головна ціль – визначити принципи, яких слід дотримуватися під час процесу тестування. | Основна мета тут полягає в тому, щоб визначити, як тестувати продукт, що тестувати, коли тестувати, хто тестуватиме і хто перевірятиме результати. |
| Мета | Це план дій процесу тестування на довгостроковій основі. | Створюється для того, щоб виявити можливі невідповідності в кінцевому продукті та пом’якшити їх через процес тестування. |
| Рівень | Використовується на організаційному рівні. | Використовується лише на рівні проєкту. |
| Повторюваність | Він використовується в багатьох проєктах і може повторюватися багато разів. | Він використовується лише одним проєктом і дуже рідко повторюється. |
| Можливість внесення змін | Це статичний документ. Зміни вносять дуже рідко. | Це динамічний документ, і його можна багаторазово змінювати залежно від специфікацій тестування. |
| Компоненти | Включає: цілі та обсяг, документацію, процеси тестування тощо. | Включає: ідентифікатор тест-плану, функції, які необхідно перевірити, методи, яких слід дотримуватися, завдання, критерії початку і закінчення тестування, розклади тощо. |
| Відповідальний | Менеджер проєкту. | Менеджер з тестування або керівник тестування (тест-лід). |
| Область застосування | Зосереджений лише на методах та стратегіях тестування високого рівня. | Детально визначає всю діяльність тестування. |
| Джерела | Є похідним від документа специфікації бізнес-вимог. | Створюють за допомогоюuse case, документів зі специфікацією вимог та документів з описом продукту. |
| Існування | У деяких випадках може бути частиною тест-плану. | Існує окремо. |
| Основа | Заснований на стандартах, які були заздалегідь визначені. | Заснований на стратегіях тестування. |
| Типи | Аналітична стратегія (Analytical strategy), стратегія на основі моделі (Model-based strategy), методична стратегія (Methodical strategy), стратегія, що відповідає стандартам (Standard-compliant strategy), реактивна стратегія (Reactive strategy), консультативна стратегія (Consultative strategy) та стратегія протидії регресії (Regression averse strategy). | Плани тестування для конкретного рівня (Level-specific test plans), плани тестування для конкретного типу (Type-specific test plans) та основні плани тестування (Master test plans). |
| Вплив | Впливає на багато проєктів одночасно. | Одночасно впливає лише на один проєкт. |
| Що описує | Описує підходи до тестування. | Описує загальні специфікації при тестуванні конкретного проєкту. |
Use Case (сценарій користування) – це перелік дій, сценарій, за яким користувач взаємодіє з додатком або програмою для виконання будь-якої дії та досягнення конкретної мети.
Тестування за юзкейсами проводиться для того, щоб виявити додаткові логічні прогалини та баги у web-додатку, які складно знайти під час тестування окремих індивідуальних модулів або частин цього web-додатку.
У більшості випадків Use Case описує, що робить система, а не як. Власне, цього правила і варто дотримуватися, створюючи такі сценарії.
За допомогою юзкейсів можна описувати взаємодію двох або більшої кількості учасників, що мають конкретну мету, наприклад:
- покупка товару у магазині (Покупець – Продавець);
- відправка листа електронною поштою (Адресант – Поштовий клієнт);
- запит сторінки браузером (Браузер – Web-сервер).
Для кого і чому необхідні Use Case?
Для замовників
Кожен юзкейс несе кінцеву бізнес-цінність, зрозумілу замовнику. То ж навіть технічно не підкована людина може переконатися у реалізації того чи іншого Use Case у системі. Наявність готового сценарію дає можливість замовнику своєчасно підтвердити старт подальшої роботи тестувальників та команди розробників.
Для розробників
Зручність полягає у розлогому описі основного й альтернативного потоку подій. Уся інформація зображена максимально структуровано та зрозуміло з урахуванням кінцевого результату. Use Case ідеально підходять у ситуаціях складних сценаріїв.
Для тестувальників
Це чудова база для формування тестових сценаріїв – test case. Юзкейси, за замовчуванням, є тестованими вимогами із зазначеною метою і шляхом її досягнення.Розглянемо на прикладі один з можливих Use Case при оформленні лікарняного співробітником через діалог з чат-ботом.
Тест кейси об’єднують у тест сьюти для більшої зручності при проходженні тест кейсів, проходячи їх послідовно від модуля до модуля, від одного типу тестування до іншого, а не сумбурно, кидаючись з одного кута в кут, залишивши не перевіреним більшу частину модуля або загальної функціональності.