www.softwaretestforum.dk Forum Index www.softwaretestforum.dk
Virtuelle netværks forum for dem som arbejder professionelt med QA og software test
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Hvad skal man huske på, når man laver testcases

 
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Teknikker til test
View previous topic :: View next topic  
Author Message
Marck Petersen
Bruger på niveau 5
Bruger på niveau 5


Joined: 16 Jan 2008
Posts: 86
Location: København

PostPosted: Fri Apr 11, 2008 9:55 am    Post subject: Hvad skal man huske på, når man laver testcases Reply with quote

Jeg har altid nogle punkter som jeg huske på når jeg skal til at skrive testcases

- Dokumentationen læses igennem og der dannes et overblik over mulige varianser for funktionsområdet.
- Der aftales et møde med den ansvarlige udvikler, hvor der afstemmes et fælles billede af funktionsområdet og niveau for testdækningen.
- Hvis det er nødvendigt, formuleres der en testplan for hvert funktionsområde, der sendes til review hos de ansvarlige udviklere og alternativt hos forretning med særlig interesse i kvalitetssikringen af området
- Husk at en testcase altid har et formål: ”Hvad vil jeg teste?” (funktionalitet, arbejdsflow, beskrivelser i menuer, navne på knapper, etc)
- Start med de positive testcases, derefter med de negative.
- Vær opmærksom på omhyggelig beskrivelse af testdata, sådan at du kan bruge informationen til oprettelse af testdata i vores testmiljø på et senere tidspunkt.
- Et step i en testcase indeholder en beskrivelse af funktionelle valg (flueben, indtastning i felter) og steppet afsluttes af bekræftigelsen af disse valg (eks. ”Send” eller ”OK” ). En fornuftig længde på en testcase, stepmæssigt er 5-15 steps.
- Niveauet i beskrivelsen skal ligge, så en kollega kan udføre testen på basis af din testcases

Hvad mener du man skal husk på…?
Back to top
View user's profile Send private message Visit poster's website
Flemming Wulff



Joined: 19 Feb 2008
Posts: 2
Location: Slagelse

PostPosted: Mon Apr 14, 2008 8:01 pm    Post subject: Reply with quote

Det er nogle rigtige gode betragtninger om testcases, som du har beskrevet. Vil dog gerne knytte nogle kommentarer:

Jeg har ofte gjort brug af testmatricer til at beskrive, hvad jeg vil teste, inden jeg begynder at skrive testcasene. Det giver et godt overblik over, hvordan jeg kan gruppere min test. Det er også nemmere for andre at reviewe, om jeg har planlagt at teste det rigtige.

Det er vigtigt, at man har en ide, om hvem der skal afvikle testcasene, når man beskriver dem. Er det garvet tester eller er det "folk fra gaden"? Hvilke forudsætninger har de for at teste? Dette kan have betydning for, hvor detaljeret testcasene skal beskrives. Omkring detaljeringen er det også vigtigt at vurdere, hvor god/færdig er dokumentationen, som ligger til grund for testcasene. Hvis den er "nagelfast" kan man godt være meget præcis i testcasene. Hvis man derimod vurdere, at den nok ikke er færdig og den vil blive ændre mange gange inden testafviklingen, vil det være en god ide, at man tager højde for det, når testcasene udarbejdes. Ellers risikere man at stå med en masse testcases, som er forkert ift. den endelige løsning.

En god testcase skal som minimum indeholde:
- formål, som beskriver hvad testcasen går ud på,
- forudsætninger, som skal være opfyldt inden testen kan afvikles,
- beskrivelse af krav til testdata,
- en prioritering af testcasens vigtighed,
- henvisning til de(t) krav, som testcasen tester
- et antal testtrin, som indeholder beskrivelse af, hvordan der skal testes samt, hvad det forventet resultat er.

Testcasene skal også reviewes inden de afvikles. Her kan skelnes mellem:
- testmæssigt, som skal sikre, at testcasen overholder aftalte standard/notation og at den er testbar
- forretningsmæssigt, som sikre at testen er dækkende og korrekt for det, som ønskes testet.
Back to top
View user's profile Send private message Send e-mail
Bjarne Lykkegaard
Bruger på niveau 1
Bruger på niveau 1


Joined: 01 Aug 2008
Posts: 14
Location: Randers

PostPosted: Mon Aug 18, 2008 2:52 pm    Post subject: Formuleringen i test cases og detaljeringsgraden Reply with quote

Formuleringen i test cases og detaljeringsgraden er også vigtig at overveje.

Uanset hvordan man laver sine Test Cases, så vil et givet test scenario altid teste øvrig funktionalitet implicit. Men ellers bør en test case ikke være alt for "bred".

Hvis man kan undgå at bruge navne på knapper/funktioner, så bør det gøres, da man så er fri for at opdatere alle sine test cases, hvis en knap pludselig får et ny navn. Man bør i det hele taget forsøge at lave sin beskrivelse så den er generisk, dog uden at gøre det svært at læse og forstå test casen.

Man kan f.eks. definere sine egne navne på knapper/funktioner, og så bare lave en krydsreference der viser det rigtige navn på knappen/funktionen. Hvis knappen så ændre navn, skal du kun opdatere krydsreferencen.

Samtidig bør man undgå alt for mange henvisninger, da man hurtigt havner i et spindelvæv af henvisninger der gør tingene uoverskuelige og forårsager, at man ved den mindste ændring er nødt til at nærlæse alt. En løsning er at droppe enhver henvisning, og i stedet for opbygge en god indholdsfortegnelse, stikordsliste eller en grafisk oversigt.

"Gummi ord" bør undgås. Ord som: sædvanligvis, normalt, så vidt muligt, i de fleste tilfælde, hurtigt, langsomt, mange, få, dyrt, billigt, tilfredsstillende, dårligt, godt, er "uklare" ord. Når en sætning ikke er entydig skal den omformuleres.

Hvis ordet "ikke" bruges i lange tekst-linierne, så skal man passe på, at negationen ikke er glemt når budskabet nås. Derved bliver det forståede budskab det modsatte af det tiltænkte. Overflødighed og dobbeltkonfekt (dvs. overflødige sætninger og at man gentager sig selv) skal man undgå. Mere informationsmængde en nødvendigt tilslører budskabet.

Ord der indeholder underforståede budskaber skal undgås. Eksempler kan være, "men vi gider ikke" eller "undgå utilsigtet fejl". Ordet "gider" er negativt ladet og tilkendegiver manglende lyst. Ordet "utilsigtet" tilkendegiver, at vise andre fejl åbenbart er tilsigtet.

Teksten må heller ikke svækkes ved, at der i en test case f.eks. skrives, "At man skal være ekstra omhyggelig når man....". Det er det samme som at give lov til, at man er mindre omhyggelig når man gør det andet.

Man bør sætte sig i læserens sted når man skriver sine test cases. Det der er logisk viden for mig behøver ikke være det for læseren. Man skal især passe på, hvis man sidder inde med stor viden om det emne/system man skriver test cases til. For gør man det, så kan man nemt glemme en lille forklaring, som ellers vil lette hele forståelsen hos læseren. Man bør sørge for, at der er en ”rød tråd” igennem det man skriver og hele tiden overveje, om den rækkefølge man har valgt er okay, for måske læseren har brug for en forklaring på noget før man begynder på et afsnit/beskrivelse.

Selv om jeg ikke selv er for god til korrekt stavemåde og tegnsætning, så skal man selvfølgelig sørge for korrekt stavemåde og at fagtermer bruges korrekt. Ligeledes kan manglende eller fejlagtig kommasætning fuldstændig ødelægge en sætning, og den bliver derved uforståelig eller misforstået. Den berømte anekdote om fangen der bliver benådet, men bliv hængt pga. en kommafejl i brevet fra kongen, vise med alt tydelighed hvor vigtige kommaer er - for der er stor forskel på teksten ”Hænges ikke, frifindes” og teksten ”Hænges, frifindes ikke”.

Jeg har i øvrigt engang set en jobansøgning hvor der stod… ”jeg er samboende med min kæreste Maria på 6 år”. Lige da jeg læste det, tænkte jeg…Gud, det var en ung kæreste, er han mon pædofil”. Men der burde nok have været et punktum efter ”6-tallet” således, at han var… ”samboende med sin kæreste Maria på 6. år” (sjette år).
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.softwaretestforum.dk Forum Index -> Teknikker til test All times are GMT + 2 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group