Що таке Agile Testing? Процес і життєвий цикл

Що таке Agile Testing?

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

Принципи гнучкого тестування

Ось основні принципи гнучкого тестування:

  • У цій моделі гнучкого тестування робоче програмне забезпечення є основним показником прогресу.
  • Найкращого результату можуть досягти самоорганізовані команди.
  • Постачання цінного програмного забезпечення завчасно та постійно є нашим найвищим пріоритетом.
  • Розробники програмного забезпечення повинні діяти, щоб збиратися щодня протягом усього проекту.
  • Підвищення маневреності шляхом постійного технічного вдосконалення та гарного дизайну.
  • Agile Testing гарантує, що кінцевий продукт відповідає очікуванням бізнесу, надаючи постійний зворотний зв’язок.
  • У процесі Agile Test нам потрібно виконати процес тестування під час реалізації, що скорочує час розробки.
  • Процес тестування в Agile повинен працювати в постійному темпі розробки
  • Регулярно міркуйте над тим, як стати ефективнішим.
  • Найкращі архітектури, вимоги та проекти виходять із самоорганізованих команд.
  • Кожного разу, коли команда збирається, вона переглядає та коригує свою поведінку, щоб стати більш ефективною.
  • Особиста розмова з командою розробників є найефективнішим і дієвим методом передачі інформації всередині команди.

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

Життєвий цикл гнучкого тестування

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

Життєвий цикл гнучкого тестування

Ось етапи тестування процесу Agile:

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

Фаза 2: планування гнучкого тестування: Це друга фаза життєвого циклу Agile-тестування, де всі зацікавлені сторони збираються разом, щоб спланувати графік процесу тестування та результати.

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

Фаза 4: Щоденні Scrums: Цей етап включає кожну ранкову зустріч, щоб наздогнати статус тестування та поставити мету на весь день.

Фаза 5: Перевірте спритність Revось: Останнім етапом життєвого циклу Agile є Agile RevЗустріч iew. Це передбачає щотижневі зустрічі із зацікавленими сторонами для регулярного оцінювання прогресу щодо поставлених цілей.

Гнучкий план тестування

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

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

Гнучкі стратегії тестування

Життєвий цикл гнучкого тестування складається з чотирьох етапів

Гнучкі стратегії тестування

Ітерація 0

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

  • Створення бізнес-кейсу для проекту
  • Встановіть граничні умови та обсяг проекту
  • Окресліть ключові вимоги та варіанти використання, які керуватимуть компромісами при проектуванні
  • Окресліть одну або кілька архітектур-кандидатів
  • Виявлення ризику
  • Оцінка вартості та підготовка ескізного проекту

Ітерації будівництва

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

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

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

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

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

Випуск Кінцева гра або Фаза переходу

Мета «Випуск, завершення гри» — успішно розгорнути вашу систему у виробництві. Діяльність на цьому етапі включає навчання кінцевих користувачів, людей підтримки та оперативних працівників. Крім того, це включає маркетинг випуску продукту, резервне копіювання та відновлення, доопрацювання системної та користувацької документації.

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

Production

Після етапу випуску продукт переходить на етап виробництва.

Квадранти гнучкого тестування

Квадранти гнучкого тестування

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

Agile Quadrant I

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

  • Одиничні тести
  • Тести компонентів

Agile Quadrant II

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

  • Тестування прикладів можливих сценаріїв і робочих процесів
  • Тестування досвіду користувача, наприклад прототипів
  • Парне тестування

Agile Quadrant III

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

  • Тестування на зручність
  • Дослідницьке випробування
  • Тестування пар з клієнтами
  • Спільне тестування
  • Прийнятне тестування користувача

Гнучкий квадрант IV

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

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

Проблеми забезпечення якості з гнучкою розробкою програмного забезпечення

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

Ризик автоматизації в гнучкому процесі

  • Автоматизований інтерфейс користувача забезпечує високий рівень впевненості, але він повільний у виконанні, крихкий у підтримці та дорогий у створенні. Автоматизація може не значно підвищити продуктивність тестування, якщо тестувальники не знають, як тестувати
  • Ненадійні тести є основною проблемою в автоматизованому тестуванні. Виправлення невдалих тестів і вирішення проблем, пов’язаних із крихкими тестами, мають бути головним пріоритетом, щоб уникнути помилкових спрацьовувань
  • Якщо автоматичні тести запускаються вручну, а не через CI (безперервну інтеграцію), існує ризик, що вони не виконуються регулярно, і тому можуть спричинити невдачу тестів
  • Автоматичні тести не є заміною дослідницького ручного тестування. Щоб отримати очікувану якість продукту, необхідна суміш типів і рівнів тестування
  • Багато комерційно доступних інструментів автоматизації надають прості функції, такі як автоматизація захоплення та повторного відтворення тестових випадків вручну. Такий інструмент заохочує тестування через користувальницький інтерфейс і призводить до внутрішньо крихких тестів, які важко підтримувати. Крім того, зберігання тестових випадків поза системою контролю версій створює непотрібну складність
  • Щоб заощадити час, часто план тестування автоматизації погано спланований або незапланований, що призводить до невдачі тесту
  • Процедури налаштування та демонтажу тесту зазвичай пропускаються під час автоматизації тестування, тоді як виконання ручного тестування, процедури налаштування та демонтаж тесту звучать бездоганно
  • Такі показники продуктивності, як кількість тестів, створених або виконаних на день, можуть вводити в оману та призвести до великих інвестицій у виконання марних тестів.
  • Члени команди гнучкої автоматизації повинні бути ефективними консультантами: доступними, готовими до співпраці та винахідливими, інакше ця система швидко вийде з ладу
  • Автоматизація може запропонувати та надати рішення для тестування, які вимагають занадто багато поточного обслуговування порівняно з наданою вартістю
  • Автоматизованому тестуванню може не вистачити досвіду, щоб задумати та надати ефективні рішення
  • Автоматизоване тестування може бути настільки успішним, що в них закінчаться важливі проблеми для вирішення, і, таким чином, вони перейдуть до неважливих проблем.

Висновок

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