7 sfaturi de scriere a cazurilor de testare pentru a îmbunătăți procesul de testare a software-ului ERP

cazurile de testare sunt foarte importante pentru asigurarea calității în procesul de testare a software-ului ERP. Acestea sunt primii pași într-un ciclu de testare și dacă cazurile de testare nu sunt de o calitate suficientă, atunci întregul proiect va fi împovărat. Scrierea cazurilor de testare “grozave” este o abilitate care se formează pur și simplu făcând-o. Dar este foarte util să aveți câteva informații care vă pot ajuta. Cu acest articol vreau să ajung la tine și să dau sugestii pentru a face mai ușor, mai distractiv și mai bine. Sfaturile care vor fi date se vor referi în special la cazurile de testare la testarea acceptării sistemelor ERP.

ce sunt cazurile de testare?

în lumea testării software, există o mulțime de definiții ale cazurilor de testare. Din acest motiv, este important să numim definiția noastră. În filosofia noastră, cazurile de testare sunt (bazate pe IEEE610): “un set de intrări de testare, condiții de execuție și rezultate așteptate dezvoltate pentru un anumit obiectiv.”Să știi să scrii cazuri bune de testare este extrem de util pentru oricine dorește să testeze. Fie că este vorba despre un test funcțional, un test de acceptare a utilizatorului, testarea unei aplicații web sau a unui modul al unui sistem ERP. În toate situațiile descrise mai sus, cazurile de testare determină în ce măsură rezultatele dau un verdict asupra țintelor prestabilite.

de ce este scris cazuri de testare atât de greu?

așa cum este descris în definiție, cazurile de testare ajută testerii să treacă printr-o secvență de instrucțiuni de testare pentru a determina dacă software-ul îndeplinește sau nu cerințele predefinite. Executarea cazurilor de testare ne ajută să adunăm și să descoperim informații pentru a realiza acel obiectiv sau țintă specifică. Prima problemă cu care ne confruntăm în mod direct este diversitatea posibilelor ținte. Și pentru că există diferite tipuri de teste și obiective, există diferite tipuri de cazuri de testare corespunzătoare.

o a doua problemă este legată de conținutul instrucțiunii sau pașilor de testare reali. Nivelul acestor instrucțiuni depinde de tipul de tester care trebuie să interpreteze aceste informații și să dea un aviz. Un tester profesionist va avea nevoie de instrucțiuni diferite, spre deosebire de un utilizator final care este implicat în testarea de acceptare a unui sistem ERP

Sfat 1: Determinați obiectivul dvs. și ce doriți să raportați

gândiți-vă la ceea ce doriți să raportați, astfel încât să puteți determina obiectivul derivat. Folosind asta ca bază, aveți în vedere conturul cazului de testare. Există multe obiective diferite, în care trebuie întotdeauna să ne întrebăm ce încercăm să învățăm sau să realizăm atunci când vom rula testul. Iată câteva exemple:

• găsirea defectelor: acesta este scopul clasic al testării. Se efectuează un test pentru a expune defectele.
• Maximizați numărul de bug-uri: Distincția dintre “Maximizați numărul de bug-uri” și “găsirea defectelor” este că numărul total de bug-uri este mai important decât acoperirea.
• blocați lansările premature ale produsului: scopul acestui test este de a găsi prematur cât mai multe defecte severe (showstoppers), astfel încât nimeni să nu ia produsul în producție.
• sprijinirea managerilor cu deciziile lor go/no-go: managerii iau decizii bazate pe riscuri. Indicații de risc ca acoperire de testare, impactul problemelor constatate etc. Oferiți-le un fundal mai bun pe care să-și bazeze deciziile.
• evaluează conformitatea conform specificațiilor: specificațiile presupuse sunt verificate pentru funcționarea lor. Toate aspectele care nu sunt asociate cu specificațiile sunt ignorate.
• evaluați calitatea: acesta este un obiectiv dificil, deoarece calitatea este multidimensională. Natura calității depinde de natura produsului. Pentru a evalua calitatea ar trebui elaborate criterii clare, care sunt definite astfel încât să poată fi efectiv măsurabile.

rezultatele testelor derivate din cazurile de testare oferă informații relevante directe despre obiectiv.

Sfat 2: rezervați suficient timp de proiectare

rezervați suficient timp pentru a vă proiecta cazurile de testare, astfel încât să se potrivească obiectivelor dvs. Cazurile slabe de testare vă vor bântui pe tot parcursul procesului de testare. Compararea rezultatelor testelor, raportarea pe mai multe runde de testare etc. Sunt determinate în esență de calitatea cazurilor dvs. de testare.

dacă deja nu mai aveți timp să proiectați, dar totuși doriți să începeți testarea, asigurați-vă că ați definit cel puțin principalele riscuri. Dacă 10 testeri trebuie să revizuiască 5 cazuri de testare cu 1 pas de testare, Acest lucru va duce la 50 de rezultate ale testului. Indiferent de ceea ce aceste 50 rezultate oferă mai multe informații despre calitate, atunci nu face nimic. Probabil că acest lucru nu va fi exhaustiv, dar este un prim pas. De aici, se poate determina nivelul de detaliu al anumitor părți.

preferăm să vă gândiți bine în avans la modul în care ar trebui proiectat testul și ca rezultatele testului să ofere un răspuns real obiectivului. Dar, în realitate, acest lucru este uneori indisciplinat.

Sfat 3: denumirea cazului de testare

denumirea cazurilor de testare este importantă. Într-un test ERP Mediu aveți cu ușurință mai mult de 500 de cazuri de testare. Veți înțelege că o structură de nume logică îmbunătățește findability. În literatura de specialitate este adesea menționată ca un nume complet posibil, în care procesul de testat, modulul, obiectul etc. Toate sunt incluse în nume. Vă puteți imagina că furnizarea a 500 de cazuri de testare cu un titlu atât de complet oferă o administrare haotică. Cu o foaie Excel simplu, vă pierde cu ușurință privire de ansamblu. Instrumentele de gestionare a testelor oferă o structură la care puteți raporta cazurile de testare la obiecte reutilizabile, fără ca acestea să “polueze” numele. De asemenea, aveți instrumente de înregistrare a testelor care organizează aceste relații într-un mod diferit.

în cadrul TestMonitor de exemplu, am inventat o soluție diferită. În instrument puteți defini etichete sau etichete pe care apoi le puteți lega pentru a testa cazurile. În cadrul TestMonitor, cazurile de testare sunt legate de una sau mai multe etichete de proces de afaceri, risc, cerință sau aplicație. Acest lucru permite ca cazurile de testare să fie grupate și preluate din perspective diferite.

pentru denumirea unui caz de testare în cadrul TestMonitor este suficientă o descriere clară a scopului cazului de testare. Pentru a face simplu descrie o activitate cu o așteptare implicită.

exemplu test nume de caz:
“încetarea de leasing – independent de origine”
“crea client” “rezervare provizorie primire”
etc.

exemplu de caz de testare “chitanță provizorie de rezervare” care este legată de mai multe etichete:

• procesul de afaceri ‘primirea bunurilor’
• cerință ‘cerință Contract’
• risc ‘risc operațional’
• cerere ‘ERP’

este important să descrieți rezultatul așteptat pentru fiecare caz de testare. Testerul știe apoi în ce direcție trebuie să fie “răspunsul” și primește direct un cadru de testare explicit.

Sfat 4: descrierea etapei de testare

așa cum este descris în definiția test cazurile sunt o colecție de instrucțiuni de testare care ne ajută să descoperim informații pentru a atinge un anumit obiectiv.

un caz de testare trebuie să aibă un început și un sfârșit clar pentru a determina dacă cazul de testare a trecut sau a eșuat. În plus, un caz de testare este compus din una sau mai multe instrucțiuni de testare sau-pași, în care există mai multe căi posibile pentru a obține rezultatul dorit. Doar testarea căii succesului este adesea insuficientă. În anumite situații, urmărirea căilor de non-succes poate face diferența.

este important să definiți pașii de testare cât mai clar posibil, astfel încât utilizatorul final pentru un test de acceptare a utilizatorului să știe exact ce trebuie să facă. Desigur, există condiții prealabile pentru a veni, cum ar fi testerul de nivel funcțional, cunoașterea noului sistem, cunoașterea posibilelor procese de afaceri ajustate etc. Dar, în esență, toată lumea ar trebui să înțeleagă toți pașii de testare.

să presupunem că vom descrie în continuare cazul de testare “Rezilierea Contractului de leasing – acasă independent” pentru o cale de succes simplu:

1. Selectați o unitate și începe rezilierea contractului de leasing. Controlați dacă există condiții prealabile printre care rezilierea contractului de închiriere poate/nu poate fi acceptată și creați o înregistrare a acestui lucru.
2. programați o programare pentru inspecția finală.
3. completați datele din încetarea ecran de leasing. Verificați de două ori datele chiriașului din cardul de reziliere a contractului de închiriere.
4. înregistrați rezilierea contractului de închiriere și trimiteți o scrisoare conformațională. Verificați dacă scrisoarea de confirmare a venit în arhiva digitală.
5. verificați în registrul contractelor de la unitate că contractul actual este reziliat, că contractul reziliat este legat de rezilierea contractului de închiriere și că există un nou creat un contract de post vacant.
6. verificați noul contract (post vacant)pe baza politicii de închiriere și a șabloanelor de elemente.

ce observi?

• fiecare etapă de testare începe cu un verb
• urmat de un subiect
• încheind cu întrebări detaliate și eventual de control. S-ar putea să alegeți să puneți întrebările de control în pași de testare separați, dar practica arată că întrebarea de control este o rafinare a acțiunii și apoi, logic, va fi scrisă ca o etapă de testare.

în exemplul menționat mai sus, se presupune că un specialist dintr-un anumit domeniu va evalua etapa de testare. Și pentru că el sau ea este un specialist, nu sunt date condiții de intrare sau așteptări explicite, deoarece specialistul are încă propriile studii de caz în mânecă și așteptările sale sunt clare.

dacă nu aveți în prezent un specialist, puteți extinde pașii de testare cu condiții de intrare și așteptări explicite.

de exemplu, etapa de testare 1 la cazul de testare “încetarea de leasing – independent de origine”, cu mai multe detalii.

1. selectați unitatea “Fleet street 677” și începeți încetarea contractului de închiriere. Condițiile asigură că această unitate nu poate fi reziliată înainte de plata arieratelor.
2. etc.

Sfat 5: Nu mai mult de 10 Instrucțiuni de testare în 1 caz de testare

întâlnim în mod regulat proiecte de testare în care > 50 pas de testare sunt atribuite unui caz de testare. Acest lucru este prea mult pentru câteva motive:

• toate etapele de testare trebuie luate separat (sau transmise în mod explicit) înainte ca un caz de testare să primească un verdict.
• evaluarea finală a unui caz de testare este determinată de scorul “cel mai rău”. Deci, este posibil ca 49 de pași de testare să fie evaluați ca “buni “și unul ca” greșit “ceea ce duce la un caz de testare” greșit”. Măsurarea etapelor de încercare este similară. Prin aceasta vreau să spun că practic fiecare etapă de testare trebuie să fie egală cu efectul evaluării. Dacă aveți 10 pași de testare pe care trebuie să îi urmați, inclusiv 2 pași mici de testare care sunt disproporționați față de ceilalți 8 pași de testare, trebuie să îi reformulați. Același lucru este valabil și invers, cu un pas de testare dur.
• testerul se pierde rapid cu prea mulți pași de testare într-un caz de testare. Nu am făcut un studiu științific despre asta, dar practica arată că un caz de testare nu ar trebui să includă mai mult de 10 pași de testare. Se poate gândi la multe excepții (controale de conversie etc.), dar în practică pentru un test de acceptare a utilizatorului unui sistem ERP, acest lucru funcționează cel mai bine.
• este dificil pentru dezvoltatori să reproducă eroarea găsită. Cu mulți pași de testare dezvoltatorul va pierde o mulțime de timp încercând să re-adopte situația.
• reluările sau retestarea cazurilor mari de testare durează prea mult timp. Când o defecțiune este detectată de un tester, cazul de testare corespunzător va trebui retestat. O retestare necesită ca foarte pas va fi reevaluat, pe care doriți pentru a preveni erorile de regresie, evident. Luând prea mulți pași de testare, cel mai probabil testați prea mult. În acest fel, procesul de testare durează mai mult și în cele din urmă vă poate supraîncărca testerii.

pe lângă faptul că aveți, de asemenea, instrumente de înregistrare de testare, care pot prezenta cazurile de testare în diferite forme la tester. TestMonitor, de exemplu, are două vedere diferită. TestMonitor are un afișaj care arată toate etapele de testare separat pe pagină și un afișaj în care cazurile de testare sunt prezentate pe pagină, inclusiv toate etapele de testare.Avantajul primului afișaj este că fiecare tester poate obține mai multe informații pentru fiecare etapă de testare. Dezavantajul în cazul în care testerul este mai experimentat, el trebuie să facă clic pe “Următorul” de fiecare dată când dorește să treacă la următorul pas de testare. În cealaltă vedere pentru fiecare caz de testare, avantajele și dezavantajele sunt invers.

Sfat 6: revizuirea de către un non-designer/furnizor

în practică, vedem în mod regulat scripturi de testare pregătite de programatorii furnizorului de software. Când examinați aceste scripturi de testare de către eventualii testeri, există de obicei mai multe întrebări decât răspunsuri. În schimb, acest lucru funcționează la fel pentru scripturile de testare pregătite de propriul angajat. Acesta oferă o valoare adăugată reală revizuirea acestora de către furnizorul de software. Ei privesc scripturile de testare completate cu ochi diferiți și vin întotdeauna cu adăugiri sau modificări semnificative.

cu un pic de brainstorming cu specialiștii furnizorului de software și organizația clientului, vă concentrați rapid asupra esenței a ceea ce trebuie testat. Apoi, ia timp să ia în considerare cazurile de testare, scenarii non-succes și veți vedea că modelul de testare este rapid devine mai extinsă și detaliată. În afară de asta, veți obține mai multe informații despre calitatea pe care ați considerat-o posibilă.

Sfat 7: TestMonitor

pe lângă faptul că face uz de o platformă de testare profesionale și de a face de calitate într-adevăr eficiente. Solicitați o încercare gratuită a TestMonitor astăzi și vedeți și experimentați diferența pentru dvs.

dacă sunteți un nou venit în lumea testării, deveniți cu ușurință copleșiți de toată terminologia de testare aruncată în jur. În acest articol, vom încerca să explicăm o parte din jargonul pe care l-ați putea întâlni în viața dvs. de testare zilnică, doar pentru a face totul puțin mai ușor de înțeles.

începeți testarea cu TestMonitor

nu este un utilizator TestMonitor încă? Testarea bună și ușoară este o prioritate cheie pentru managerii de asigurare a calității, testmanagers, IT-manageri, manageri de testare și managerul de lansare. TestMonitor face testarea ușor și distractiv pentru utilizatorii de testare, de asemenea.

să începem. Poate doriți să consultați videoclipul nostru sau să descărcați prospectul produsului. Dar, desigur,cu o încercare gratuită, puteți experimenta cu adevărat ușurința utilizării TestMonitor.

păstrăm legătura? Urmăriți TestMonitor pe Twitter și LinkedIn.