7 Test Case Skrivning Tips til at forbedre din ERP test proces

Test cases er meget vigtige for at sikre kvalitet i din ERP test proces. De er de første trin i en testcyklus, og hvis testcases ikke er af tilstrækkelig kvalitet, bliver hele projektet ‘belastet’. At skrive “store” testsager er en færdighed, der får form ved blot at gøre det. Men det er meget praktisk at have nogle indsigter, der kan hjælpe dig. Med denne artikel vil jeg nå ud til dig og give forslag til at gøre det lettere, sjovere og bedre. De tip, der vil blive givet, vil især vedrøre testsager ved accepttest af ERP-systemer.

hvad er test cases?

inden for verden af test af programmer er der mange definitioner af testcases. På grund af dette er det vigtigt at nævne vores definition. I vores filosofi er testcases (baseret på IEEE610): “et sæt testindgange, udførelsesbetingelser og forventede resultater udviklet til et bestemt mål.”At vide, hvordan man skriver gode testsager, er yderst nyttigt for alle, der ønsker at teste. Uanset om det er en funktionstest, en brugeraccepttest, test af en internetapplikation eller et modul i et ERP-system. I alle situationer, der er beskrevet ovenfor, bestemmer testsagerne, i hvilket omfang resultaterne giver en dom om de forudindstillede mål.

Hvorfor er det så svært at skrive testsager?

som beskrevet i definitionen hjælper testcases testere gennem en række testinstruktioner for at afgøre, om programmet opfylder de foruddefinerede krav. Udførelsen af testsager hjælper os med at indsamle og opdage oplysninger for at realisere det specifikke mål eller mål. Det første problem, vi direkte støder på, er mangfoldigheden af mulige mål. Og fordi der er forskellige typer test og mål, er der forskellige typer tilsvarende testsager.

et andet problem er relateret til indholdet af den faktiske testinstruktion eller trin. Niveauet af disse instruktioner afhænger af den type tester, der skal fortolke disse oplysninger og give en mening. En professionel tester har brug for forskellige instruktioner i modsætning til en slutbruger, der er involveret i accepttest af et ERP-system

Tip 1: Bestem dit mål, og hvad du vil rapportere

tænk over, hvad du vil rapportere, så du kan bestemme dit afledte mål. Ved at bruge det som base har du oversigten over testsagen i betragtning. Der er mange forskellige mål, hvor vi altid skal spørge os selv, hvad vi prøver at lære eller opnå, når vi skal køre testen. Her er nogle eksempler:

• Find fejl: Dette er det klassiske formål med test. En test udføres for at afsløre defekter.
• Maksimer antallet af fejl: Sondringen mellem” maksimere antallet af fejl “og” finde fejl ” er, at det samlede antal fejl er vigtigere end dækningen.
• Bloker for tidlige produktudgivelser: målet med denne test er for tidligt at finde så mange alvorlige defekter (visstoppere), så ingen tager produktet i produktion.
• Support ledere med deres GO/no-go beslutninger: ledere tager beslutninger baseret på risici. Risikoindikationer som testdækning, virkningen af fundne problemer osv. Giv dem en bedre baggrund, som de kan basere deres beslutninger på.
• Vurder overensstemmelse i henhold til specifikationen: de påståede SPECIFIKATIONER kontrolleres for deres drift. Alle forhold, der ikke er forbundet med specifikationerne, ses bort fra.
• Vurder kvaliteten: dette er et vanskeligt mål, fordi kvaliteten er multidimensionel. Kvaliteten afhænger af produktets art. For at vurdere kvaliteten skal der udarbejdes klare kriterier, der defineres på en måde, så de rent faktisk kan gøres målbare.

testresultaterne som afledt af test cases giver direkte relevant information om målet.

Tip 2: reserver tilstrækkelig designtid

reserver nok tid til at designe dine testcases, så de matcher dine mål. Dårlige testsager vil hjemsøge dig gennem hele testprocessen. Sammenligning af testresultater, rapportering om flere testrunder osv. Er i det væsentlige bestemt af kvaliteten af dine testsager.

hvis du allerede løber tør for tid til at designe, men stadig vil begynde at teste, skal du sørge for, at du i det mindste har defineret de største risici. Hvis 10 testere skal gennemgå 5 testsager med 1 testtrin, vil dette resultere i 50 testresultater. Uanset hvad disse 50 resultater giver mere information om kvalitet, så gør ingenting. Dette vil sandsynligvis ikke være udtømmende, men det er et første skridt. Herfra kan detaljeringsniveauet for visse dele bestemmes.

vi foretrækker, at du i god tid tænker over, hvordan testen skal designes, og at resultaterne af testen giver et reelt svar på målet. Men i virkeligheden er dette undertiden uregerligt.

Tip 3: navn test case

navngivning test cases er vigtig. I en gennemsnitlig ERP-test har du let mere end 500 testcases. Du vil forstå, at en logisk navnestruktur forbedrer findbarheden. I litteraturen omtales ofte som et komplet som muligt navn, hvor den skal testes proces, modul, objekt osv. Er alle inkluderet i navnet. Du kan forestille dig, at det at give 500 testsager med en så komplet titel giver en kaotisk administration. Med et enkelt ark mister du nemt overblikket. Teststyringsværktøjer giver en struktur, som du kan relatere testsager til genanvendelige objekter, uden at de “forurener” navnet. Du har også testregistreringsværktøjer, der organiserer disse forhold på en anden måde.

inden for TestMonitor for eksempel opfandt vi en anden løsning. I værktøjet kan du definere etiketter eller tags, som du derefter kan linke til testcases. Inden TestMonitor test cases er knyttet til en eller flere forretningsproces-, risiko-, krav – eller ansøgning etiketter. Dette gør det muligt at gruppere testsager og hente dem fra forskellige perspektiver.

for navnet på en testsag i TestMonitor er det tilstrækkeligt med en klar beskrivelse af formålet med testsagen. For at gøre det enkelt beskriver du en aktivitet med en implicit forventning.

eksempel test case navn:
“opsigelse af leasing – uafhængig hjem”
“Opret kunde” “foreløbig booking kvittering”
etc.

eksempel på testcase “foreløbig bookingkvittering”, som er knyttet til flere etiketter:

• forretningsproces ‘modtagelse af varer’
• krav ‘kontraktkrav’
• risiko ‘operationel risiko’
• ansøgning ‘ERP’

det er vigtigt at beskrive det forventede resultat pr. Testeren ved derefter i hvilken retning “svaret” skal være og får direkte en eksplicit testramme.

Tip 4: Testtrin beskrivelse

som beskrevet i definitionen test cases er en samling testinstruktioner, der hjælper os med at finde information for at nå et bestemt mål.

en testsag skal have en klar begyndelse og slutning for at afgøre, om testsagen bestod eller mislykkedes. Derudover er en testcase sammensat af en eller flere testinstruktioner eller-trin, hvor der er flere stier mulige for at opnå det ønskede resultat. Kun at teste vejen for succes er ofte utilstrækkelig. I visse situationer efter ikke-succes stier kan bare gøre forskellen.

det er vigtigt at definere testtrin så klart som muligt, så slutbrugeren til en brugeraccepttest ved nøjagtigt, hvad de skal gøre. Selvfølgelig er der forudsætninger for at komme op med, ligesom funktionelt niveau tester, kendskab til det nye system, viden om de mulige justerede forretningsprocesser, etc. Men i det væsentlige skal alle forstå alle testtrinnene.

Antag, at vi yderligere beskriver testsagen “Lease termination-independent home” for en simpel successti:

1. vælg en enhed og start opsigelse af lejekontrakten. Kontroller, om der er forudsætninger, blandt hvilke opsigelse af lejekontrakt kan/ikke accepteres, og opret en registrering af dette.
2. Planlæg en aftale til den afsluttende inspektion.
3. udfyld dataene på skærmen opsigelse af lejekontrakt. Dobbelttjek lejerdataene på lejekontraktens opsigelseskort.
4. registrer opsigelsen af lejekontrakten og send et konformationsbrev. Kontroller, om bekræftelsesbrevet er kommet i det digitale arkiv.
5. kontroller i kontraktregistret fra enheden, at den nuværende kontrakt opsiges, at den opsigede kontrakt er knyttet til opsigelsen af lejekontrakten, og at der er en nyoprettet en ledig kontrakt.
6. Kontroller den nye (ledige)kontrakt baseret på lejepolitikken og elementskabeloner.

hvad bemærker du?

• hvert testtrin starter med et verb
• efterfulgt af et emne
• afsluttende med detaljerede og muligvis kontrolspørgsmål. Du kan vælge at sætte kontrolspørgsmålene i separate testtrin, men praksis viser, at kontrolspørgsmålet er en forfining af handlingen og derefter logisk vil blive nedskrevet som et testtrin.

i ovenstående eksempel antages det, at en specialist fra et bestemt felt vil evaluere testtrinet. Og fordi han eller hun er specialist, gives der ingen inputbetingelser eller eksplicit forventninger skitseret, fordi specialisten stadig har sine egne casestudier i ærmet, og hans forventninger er krystalklare.

hvis du i øjeblikket ikke har en specialist, kan du udvide testtrinnene med inputbetingelser og eksplicitte forventninger.

for eksempel testtrin 1 i testsagen “opsigelse af leasinguafhængigt hjem” med flere detaljer.

1. Vælg enheden “Fleet street 677” og start opsigelsen af lejekontrakten. Betingelserne sikrer, at denne enhed ikke kan opsiges, før restancer er betalt.
2. Etc.

Tip 5: Ikke mere end 10 testinstruktion i 1 testcase

vi støder regelmæssigt på testprojekter, hvor >50 testtrin er tildelt en testcase. Dette er for meget af nogle få grunde:

• alle testtrin skal tages separat (eller eksplicit bestået), før en testsag får en dom.
• den endelige vurdering af en testsag bestemmes af den “værste” score. Så det kan godt være, at 49 testtrin vil blive vurderet som “godt” og et som “forkert”, hvad der resulterer i en “forkert” testsag. Målingen af prøvningstrin skal være den samme. Med det mener jeg, at stort set alle testtrin skal være lig med effekten af evalueringen. Hvis du har 10 testtrin, du skal følge, inklusive 2 små testtrin, som de er uforholdsmæssige i forhold til de andre 8 testtrin, skal du omformulere dem. Det samme gælder omvendt med et hårdt testtrin.
• testeren går hurtigt tabt med for mange testtrin i en testsag. Vi har ikke lavet en videnskabelig undersøgelse om det, men praksis viser, at en testsag ikke bør omfatte mere end 10 testtrin. Man kan tænke på mange undtagelser (konverteringskontrol osv.), men i praksis for en brugeraccepttest af et ERP-system fungerer dette bedst.
• det er vanskeligt for udviklere at gengive den fundne fejl. Med mange test trin udvikleren vil miste en masse tid på at forsøge at re-enact situationen.
• Genudsendelser eller gentest af store testsager tager for meget tid. Når en fejl opdages af en tester, skal den tilsvarende testsag testes igen. En gentest kræver, at meget trin vil blive revurderet, du vil naturligvis forhindre regressionsfejl. Ved at tage for mange testtrin tester du sandsynligvis for meget. På denne måde tager testprocessen længere tid og kan i sidste ende overbelaste dine testere.

Derudover har du også testregistreringsværktøjer, der kan præsentere testcases i forskellige former for testeren. TestMonitor har for eksempel to forskellige synspunkter. TestMonitor har et display, der viser alle testtrin separat pr.side og et display, hvor testcases præsenteres pr. side inklusive alle testtrin.Fordelen ved det første display er, at hver tester kan få mere information for hvert testtrin. Ulempen, hvis testeren er mere erfaren, skal han klikke på “Næste” hver gang han vil gå videre til næste testtrin. I den anden opfattelse for hver testsag er fordele og ulemper omvendt.

Tip 6: gennemgang af en ikke-designer/leverandør

i praksis ser vi regelmæssigt testskripter udarbejdet af programmørleverandørens programmører. Når man gennemgår disse testskripter af de eventuelle testere, er der normalt flere spørgsmål end svar. Omvendt fungerer dette det samme for testskripter udarbejdet af deres egen medarbejder. Det giver en reel merværdi ved at gennemgå disse af programleverandøren. De ser på de færdige testskripter med forskellige øjne og kommer altid med meningsfulde tilføjelser eller ændringer.

med lidt brainstorming hos leverandørspecialisterne og klientorganisationen får du hurtigt fokus på essensen af det, der skal testes. Så tag dig tid til at overveje test cases, ikke-succes scenarier, og du vil se, at din testmodel er hurtigt bliver mere omfattende og detaljeret. Derudover får du mere information om kvaliteten, så du skønnede det muligt.

Tip 7: TestMonitor

udover at gøre brug af en professionel test platform og gøre kvalitet virkelig indsigtsfuld. Anmod om en gratis prøveversion af TestMonitor i dag og se og opleve forskellen for dig selv.

hvis du er en nybegynder i testverdenen, bliver du let overvældet af al testterminologien, der bliver kastet rundt. I denne artikel vil vi forsøge at forklare noget af det jargon, du måtte støde på i dit daglige testliv, bare for at gøre det hele lidt mere forståeligt.

Start test med TestMonitor

ikke en TestMonitor bruger endnu? God og nem test er nøgleprioritet for kvalitetssikringsledere, testledere, IT-ledere, testledere og release manager. TestMonitor gør test nemt og sjovt for testbrugere så godt.

så lad os komme i gang. Du vil måske tjekke vores video eller hente produktbrochuren. Men selvfølgelig kan du med en gratis prøveperiode virkelig opleve brugervenligheden af TestMonitor selv.

holde kontakten? Følg TestMonitor på kvidre og LinkedIn.