Что такое тестирование рабочих процессов при тестировании программного обеспечения? с примерами

⚡ Умное резюме

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

🔄 Определение: Рабочий процесс — это последовательность задач, которые на нескольких этапах приводят к достижению одного желаемого результата.
🏢 Согласование бизнеса: Каждая тестируемая последовательность должна соответствовать процессу, описанному в документе с бизнес-требованиями.
🧩 Объем: Анализ покрытия включает в себя как интеграционные, так и системные тесты для каждой сборки.
📅 Четыре фазы: На этапах зарождения, разработки, построения и перехода к следующему этапу тестирование имеет свой особый акцент.
👥 Роли: В работе участвуют инженеры по тестированию, инженеры по компонентам, специалисты по интеграционному тестированию и системные тестировщики.
🆚 Границы: Сквозное тестирование охватывает все системы, в то время как тестирование рабочих процессов следует одному бизнес-процессу.
🇧🇷 Практика: Расставьте приоритеты для потоков, критически важных для получения дохода, используйте реалистичные данные и проводите повторное тестирование при каждом изменении процесса.

Читать

Что такое тестирование рабочего процесса?

Тестирование рабочих процессов Тестирование программного обеспечения — это тип тестирования, который проверяет, насколько точно каждый рабочий процесс программного обеспечения отражает заданный бизнес-процесс. Рабочий процесс — это последовательность задач, которые приводят к желаемому результату, и обычно он включает в себя несколько этапов или шагов. Для любого бизнес-процесса тестирование этих последовательных шагов определяется как тестирование рабочего процесса.

Главное отличие — это масштаб. Единичный прецедент Тестирование рабочих процессов проверяет, возвращает ли одна функция правильный ответ. Тестирование рабочих процессов проверяет, обеспечивают ли десять таких функций, выполняемых в том порядке, в котором их выполняет реальный пользователь, результат, ожидаемый бизнесом. По этой причине тестирование рабочих процессов относится к процессно-ориентированным разделам. виды тестирования ПО каталог, а не с использованием методов на уровне отдельных единиц.

Пример тестирования рабочего процесса

Например, убедитесь, что система может быть установлена на платформе пользователя и что она корректно работает.

Более наглядный пример — онлайн-заказ. Клиент добавляет товар в корзину, применяет код скидки, выбирает способ доставки, оплачивает заказ и получает электронное письмо с подтверждением, а склад получает инструкцию по комплектации. Каждый из этих шагов может пройти успешно в отрыве от контекста, но при этом завершиться неудачей в цепочке: скидка может не сохраниться на этапе оплаты, или сообщение от склада может так и не покинуть очередь.

Тестирование рабочих процессов проводится поэтапно. Вот как вы будете проводить тестирование рабочих процессов.

Начальный этапЭтот этап включает в себя первоначальное планирование испытаний и тестирование прототипа.
Этап разработкиНа этом этапе определяется базовая архитектура тестирования.
Фаза строительстваЭтот этап включает в себя тщательное тестирование на каждом этапе сборки.
Фаза переходаЭта фаза включает в себя: регрессионные тесты и повторно протестировать исправления.

Как проводить тестирование рабочих процессов

Представленная выше модель фаз описывает, когда именно выполняется работа. Приведенная ниже последовательность описывает, что фактически делает тестировщик в рамках любой из этих фаз.

Составьте карту бизнес-процесса. Составьте точную схему рабочего процесса, как он работает в компании, включая все точки принятия решений, утверждения и передачу информации между отделами. Как правило, бизнес-аналитик — это самый быстрый способ получить точную схему, и... бизнес-аналитик Документация служит эталоном, по которому проверяется карта.
Установите критерии входа и выхода. Зафиксируйте состояние, в котором система должна находиться до начала рабочего процесса, и состояние, подтверждающее его завершение. Без обоих показателей тестировщики могут не согласиться с тем, был ли запуск успешно пройден.
Разработайте тестовые примеры. Для каждого этапа рабочего процесса необходимо написать отдельный сценарий, а не по одному на каждый экран. Пронумеруйте шаги, укажите ожидаемый результат для каждого из них и присвойте каждому сценарию уникальный идентификатор, чтобы можно было выявлять и устранять дефекты. tracвернуться на тропу.
Подготовьте реалистичные тестовые данные. Используйте анонимизированные, созданные на основе производственных данных записи, а не вымышленные значения. Коды скидок, налоговые правила и форматы адресов — это типичные места, где синтетические данные скрывают реальные недостатки.
Сначала запустите основной путь. Прежде чем что-либо намеренно нарушать, убедитесь, что рабочий процесс завершен от начала до конца. Сбой на этом этапе аннулирует все последующие негативные результаты.
Намеренно разорвать цепь. Отмена на полпути, отправка недопустимого значения в точке принятия решения, истечение времени сессии и отказ в утверждении. Интересные дефекты находятся именно в этих прерванных путях, а не в основном.
Сообщите о проблеме, исправьте и протестируйте заново. Зарегистрируйте каждый дефект, указав этап, который его вызвал, а затем повторно запустите весь рабочий процесс после исправления. Исправленный этап часто сдвигает ошибку на одну ступень дальше по цепочке.

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

Кто будет проводить тестирование рабочего процесса?

Тестирование рабочих процессов — это работа, выполняемая несколькими сотрудниками, поскольку ни один сотрудник не видит всю цепочку целиком. Нагрузку несут четыре сотрудника, каждый со своими обязанностями.

Инженер-испытатель
- Планируйте цели и график тестирования
- Определить тестовые случаи и процедуры
- Оцените результаты теста
Инженер по компонентам
- Разработка тестовых компонентов
- Автоматизируйте некоторые процедуры тестирования.
Интеграционный тестер
- Выполнение интеграционные тесты и сообщение о дефектах
Системный тестировщик
- Выполнение системные тесты и сообщение о дефектах

Что тестировать в рабочем процессе

Процессы разработки программного обеспечения документируются в документе с бизнес-требованиями, и этот документ является источником достоверной информации о покрытии кода. Тестирование процессов разработки также включает в себя части системного и интеграционного тестирования.

При полной проверке рабочего процесса анализируется не только то, что видит пользователь.

Последовательность: Шаги выполняются в указанной последовательности, и их нельзя пропустить или повторить не по порядку.
Передача данных: Значения, введенные на ранних этапах цепочки, сохраняются в неизменном виде до последнего шага и в любой последующей системе.
Роли и права доступа: Каждый этап доступен только той роли, которая уполномочена его выполнять.
Прерванные пути: Отмена, истечение времени ожидания, отклонение и повторная попытка — все эти действия оставляют рабочий процесс в заданном состоянии.
Артефакты: Модель тестирования рабочего процесса охватывает тестовые примеры, тестовые процедуры, тестовые компоненты и тестовые подсистемы, поэтому каждый из них проверяется по очереди.
Уведомления: Электронные письма, оповещения и сообщения в очереди отправляются один раз, с правильным содержимым, на правильном этапе.

Тестирование рабочих процессов против сквозного тестирования против системного тестирования

Эти три метода достаточно сильно пересекаются, чтобы вызывать путаницу, но при этом отвечают на разные вопросы. В таблице определены границы.

Аспект	Тестирование рабочих процессов	Сквозное тестирование	Тестирование системы
Ответ на вопрос	Соответствует ли программное обеспечение бизнес-процессу?	Работает ли весь процесс во всех подключенных системах?	Соответствует ли собранная система заявленным требованиям?
Единица покрытия	Один бизнес-процесс, шаг за шагом	Единый пользовательский опыт, от фронтенда до бэкенда.	Полная сборка приложения
Первичная ссылка	Документ бизнес-требований	Карта пути пользователя	Спецификация системных требований
Типичный владелец	Инженер-тестировщик с участием бизнес-аналитика	Инженер по автоматизации или инженер по контролю качества.	Системный тестировщик

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

лучшие практики и общие проблемы

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

Приоритет следует отдавать рабочим процессам, несущим финансовые или регуляторные риски, прежде чем переходить к редким.
Опишите каждый шаг и ожидаемый результат простым и недвусмысленным языком.
Используйте многократно применяемый, реалистичный набор тестовых данных, чтобы результаты выполнения тестов оставались сопоставимыми в разных средах.
Протестируйте каждый рабочий процесс с допустимыми и недопустимыми входными данными на каждом этапе принятия решения.
Обновляйте тестовые примеры в тот момент, когда изменяется базовый бизнес-процесс.

Повторяющиеся препятствия столь же предсказуемы.

Недокументированные процессы: Рабочий процесс существует в головах людей, поэтому тестировщики проверяют его, опираясь на предположение.
Длительное время выполнения: Процесс согласования может занимать несколько часов, что ограничивает частоту его ручного запуска.
Дрейф окружающей среды: В последующих звеньях производственной цепочки возникают сбои или устаревание, и дефекты проявляются только в процессе производства.
Хрупкая автоматизация: Скрипты, привязанные к расположению элементов на экране, перестают работать при каждом изменении интерфейса, даже если сам процесс не изменился.
Коллизии данных: Параллельные запуски обрабатывают одни и те же записи, что приводит к ошибкам, которые выглядят как дефекты продукта.

Часто задаваемые вопросы (FAQ)

Это функциональный метод. Он оценивает, приводит ли последовательность к желаемому результату, а не скорость или надежность этого результата — эти вопросы относятся к производительности. тестирование восстановления.

Модели ИИ анализируют документ с требованиями и предлагают по одному варианту развития событий для каждого пути, включая прерванные ветви, о которых команды обычно забывают. Результаты все еще нуждаются в проверке, поскольку модель не может определить, какие пути несут реальные бизнес-риски.

Copilot и аналогичные агентские помощники быстро создают объекты страниц, определения шагов и утверждения на основе написанного рабочего процесса. Они экономят время и силы.ping Вместо того чтобы думать: последовательность выполнения, тестовые данные и определение успешного запуска остаются ответственностью тестировщика.

Сначала документ с бизнес-требованиями, затем схема процесса и любая матрица утверждения. TracОдной лишь пользовательской истории недостаточно, поскольку история редко описывает всю последовательность шагов.

После того, как сборка интегрирована и стабильна, ошибки указывают на сам процесс, а не на неполные соединения компонентов. Запуск таких проверок на ранних этапах приводит к появлению шума; запуск их только в конце не оставляет времени для исправления обнаруженных проблем.

Затронутые случаи переписываются перед следующим запуском, а не удаляются. Изменение этапа утверждения или новой точки принятия решения обычно затрагивает несколько последующих случаев, поэтому весь процесс повторяется заново, а не исправляется в одном месте.

Сопоставление пройденных путей с задокументированными, обнаруженных дефектов по каждому рабочему процессу и доли критически важных для бизнеса процессов с автоматизированным запуском. Количество тестовых случаев само по себе мало что говорит, поскольку один рабочий процесс может содержать десятки тривиальных случаев.

Тестирование потоков Тестирование рабочих процессов следует единой функциональной нити через интегрированные компоненты, поэтому оно является их техническим аналогом. Тестирование рабочих процессов формулирует ту же идею в бизнес-терминах. tracиспользование документированного процесса вместо последовательности выполнения кода.