Какво представлява тестването на работния процес в софтуерното тестване? с примери

Какво е тестване на работния процес?

Тестване на работния процес е вид софтуерно тестване, което проверява дали всеки софтуерен работен процес точно отразява дадения бизнес процес. Работният процес е поредица от задачи, които водят до желания резултат, и обикновено включва няколко етапа или стъпки. За всеки бизнес процес тестването на тези последователни стъпки се определя като тестване на работен процес.

Разграничението, което има значение, е обхватът. Един-единствен тестов случай пита дали една функция връща правилния отговор. Тестът на работния процес пита дали десет от тези функции, изпълнени в реда, в който ги следва реален потребител, все още дават резултата, който бизнесът очаква. Поради тази причина тестването на работния процес принадлежи към процесно-ориентираните записи в видове софтуерно тестване каталог, а не с техники на ниво единица.

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

Например, проверете дали системата може да бъде инсталирана на платформата на потребителя и дали работи правилно.

По-богат пример е онлайн поръчка. Клиентът добавя артикул в количката, прилага код за отстъпка, избира опция за доставка, плаща и получава имейл за потвърждение, докато складът получава инструкции за комплектоване. Всяка от тези стъпки може да премине изолирано и все пак да се провали като верига: отстъпката може да не оцелее след стъпката на плащане или съобщението от склада може никога да не напусне опашката.

Тестването на работния процес се извършва на фази. Ето как ще извършите тестване на работния процес.

• Начална фазаТази фаза включва първоначално планиране на тестовете и тестване на прототипи.
• Фаза на разработкаТази фаза включва базова линия на тестовата архитектура.
• Фаза на строителствоТази фаза включва значително тестване при всяка компилация.
• Фаза на преходТази фаза включва регресионни тестове и повторно тестване на корекциите.

Как да извършите тестване на работния процес

Фазовият модел по-горе описва кога се извършва работата. Последователността по-долу описва какво всъщност прави тестерът във всяка една от тези фази.

1. Картографирайте бизнес процеса. Начертайте работния процес точно както го управлява бизнесът, включително всяка точка на вземане на решения, одобрение и предаване на задачи между отделите. Бизнес анализаторът обикновено е най-бързият път към точна карта и... бизнес анализатор документацията е референтният документ, спрямо който се проверява картата.
2. Задайте критерии за влизане и излизане. Запишете състоянието, в което системата трябва да бъде преди стартиране на работния процес, и състоянието, което доказва, че е приключил. Без двете, тестерите нямат единодушие относно това дали изпълнението е преминало успешно.
3. Проектирайте тестовите случаи. Напишете по един случай за всеки път през работния процес, а не по един за всеки екран. Номерирайте стъпките, посочете очаквания резултат за всяка от тях и дайте на всеки случай уникален идентификатор, за да могат да се открият дефекти. tracвърна се обратно на пътеката.
4. Подгответе реалистични тестови данни. Използвайте повторно анонимизирани записи, оформени в производствена форма, вместо измислени стойности. Кодовете за отстъпка, данъчните правила и форматите на адресите са обичайните места, където синтетичните данни крият реални дефекти.
5. Първо изпълнете основния път. Уверете се, че работният процес завършва от край до край, преди нещо да бъде умишлено повредено. Неуспех тук обезсилва всеки последващ отрицателен резултат.
6. Прекъснете веригата нарочно. Отмяна по средата, подаване на невалидна стойност в точка на вземане на решение, спиране на сесията и отказване на одобрение. Интересните дефекти се намират в тези прекъснати пътища, а не в основния.
7. Докладвайте, поправете и тествайте отново. Регистрирайте всеки дефект спрямо стъпката, която го е причинила, след което изпълнете отново целия работен процес след поправката. Поправената стъпка често измества повредата с едно ниво по-надолу по веригата.

Стабилните работни процеси, които повтарят всяко издание, са най-силните кандидати за автоматизация, защото едни и същи подредени стъпки се изпълняват по един и същи начин всеки път и скриптът се изплаща в рамките на няколко цикъла.

Кой ще извършва тестване на работния процес?

Тестването на работния процес е споделена работа, защото никоя отделна роля не вижда цялата верига. Четири роли носят товара, всяка със свои собствени отговорности.

• Тест инженер
  • Планирайте тестови цели и график
  • Дефинирайте тестови случаи и процедури
  • Оценете резултатите от теста
• Инженер по компоненти
  • Разработване на тестови компоненти
  • Автоматизирайте някои от тестовите процедури
• Тестер за интеграция
  • Извършване на интеграционни тестове и докладване на дефекти
• Системен тестер
  • Извършване на системни тестове и докладване на дефекти

Какво да се тества в работен процес

Работните процеси на софтуера са документирани в Документа с бизнес изискванията и този документ е източникът на достоверна информация за покритието. Тестването на работните процеси ще включва и части от системните и интеграционните тестове.

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

• Последователност: Стъпките се изпълняват в документирания ред и не могат да бъдат пропускани или повтаряни извън реда си.
• Предаване на данни: Стойностите, въведени в началото на веригата, се запазват непокътнати до последната стъпка и за всяка следваща система.
• Роли и разрешения: Всяка стъпка е достъпна само за ролята, която е оторизирана да я изпълнява.
• Прекъснати пътища: Анулирането, изчакването, отхвърлянето и повторният опит оставят работния процес в определено състояние.
• Артефакти: Моделът на тестване на работния процес обхваща тестови случаи, тестови процедури, тестови компоненти и тестови подсистеми, така че всеки от тях се проверява на свой ред.
• Уведомително писмо: Имейлите, предупрежденията и съобщенията в опашката се задействат веднъж, с правилното съдържание, на правилната стъпка.

Тестване на работния процес срещу цялостно тестване срещу системно тестване

Тези три техники се припокриват достатъчно, за да бъдат объркани, но въпреки това отговарят на различни въпроси. Таблицата определя границите.

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

Най-добри практики и често срещани предизвикателства

Екипите, които получават стойност от тестването на работния процес, са склонни да следват един и същ малък набор от навици.

• Приоритизирайте работните процеси, които носят приходи или регулаторен риск, пред рядко срещаните.
• Опишете всяка стъпка и очаквания резултат на ясен и недвусмислен език.
• Поддържайте многократно използваем, реалистичен набор от тестови данни, така че изпълненията да останат сравними в различните среди.
• Тествайте всеки работен процес с валидни входни данни и с невалидни такива във всяка точка на вземане на решение.
• Актуализирайте тестовите случаи в момента, в който се промени основният бизнес процес.

Повтарящите се препятствия са също толкова предвидими.

• Недокументирани процеси: Работният процес се осъществява в главите на хората, така че тестерите го валидират срещу дадено предположение.
• Дълги срокове за изпълнение: Работен процес, обхващащ одобренията, може да отнеме часове, което ограничава честотата на ръчното му изпълнение.
• Дрейф на околната среда: Системите надолу по веригата са блокирани или застояли, а дефектите се появяват едва в производството.
• Крехка автоматизация: Скриптовете, свързани с оформлението на екрана, се прекъсват всеки път, когато интерфейсът се промени, дори когато процесът не се е променил.
• Колизии на данни: Паралелните изпълнения консумират едни и същи записи, което води до повреди, които изглеждат като продуктови дефекти.

Въпроси и Отговори