Що таке Agile Testing?
AGILE TESTING - це практика тестування, яка відповідає правилам та принципам гнучкої розробки програмного забезпечення. На відміну від методу Waterfall, Agile Testing може розпочатись на початку проекту з постійною інтеграцією між розробкою та тестуванням. Методика тестування Agile не є послідовною (у тому сенсі, що вона виконується лише після фази кодування), а безперервною.
У цій статті ми обговоримо
- Спритний план тесту.
- Швидкі стратегії тестування.
- Спритний тестовий квадрант.
- Випробування забезпечення якості завдяки гнучкій розробці програмного забезпечення.
- Ризик автоматизації в гнучкому процесі.
Спритний план тесту
План гнучкого тестування включає типи тестування, проведених за цією ітерацією, такі як вимоги до даних тесту, інфраструктура, середовища тестування та результати тестування. На відміну від моделі водоспаду, у гнучкій моделі для кожного випуску пишеться та оновлюється план випробувань. Типові плани випробувань у гнучкій програмі включають
- Сфера тестування
- Нові функціональні можливості, які перевіряються
- Рівень або типи тестування на основі складності особливостей
- Тестування навантаження та продуктивності
- Розгляд інфраструктури
- План пом'якшення наслідків або ризиків
- Ресурси
- Результати та етапи
Швидкі стратегії тестування
Життєвий цикл гнучкого тестування охоплює чотири етапи
(а) Ітерація 0
На першому етапі або ітерації 0 ви виконуєте початкові завдання налаштування. Він включає визначення людей для тестування, встановлення інструментів тестування, планування ресурсів (лабораторія тестування юзабіліті) тощо. Наступні кроки встановлені для досягнення в Iteration 0
а) Встановлення бізнес-обґрунтування проекту
b) Встановити граничні умови та обсяг проекту
в) Окресліть ключові вимоги та випадки використання, які сприятимуть компромісам у проектуванні
г) Окресліть одну або кілька архітектур-кандидатів
д) виявлення ризику
f) Оцінка витрат та підготовка попереднього проекту
(b) Будівельні ітерації
Другий етап гнучкої методології тестування - будівельні ітерації, більшість тестувань відбувається на цьому етапі. Ця фаза спостерігається як набір ітерацій для побудови приросту розчину. Для цього в рамках кожної ітерації команда впроваджує гібрид практик з XP, Scrum, Agile моделювання та гнучких даних тощо.
Під час ітерації конструкції спритна команда дотримується пріоритетної практики вимог: З кожною ітерацією вони беруть найважливіші вимоги, що залишаються у стеку робочих предметів, і реалізують їх.
Ітерація конструкції класифікується на дві - підтверджуюче тестування та слідче тестування. Підтверджуюче тестування зосереджується на перевірці, чи система відповідає намірам зацікавлених сторін, як описано на сьогоднішній день командою, та проводиться командою. Хоча слідче тестування виявляє проблему, яку команда підтвердження пропустила або проігнорувала. Під час слідчого тестування тестер визначає потенційні проблеми у вигляді дефектів. Слідче тестування стосується таких загальних питань, як інтеграційне тестування, навантаження / стрес-тестування та тестування безпеки.
Знову ж таки, для підтверджуючого тестування є два аспекти тестування розробником та спритного тестування прийняття . Обидва вони автоматизовані, щоб забезпечити безперервне тестування регресії протягом усього життєвого циклу. Підтверджуюче тестування - це швидкий еквівалент тестування до специфікації.
Agile-тестування приймання - це поєднання традиційного функціонального тестування та традиційного тестування приймання як команда розробників, і зацікавлені сторони роблять це разом. Хоча тестування розробників - це поєднання традиційного модульного тестування та традиційного тестування інтеграції послуг. Тестування розробником перевіряє як код програми, так і схему бази даних.
(c) Кінець гри або фаза переходу
Метою “Release, End Game” є успішне впровадження вашої системи у виробництво. На цьому етапі передбачається навчання кінцевих споживачів, служб підтримки та оперативних людей. Крім того, він включає маркетинг випуску продукту, резервне копіювання та відновлення, доопрацювання системної та користувацької документації.
Заключний етап тестування гнучких методологій включає повне тестування системи та прийняття. Щоб завершити остаточний етап тестування без будь-яких перешкод, вам доведеться ретельніше тестувати продукт, поки він перебуває у будівельних ітераціях. Під час кінцевої гри тестувальники працюватимуть над її дефектами.
(г) Виробництво
Після етапу випуску продукт переходить на стадію виробництва.
Швидкі квадранти тестування
Швидкі квадранти тестування розділяють весь процес на чотири квадранти і допомагають зрозуміти, як проводиться гнучке тестування.
а) Agile Quadrant I - Внутрішня якість коду є основним акцентом у цьому квадранті, і він складається з тестових кейсів, які базуються на технологіях та реалізовані для підтримки команди, він включає
1. Одиничні тести
2.Компонентні тести
b) Agile Quadrant II - Він містить тестові кейси, які керуються бізнесом і реалізовані для підтримки команди. Цей квадрант зосереджений на вимогах. Вигляд тесту, проведений на цьому етапі, є
1. Тестування прикладів можливих сценаріїв та робочих процесів
2. Тестування досвіду користувача, наприклад прототипів
3. Тестування пар
в) Agile Quadrant III - Цей квадрант забезпечує зворотний зв'язок для квадрантів один і два. Тестові кейси можуть бути використані як основа для тестування автоматизації. У цьому квадранті проводиться багато раундів огляду ітерацій, що формує впевненість у продукті. Тестування, проведене в цьому квадранті, є
1. Тестування юзабіліті
2. Пошукове тестування
3. Тестування пар із клієнтами
4. Спільне тестування
5. Тестування прийняття користувача
d) Agile Quadrant IV - Цей квадрант концентрується на нефункціональних вимогах, таких як продуктивність, безпека, стабільність тощо. За допомогою цього квадранту додаток подається для надання нефункціональних якостей та очікуваної вартості.
1. Нефункціональні тести, такі як стрес-тести та показники ефективності
2. Тестування безпеки щодо автентифікації та злому
3. Тестування інфраструктури
4. Тестування міграції даних
5. Тестування масштабованості
6. Тестування навантаження
Випробування забезпечення якості завдяки гнучкій розробці програмного забезпечення
а) Швидше помилки швидкіші, оскільки документації надається менший пріоритет, з часом більший тиск на команду з контролю якості
б) Нові функції вводяться швидко, що скорочує доступний час для тестових груп, щоб визначити, чи відповідають найновіші функції вимогам, і чи справді вони відповідають діловим костюмам
в) Від тестерів часто вимагається грати в напіврозвитку
г) Цикли виконання тестів сильно стискаються
д) Дуже менше часу на підготовку плану тестування
f) Для регресійного тестування вони матимуть мінімальні терміни
g) Зміна їхньої ролі від воротаря якості до стану партнера у галузі якості
h) Зміни та оновлення вимог притаманні гнучкому методу, що стає найбільшим викликом для забезпечення якості
Ризик автоматизації в гнучкому процесі
- Автоматизований інтерфейс забезпечує високий рівень довіри, але він повільний у виконанні, крихкий в обслуговуванні та дорогий у побудові. Автоматизація може суттєво не підвищити продуктивність тесту, якщо тестувальники не знають, як тестувати
- Ненадійні тести є основною проблемою автоматизованого тестування. Виправлення невдалих тестів та вирішення проблем, пов’язаних із крихкими тестами, має бути головним пріоритетом, щоб уникнути помилкових спрацьовувань
- Якщо автоматичне тестування ініціюється вручну, а не через CI (Безперервна інтеграція), тоді існує ризик того, що вони не регулярно запускаються, а тому можуть призвести до невдалих тестів
- Автоматизовані тести не є заміною дослідницькому ручному тестуванню. Щоб отримати очікувану якість продукту, необхідна суміш типів та рівнів випробувань
- Багато комерційно доступних засобів автоматизації надають такі прості функції, як автоматизація збору та відтворення ручних тестів. Такий інструмент заохочує тестування за допомогою інтерфейсу користувача та призводить до нестабільних і важких в обслуговуванні тестів. Крім того, зберігання тестових кейсів поза системою контролю версій створює непотрібну складність
- З метою економії часу багато разів план тестування автоматизації погано планується або не планується, що призводить до тестування
- Процедури налаштування та руйнування тесту зазвичай пропускаються під час автоматизації тестування, тоді як при ручному тестуванні процедури тестування та руйнування звучать без проблем
- Такі показники продуктивності, як кількість тестових випадків, що створюються або виконуються на день, можуть страшенно ввести в оману і можуть призвести до великих інвестицій у проведення марних тестів
- Члени спритної команди автоматизації повинні бути ефективними консультантами: доступними, кооперативними та винахідливими, інакше ця система швидко вийде з ладу
- Автоматизація може запропонувати та запропонувати рішення для тестування, які вимагають занадто багато постійного технічного обслуговування відносно наданої вартості
- Автоматизоване тестування може не мати достатніх знань для розробки та надання ефективних рішень
- Автоматизоване тестування може бути настільки успішним, що у них закінчуються важливі проблеми, які потрібно вирішити, і, отже, перетворюються на незначні проблеми.
Висновок
Швидка методологія тестування програмного забезпечення передбачає тестування якомога раніше у життєвому циклі розробки програмного забезпечення. Це вимагає великої участі замовника та тестування коду, як тільки він стає доступним. Код повинен бути достатньо стабільним, щоб взяти його на тестування системи. Широке регресійне тестування можна зробити, щоб переконатися, що помилки виправлені та протестовані. Головним чином, спілкування між командами робить успішним тестування гнучкої моделі !!!