Keywords acceptance testing, black-box testing, component integration testing, component testing, confirmation testing, functional testing, integration testing, maintenance testing, non-functional testing, regression testing, shift-left, system integration testing, system testing, test level, test object, test type, white-box testing

2.1. Тестування в контексті життєвого циклу розробки програмного забезпечення.

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

Деякі дії в рамках процесів розробки програмного забезпечення також можна описати більш детальними методами розробки програмного забезпечення та методами Agile. Приклади включають: розробку, керовану приймальним тестуванням (ATDD), розробку, керовану поведінкою (BDD), дизайн, керований доменом (DDD), екстремальне програмування (XP), розробку, керовану функціями (FDD), Kanban, Lean IT, Scrum та тестова розробка (TDD).

2.1.1. Вплив життєвого циклу розробки програмного забезпечення на тестування

Тестування має бути адаптовано до SDLC, щоб досягти успіху. Вибір SDLC впливає на:

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

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

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

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

2.1.2. Життєвий цикл розробки програмного забезпечення та належна практика тестування.

Належна практика тестування, незалежно від обраної моделі SDLC, включає наступне:

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

2.1.3. Тестування як драйвер для розробки програмного забезпечення

TDD, ATDD і BDD є схожими підходами до розробки, де тести визначаються як засіб керування розробкою. Кожен із цих підходів реалізує принцип раннього тестування (див. розділ 1.3) і дотримується підходу зсуву вліво (див. розділ 2.1.5), оскільки тести визначаються до написання коду. Вони підтримують ітераційну модель розробки.

Ці підходи характеризуються наступним чином:

1. Розробка, керована тестуванням (TDD):

• Направляє кодування через тестові випадки (замість обширного проектування програмного забезпечення) (Бек 2003)
• Спочатку пишуться тести, потім пишеться код, щоб задовольнити тести, і тоді тести та код рефакторингуються.

2. Acceptance Test-Driven Development (ATDD) (див. розділ 4.5.3):

• Виводить тести з критеріїв прийнятності як частину процесу проектування системи (Gärtner 2011)
• Тести пишуться перед частиною програми розроблено, щоб задовольнити тести

Розробка, орієнтована на поведінку (BDD):

• Виражає бажану поведінку програми за допомогою тестових випадків, написаних простою формою природної мови, яку легко зрозуміти зацікавленим сторонам – зазвичай за допомогою Given/When/Then формат. (Chelimsky 2010)
• Тестові приклади потім автоматично перетворюються на виконувані тести. Для всіх вищевказаних підходів тести можуть зберігатися як автоматизовані тести, щоб гарантувати якість коду в майбутніх адаптаціях / рефакторингу.

2.1.4. DevOps і тестування

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

З точки зору тестування, деякі переваги DevOps:

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

DevOps не позбавлений ризиків і викликів, які включають:

• Конвеєр доставки DevOps має бути визначений і налагоджено
• Необхідно запровадити та підтримувати інструменти CI/CD
• Автоматизація тестування потребує додаткових ресурсів, і її може бути важко встановити та підтримувати Хоча DevOps забезпечує високий рівень автоматизованого тестування, ручне тестування – особливо з точки зору користувача – все одно буде необхідним.

2.1.5. Підхід Shift-Left

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

Існує кілька хороших практик, які ілюструють, як досягти «зсуву вліво» у тестуванні, зокрема:

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

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

2.1.6. Ретроспективи та вдосконалення процесів

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

• Що було успішним і що слід зберегти?
• Що не вдалось і можна було б покращити?
• Як запровадити вдосконалення та зберегти успіхи в майбутньому?

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

Типові переваги для тестування:

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

2.2. Рівні та типи тестів

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

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

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

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

У цьому навчальному плані описано наступні п’ять рівнів тестування:

1. Тестування компонентів (також відоме як модульне тестування) фокусується на тестуванні компонентів окремо. Для цього часто потрібна спеціальна підтримка, наприклад тестові пакети або фреймворки модульного тестування. Тестування компонентів зазвичай виконується розробниками у своїх середовищах розробки.
2. Інтеграційне тестування компонентів (також відоме як модульне інтеграційне тестування) фокусується на тестуванні інтерфейсів і взаємодії між компонентами. Тестування інтеграції компонентів значною мірою залежить від підходів стратегії інтеграції, таких як «знизу вгору», «зверху вниз» або «великий вибух».
3. Тестування системи зосереджується на загальній поведінці та можливостях усієї системи або продукту, часто включаючи функціональне тестування наскрізних завдань і нефункціональне тестування характеристик якості. Для деяких нефункціональних характеристик якості бажано тестувати їх на повній системі в репрезентативному тестовому середовищі (наприклад, зручність використання). Використання симуляції субсистем також можливо. Тестування системи може виконуватися незалежною групою тестувальників і пов’язане зі специфікаціями системи.
4. Тестування системної інтеграції зосереджується на тестуванні інтерфейсів тестованої системи та інших систем і зовнішніх служб. Тестування системної інтеграції вимагає відповідних тестових середовищ, бажано подібних до робочого середовища.
5. Приймальне тестування зосереджено на перевірці та демонстрації готовності до розгортання, що означає, що система відповідає бізнес-потребам користувача. В ідеалі приймальне тестування має виконуватися запланованими користувачами. Основними формами приймального тестування є: приймальне тестування користувача (UAT), операційне приймальне тестування, договірне та нормативне приймальне тестування, альфа-тестування та бета-тестування.

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

• Об’єкт тестування
• Цілі тестування
• Основа тестування
• Дефекти та невдачі
• Підхід і відповідальність

2.2.2. Типи тестів

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

1. Функціональне тестування оцінює функції, які повинен виконувати компонент або система. Функції – це «те, що» повинен робити тестовий об’єкт. Основною метою функціонального тестування є перевірка функціональної повноти, функціональної правильності та функціональної відповідності.
2. Нефункціональне тестування оцінює атрибути, відмінні від функціональних характеристик компонента або системи. Нефункціональне тестування — це перевірка того, «наскільки добре поводиться система». Основною метою нефункціонального тестування є перевірка якісних характеристик нефункціонального програмного забезпечення.

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

1. Ефективність продуктивності
2. Сумісність
3. Зручність
4. Надійність
5. Безпека
6. Ремонтопридатність
7. Портативність

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

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

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

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

2.2.3. Підтверджувальне тестування та регресійне тестування

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

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

• виконанням усіх тестових випадків, які раніше були невдалими через дефект, або також шляхом
• додавання нових тестів для покриття будь-яких змін, необхідних для виправлення дефекту.

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

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

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

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

2.3. Тестування технічного обслуговування

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

Обсяг тестування технічного обслуговування зазвичай залежить від:

• ступеня ризику зміни
• розміру існуючої системи
• розміру зміни

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

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