Ce este testarea fluxului de lucru în testarea software-ului? cu Exemple

⚡ Rezumat inteligent

Testarea fluxului de lucru confirmă faptul că fiecare secvență de pași din cadrul unei aplicații reflectă în continuare procesul de business pentru care a fost construită, verificând fiecare etapă, predare și dependență de la prima acțiune până la rezultatul final.

  • 🔄 Definiție: Un flux de lucru este o serie de sarcini care produc un rezultat dorit în mai multe etape.
  • 🏢 Alinierea afacerii: Fiecare secvență testată trebuie să corespundă procesului descris în Documentul de Cerințe de Afaceri.
  • 🧩 Domeniu de aplicare: Acoperirea se bazează atât pe teste de integrare, cât și pe teste de sistem pentru fiecare versiune.
  • 📅 Patru faze: Inceperea, elaborarea, construcția și tranziția au fiecare un obiectiv diferit de testare.
  • 👥 roluri: Inginerii de testare, inginerii de componente, testerii de integrare și testerii de sistem își împart munca.
  • 🆚 Limite: Testarea end-to-end se întinde pe sisteme, în timp ce testarea fluxului de lucru urmează un singur proces de business.
  • 🛠️ Practică: Prioritizați fluxurile critice pentru venituri, utilizați date realiste și retestați ori de câte ori procesul se schimbă.

Testarea fluxului de lucru explicată cu pași, roluri și exemple ale procesului de business

Ce este testarea fluxului de lucru?

Testarea fluxului de lucru este un tip de testare software care verifică dacă fiecare flux de lucru software reflectă cu acuratețe procesul de business dat. Un flux de lucru este o serie de sarcini care produc un rezultat dorit și implică de obicei mai multe etape sau pași. Pentru orice proces de business, testarea acestor pași secvențiali este definită ca testare a fluxului de lucru.

Distincția care contează este domeniul de aplicare. O singură caz de testare întreabă dacă o funcție returnează răspunsul corect. Un test de flux de lucru întreabă dacă zece dintre aceste funcții, executate în ordinea în care un utilizator real le urmează, livrează în continuare rezultatul așteptat de companie. Din acest motiv, testarea fluxului de lucru aparține intrărilor orientate pe procese din tipuri de testare software catalog, mai degrabă decât cu tehnicile la nivel de unitate.

Exemplu de testare a fluxului de lucru

De exemplu, verificați dacă sistemul poate fi instalat pe platforma utilizatorului și dacă se execută corect.

Un exemplu mai complex este o comandă online. Clientul adaugă un articol în coș, aplică un cod de reducere, selectează o opțiune de livrare, plătește și primește un e-mail de confirmare, în timp ce depozitul primește o instrucțiune de ridicare a comenzilor. Fiecare dintre acești pași poate trece izolat și totuși să eșueze ca lanț: reducerea poate să nu supraviețuiască etapei de plată sau mesajul depozitului poate să nu părăsească niciodată coada.

Testarea fluxului de lucru se face în etape. Acesta este modul în care veți efectua testarea fluxului de lucru.

  • Faza de inițiereAceastă fază include planificarea testelor inițiale și testarea prototipului.
  • Faza de elaborareAceastă fază include stabilirea bazei arhitecturii de testare.
  • Faza de construcțieAceastă fază include teste semnificative la fiecare versiune.
  • Faza de tranzițieAceastă fază include teste de regresie și retestarea corecțiilor.

Cum se efectuează testarea fluxului de lucru

Modelul de faze de mai sus descrie momentul în care se desfășoară lucrarea. Secvența de mai jos descrie ce face de fapt un tester în oricare dintre aceste faze.

  1. Cartografiați procesul de afaceri. Desenați fluxul de lucru exact așa cum îl desfășoară afacerea, inclusiv fiecare punct de decizie, aprobare și transfer între departamente. Un analist de afaceri este de obicei cea mai rapidă cale către o hartă precisă, iar analist de afaceri Documentația este referința în raport cu care se verifică harta.
  2. Stabiliți criteriile de intrare și ieșire. Înregistrați starea în care trebuie să se afle sistemul înainte de începerea fluxului de lucru și starea care dovedește finalizarea acestuia. Fără ambele, testerii nu sunt de acord cu privire la succesul unei rulări.
  3. Proiectați cazurile de testare. Scrieți câte un caz pentru fiecare cale prin fluxul de lucru, nu unul pentru fiecare ecran. Numerotați pașii, precizați rezultatul așteptat pentru fiecare și dați fiecărui caz un identificator unic, astfel încât defectele să poată fi identificate. tracs-a întors pe o cărare.
  4. Pregătiți date de testare realiste. Reutilizați înregistrări anonimizate, modelate conform producției, în loc de valori inventate. Codurile de reducere, regulile fiscale și formatele de adresă sunt locurile obișnuite în care datele sintetice ascund defecte reale.
  5. Executați mai întâi calea principală. Confirmați că fluxul de lucru se completează complet înainte de a fi compromis în mod deliberat. O eroare în acest caz invalidează orice rezultat negativ care urmează.
  6. Rupe lanțul intenționat. Anulare la jumătatea drumului, trimitere a unei valori nevalide într-un punct de decizie, expirare a unei sesiuni și respingere a unei aprobări. Defectele interesante se află în aceste căi întrerupte, nu în cea principală.
  7. Raportează, corectează și retestează. Înregistrați fiecare defect în raport cu pasul care l-a produs, apoi reluați întregul flux de lucru după remediere. Un pas reparat deplasează frecvent defecțiunea cu o etapă mai jos în lanț.

Fluxurile de lucru stabile care repetă fiecare lansare sunt cei mai buni candidați pentru automatizare, deoarece aceiași pași ordonați se execută identic de fiecare dată, iar scriptul se amortizează în câteva cicluri.

Cine va efectua testarea fluxului de lucru?

Testarea fluxului de lucru este o muncă partajată, deoarece niciun rol nu vede întregul lanț. Patru roluri poartă sarcina, fiecare cu propriile responsabilități.

  • Inginer de testare
    • Planificați obiectivele testelor și programați
    • Definiți cazurile și procedurile de testare
    • Evaluați rezultatele testelor
  • Inginer componente
    • Dezvoltarea componentelor de testare
    • Automatizați unele dintre procedurile de testare
  • Tester de integrare
  • Tester de sistem

Ce să testezi într-un flux de lucru

Fluxurile de lucru software sunt documentate în Documentul de cerințe de afaceri, iar acest document este sursa de adevăr pentru acoperire. Testarea fluxului de lucru va implica, de asemenea, părți din testele de sistem și de integrare.

O trecere completă peste un flux de lucru examinează mai mult decât ecranele pe care le vede utilizatorul.

  • Secvenţă: Pașii se execută în ordinea documentată, iar pașii nu pot fi omiși sau repetați în mod neregulat.
  • Transfer de date: Valorile introduse devreme în lanț supraviețuiesc intacte până la ultima etapă și în orice sistem din aval.
  • Roluri și permisiuni: Fiecare pas este disponibil doar rolului autorizat să îl execute.
  • Căi întrerupte: Anularea, expirarea, respingerea și reîncercarea lasă fluxul de lucru într-o stare definită.
  • Artefacte: Modelul de testare a fluxului de lucru acoperă cazuri de testare, proceduri de testare, componente de testare și subsisteme de testare, astfel încât fiecare dintre acestea este verificat pe rând.
  • Notificări: E-mailurile, alertele și mesajele din coadă se declanșează o singură dată, cu conținutul corect, la pasul corect.

Testarea fluxului de lucru vs. testarea end-to-end vs. testarea sistemului

Aceste trei tehnici se suprapun suficient pentru a fi confundate, însă răspund la întrebări diferite. Tabelul stabilește limitele.

Aspect Testarea fluxului de lucru Testare de la capăt la capăt Testarea sistemului
Întrebare răspunsă Software-ul se potrivește cu procesul de afaceri? Întreaga călătorie funcționează în fiecare sistem conectat? Sistemul asamblat îndeplinește cerințele sale?
Unitate de acoperire Un proces de afaceri, pas cu pas O singură călătorie a utilizatorului, de la început până la sfârșit Construcția completă a aplicației
Referință principală Document de cerințe de afaceri Harta călătoriei utilizatorului Specificația cerințelor de sistem
Proprietar tipic Inginer de testare cu contribuții de analist de afaceri Inginer de automatizare sau QA Tester de sistem

În practică, un test al fluxului de lucru este adesea specificația unui test de la un capăt la altul este construit din, în timp ce testarea sistemului oferă versiunea stabilă pe care rulează fluxul de lucru.

Cele mai bune practici și provocări comune

Echipele care obțin valoare din testarea fluxului de lucru tind să urmeze același set restrâns de obiceiuri.

  • Prioritizați fluxurile de lucru care implică riscuri legate de venituri sau de reglementări înaintea celor rare.
  • Descrieți fiecare pas și rezultatul așteptat într-un limbaj simplu și lipsit de ambiguitate.
  • Păstrați un set de date de testare reutilizabil și realist, astfel încât execuțiile să rămână comparabile în diferite medii.
  • Testați fiecare flux de lucru cu intrări valide și cu intrări nevalide în fiecare punct de decizie.
  • Actualizați cazurile de testare în momentul în care procesul de business subiacent se modifică.

Obstacolele recurente sunt la fel de previzibile.

  • Procese nedocumentate: Fluxul de lucru se află în mintea oamenilor, așa că testerii validează în baza unei presupuneri.
  • Timpi lungi de execuție: Un flux de lucru care acoperă aprobări poate dura ore întregi, ceea ce limitează frecvența executării manuale.
  • Derivația mediului: Sistemele din aval din lanț sunt defecte sau învechite, iar defectele apar doar în producție.
  • Automatizare fragilă: Scripturile legate de aspectul ecranului se întrerup ori de câte ori interfața se schimbă, chiar și atunci când procesul nu s-a schimbat.
  • Coliziuni de date: Execuțiile paralele consumă aceleași înregistrări, producând erori care arată ca defecte de produs.

Întrebări frecvente

Este funcțională. Tehnica evaluează dacă secvența produce rezultatul de afaceri specificat, nu cât de repede sau cât de fiabil o face - aceste întrebări aparțin performanței și testarea de recuperare.

Modelele de inteligență artificială citesc documentul cu cerințe și propun câte un caz per cale, inclusiv ramificațiile întrerupte pe care echipele le uită de obicei. Rezultatele trebuie încă analizate, deoarece un model nu poate ști care căi prezintă un risc real pentru afaceri.

Copilot și asistenți agenți similari creează rapid obiecte de pagină, definiții de pași și afirmații dintr-un flux de lucru scris. Aceștia economisesc timp.ping în loc să gândească: secvențierea, datele de testare și definirea unei rulări reușite rămân responsabilitatea testerului.

Mai întâi Documentul privind cerințele de afaceri, apoi diagrama procesului și orice matrice de aprobare. TracAbordarea doar a unei povești de utilizator nu este suficientă, deoarece o poveste rareori descrie lanțul complet de pași.

După ce construcția este integrată și stabilă, erorile indică procesul, mai degrabă decât componentele pe jumătate conectate. Rularea lor mai devreme produce zgomot; rularea lor doar la sfârșit nu lasă timp pentru a remedia ceea ce găsesc.

Cazurile afectate sunt rescrise înainte de următoarea rulare, nu sunt retrase. O etapă de aprobare modificată sau un nou punct de decizie modifică de obicei mai multe cazuri din aval, astfel încât întreaga cale este refăcută, în loc să fie remediată într-un singur loc.

Căile parcurse în raport cu căile documentate, defectele găsite per flux de lucru și ponderea proceselor critice pentru afacere cu o rulare automatizată. Numărul brut al cazurilor de testare spune foarte puțin, deoarece un flux de lucru poate conține zeci de cazuri banale.

Testarea firelor de ață urmează un fir funcțional prin componentele integrate, deci este omologul tehnic. Testarea fluxului de lucru prezintă aceeași idee în termeni de afaceri, traccrearea unui proces documentat în loc de o cale de cod.

Rezumați această postare cu: