Що таке тестування робочого процесу в тестуванні програмного забезпечення? з прикладами
Томас Гамільтон
⚡ Розумний підсумок
Тестування робочого процесу підтверджує, що кожна послідовність кроків усередині програми все ще відображає бізнес-процес, для якого вона була створена, перевіряючи кожен етап, передачу та залежність від першої дії до кінцевого результату.
Що таке тестування робочого процесу?
Тестування робочого процесу – це тип тестування програмного забезпечення, який перевіряє, чи кожен робочий процес точно відображає заданий бізнес-процес. Робочий процес – це серія завдань, які призводять до бажаного результату, і зазвичай він включає кілька етапів або кроків. Для будь-якого бізнес-процесу тестування цих послідовних кроків визначається як тестування робочого процесу.
Різниця, яка має значення, полягає в масштабі. Єдиний тестовий випадок запитує, чи одна функція повертає правильну відповідь. Тест робочого процесу запитує, чи десять із цих функцій, виконаних у порядку, в якому їх виконує реальний користувач, все ще забезпечують результат, очікуваний бізнесом. З цієї причини тестування робочого процесу належить до процесно-орієнтованих записів у види тестування програмного забезпечення каталогу, а не за допомогою методів на рівні одиниць.
Приклад тестування робочого процесу
Наприклад, перевірте, чи можна встановити систему на платформі користувача, і чи вона працює коректно.
Більш насиченим прикладом є онлайн-замовлення. Клієнт додає товар до кошика, застосовує код знижки, вибирає варіант доставки, оплачує та отримує електронний лист із підтвердженням, поки склад отримує інструкції щодо комплектації. Кожен із цих кроків може проходити окремо та все одно завершуватися невдачею як ланцюг: знижка може не пережити крок оплати, або повідомлення зі складу може ніколи не покинути чергу.
Тестування робочого процесу виконується поетапно. Ось як ви будете виконувати тестування робочого процесу.
- Фаза початкуЦей етап включає початкове планування тестування та тестування прототипу.
- Етап розробкиЦей етап включає базову архітектуру тестування.
- Етап будівництваЦей етап включає значне тестування на кожній збірці.
- Перехідна фазаЦей етап включає регресійні тести та повторно протестуйте виправлення.
Як виконати тестування робочого процесу
Фазова модель, наведена вище, описує, коли відбувається робота. Послідовність нижче описує, що насправді робить тестер у будь-якій з цих фаз.
- Зобразіть бізнес-процес на карті. Намалюйте робочий процес точно так, як його веде бізнес, включаючи кожну точку прийняття рішень, затвердження та передачу між відділами. Бізнес-аналітик зазвичай є найшвидшим шляхом до точної карти, а бізнес-аналітик документація – це посилання, за яким перевіряється карта.
- Встановіть критерії входу та виходу. Запишіть стан, у якому система має бути перед початком робочого процесу, та стан, який підтверджує його завершення. Без обох станів тестувальники не погоджуються щодо успішності виконання.
- Розробіть тестові випадки. Запишіть один випадок для кожного шляху робочого процесу, а не один для кожного екрана. Пронумеруйте кроки, вкажіть очікуваний результат для кожного та надайте кожному випадку унікальний ідентифікатор, щоб можна було виявити дефекти. tracповернувся на стежку.
- Підготуйте реалістичні тестові дані. Повторно використовуйте анонімізовані записи, що відповідають виробничій структурі, а не вигадані значення. Коди знижок, податкові правила та формати адрес – це звичайні місця, де синтетичні дані приховують реальні недоліки.
- Спочатку запустіть основний шлях. Переконайтеся, що робочий процес завершено від початку до кінця, перш ніж щось буде навмисно порушено. Збій тут анулює всі наступні негативні результати.
- Розірвати ланцюг навмисно. Скасувати на півдорозі, надіслати недійсне значення в момент прийняття рішення, зупинити сеанс і відхилити затвердження. Цікаві дефекти знаходяться в цих перерваних шляхах, а не в основному.
- Звіт, виправлення та повторне тестування. Зареєструйте кожен дефект відповідно до кроку, який його спричинив, а потім повторіть весь робочий процес після виправлення. Виправлений крок часто зміщує несправність на один етап далі по ланцюжку.
Стабільні робочі процеси, які повторюються після кожного випуску, є найкращими кандидатами для автоматизації, оскільки одні й ті ж упорядковані кроки виконуються однаково кожного разу, а скрипт окупається протягом кількох циклів.
Хто виконуватиме тестування робочого процесу?
Тестування робочого процесу – це спільна робота, оскільки жодна окрема роль не бачить усього ланцюжка. Чотири ролі несуть навантаження, кожна зі своїми обов'язками.
- Інженер-випробувач
- Сплануйте цілі тесту та розклад
- Визначте тестові випадки та процедури
- Оцініть результати тестування
- Інженер по компонентам
- Розробка тестових компонентів
- Автоматизуйте деякі тестові процедури
- Тестер інтеграції
- Виконання інтеграційні тести та повідомлення про дефекти
- Системний тестер
- Виконання системні тести та повідомлення про дефекти
Що тестувати в робочому процесі
Робочі процеси програмного забезпечення задокументовані в Документі бізнес-вимог, і цей документ є джерелом достовірної інформації для охоплення. Тестування робочих процесів також включатиме частини системних та інтеграційних тестів.
Повний огляд робочого процесу охоплює не лише екрани, які бачить користувач.
- Послідовність: Кроки виконуються в задокументованому порядку, і їх не можна пропускати або повторювати поза чергою.
- Передача даних: Значення, введені на початку ланцюжка, залишаються незмінними до останнього кроку та для будь-якої наступної системи.
- Ролі та дозволи: Кожен крок доступний лише для ролі, уповноваженої на його виконання.
- Перервані шляхи: Скасування, тайм-аут, відхилення та повторна спроба залишають робочий процес у визначеному стані.
- Артефакти: Модель тестування робочого процесу охоплює тестові випадки, тестові процедури, тестові компоненти та тестові підсистеми, тому кожен з них перевіряється по черзі.
- Сповіщення: Електронні листи, сповіщення та повідомлення черги запускаються один раз, з правильним вмістом, на правильному кроці.
Тестування робочого процесу проти наскрізного тестування проти системного тестування
Ці три методи достатньо перетинаються, щоб їх можна було сплутати, проте вони відповідають на різні питання. Таблиця встановлює межі.
| Аспект | Тестування робочого процесу | Наскрізне тестування | Тестування системи |
| Відповідь на запитання | Чи відповідає програмне забезпечення бізнес-процесам? | Чи працює весь процес у кожній підключеній системі? | Чи відповідає зібрана система вимогам? |
| Одиниця покриття | Один бізнес-процес, крок за кроком | Шлях одного користувача, від фронтенду до бекенду | Повна збірка програми |
| Основне посилання | Документ бізнес-вимог | Карта шляху користувача | Специфікація системних вимог |
| Типовий власник | Інженер-тестувальник з участю бізнес-аналітика | Інженер з автоматизації або контролю якості | Системний тестер |
На практиці тест робочого процесу часто є специфікацією наскрізне тестування побудовано з, тоді як тестування системи забезпечує стабільну збірку, на якій працює робочий процес.
Найкращі практики та поширені проблеми
Команди, які отримують цінність від тестування робочих процесів, як правило, дотримуються одного й того ж невеликого набору звичок.
- Надайте пріоритет робочим процесам, які несуть дохід або регуляторний ризик, перед рідкісними.
- Опишіть кожен крок та очікуваний результат простою та недвозначною мовою.
- Зберігайте реалістичний набір тестових даних для повторного використання, щоб результати тестування залишалися порівнянними в різних середовищах.
- Тестуйте кожен робочий процес з дійсними та недійсними вхідними даними на кожному етапі прийняття рішення.
- Оновлюйте тестові випадки щойно змінюється базовий бізнес-процес.
Повторювані перешкоди так само передбачувані.
- Недокументовані процеси: Робочий процес існує в головах людей, тому тестувальники перевіряють його на відповідність припущенням.
- Тривалий час виконання: Робочий процес, що охоплює затвердження, може тривати годинами, що обмежує частоту його виконання вручну.
- Дрейф навколишнього середовища: Системи нижче за течією в ланцюжку застопорилися або застаріли, а дефекти проявляються лише у виробництві.
- Крихка автоматизація: Скрипти, пов'язані з макетом екрана, перериваються щоразу, коли змінюється інтерфейс, навіть якщо сам процес цього не відбувається.
- Колізії даних: Паралельні запуски використовують ті самі записи, створюючи збої, які виглядають як дефекти продукту.
