Гнучке тестування: методологія та життєвий цикл

Що таке Agile Testing?

Agile тестування – це практика тестування, яка дотримується правил і принципів гнучкої розробки програмного забезпечення. На відміну від методу «Касл», гнучке тестування починається на початку проекту та триває безперервно разом із розробкою. Воно не є послідовним — виконується лише після фази кодування — а вбудоване в кожну ітерацію, тому зворотний зв'язок досягає команди в момент появи дефектів.

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

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

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

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

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

Життєвий цикл гнучкого тестування складається з п'яти фаз, як показано нижче.

Фази такі:

• Фаза 1: Оцінка впливу. Зберіть інформацію від зацікавлених сторін та користувачів. Це також називається фазою зворотного зв'язку, оскільки це допомагає інженерам-тестувальникам ставити цілі на наступний життєвий цикл.
• Фаза 2: Планування гнучкого тестування. Усі зацікавлені сторони об'єднуються, щоб спланувати графік тестування, обсяг та результати.
• Фаза 3: Готовність до випуску. Revпереглянути реалізовані функції та вирішити, які з них готові до запуску, а які потрібно повернутися до розробки.
• Фаза 4: Щоденні скрами. Ранкова зустріч, під час якої команда обговорює стан тестування та ставить цілі на день.
• Фаза 5: Перевірте спритність Review. Щотижневі зустрічі із зацікавленими сторонами для оцінки прогресу у досягненні цілей та коригування стратегії.

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

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

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

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

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

Ітерація 0

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

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

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

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

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

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

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

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

Фаза випуску, завершення гри або перехід

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

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

Виробництво

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

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

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

Agile Quadrant I

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

• Модульні тести.
• Компонентні випробування.

Agile Quadrant II

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

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

Agile Quadrant III

Квадрант III забезпечує зворотний зв'язок для квадрантів I та II. Тестові випадки, наведені тут, часто формують основу для автоматизації, а багаторазові ітераційні перевірки зміцнюють довіру до продукту. Типова робота включає:

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

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

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

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

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

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

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

Ризик автоматизації в Agile-процесі

Автоматизація є важливою в Agile, але вона несе ризики, якими команди повинні активно керувати:

• Автоматизовані тести інтерфейсу користувача пропонують високу впевненість, але вони повільні, нестабільні та дорогі в обслуговуванні. Підвищення продуктивності спостерігається лише тоді, коли тестувальники знають, як розробляти хороші тести.
• Ненадійні тести викликають серйозну проблему. Виправлення ненадійних тестів та хибнопозитивних результатів має залишатися головним пріоритетом.
• Автоматизовані тести, що виконуються вручну, а не через неперервну інтеграцію (CI), ризикують непомітно зависнути та давати застарілі результати.
• Автоматизація не замінює дослідницьке ручне тестування. Для очікуваної якості необхідне поєднання типів та рівнів тестування.
• Інструменти захоплення та відтворення заохочують використання скриптів, керованих інтерфейсом користувача, які є крихкими та важкими для підтримки. Тести, що зберігаються поза системою контролю версій, додають зайвої складності.
• Погано спланована автоматизація, що здійснюється для «економії часу», часто повністю зазнає невдачі.
• Процедури налаштування та демонтажу тестів легко пропустити під час автоматизації, тоді як ручне тестування справляється з ними природним чином.
• Такі показники продуктивності, як «кількість тестових випадків на день», можуть ввести команди в оману та змусити їх проводити непотрібні тести.
• Команда з автоматизації повинна бути ефективними консультантами — доступними, схильними до співпраці та винахідливими — інакше практика зазнає невдачі.
• Рішення, що вимагають інтенсивного постійного обслуговування, можуть переважити цінність, яку вони забезпечують.
• Автоматизованим тестам може бракувати досвіду, необхідного для розробки ефективних рішень.
• Успішна автоматизація може призвести до того, що важливі проблеми для вирішення закінчаться, і робота перейде на менш цінну.

Найкращі практики для ефективного гнучкого тестування

Наступні практики забезпечують швидке, надійне та цінне для команди гнучке тестування:

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

Поширені запитання