Testerens syv gode vaner

Vane nr. 1 - Vær Proaktiv
En testers mål i et softwareprojekt er at sikre, at softwaren har en så høj kvalitet som muligt. Når projekter kører af sporet på grund af dårlig kvalitet kan man enten være proaktiv eller reaktiv, når årsagen skal findes. Den reaktive tester vil straks give andre personer eller omstændigheder skylden for problemerne. Den proaktive tester vil tage medansvar og forsøge at finde ud af, hvordan samme problemer ikke opstår i fremtiden.

Ved slutningen af et projekt bør testholdet lave en evaluering af projektforløbet. Her bør man både diskutere de ting, der gik godt, men også de ting, der gik mindre godt. Her er en række ideer til, hvordan man som tester kan være proaktiv.

A: Tag ansvar for en god kravspecifikation
Det kan ikke nytte noget at lænse sig tilbage og brokke sig over, at kravspecifikiationerne er for dårligt beskrevet. Tag i stedet og samarbejd med kravspecifikatørerne om at få kravene mere præcise, mere udførligt beskrevet og testbare.

B: Analyser sporbarheden
Lav en matrix for at øge sporbarheden i sammenhængen mellem testcases og krav. Det giver bedre mulighed for at analysere, hvor meget dine testcases dækker, hvor langt du er nået og hvor nem softwaren er at teste. Hold møder med dit team, hvor I gennemgår dine testcases for at sikre at kravene er forstået rigtigt og at testen har den rigtige dækningsgrad. Lad udviklerne læse og give review på dine testcases, før de går i gang med at udvikle. Det giver færre rettelser og der bliver brugt mindre tid på QA i sidste ende.

C: Kommuniker effektivt.
Under testen er det vigtigt, at alle kender status på testarbejdet. Kommuniker dagligt via mail eller online diskussionsfora. Her er det vigtigt at give information i målbare størrelser som eksempelvis antallet af defects, hvor stor dækningsgraden er i forhold til kravspecifikationerne eller hvor mange testcases, der er blevet afviklet.

D: Beskriv fejl udførligt.
Når du har fundet en fejl og skal beskrive den, så gør det grundigt og udførligt. Brug tid på at lave en god beskrivelse- Beskrivelsen skal indeholde de skridt man skal udføre for at reproducere fejlen og screen shots bør også vedlægges som dokumentation.

Vane nr. 2 - Fokuser på slutresultatet
Dit mål i et softwareprojekt bør være at levere software af en høj kvalitet, som samtidig opfylder kundens behov. Før den første kodelinje bliver skrevet, bør projektets succeskriterier være nedfædet. Det kan eksempelvis være at softwaren fungerer efter specifikationerne, eller at der ikke må afleveres et produkt med kente fejl. Det gør det nemmere senere hen at vurdere om projektet har været en succes.

Vane nr. 3 - Start med det vigtigste
Det er vigtigt at prioritere arbejdet efter hvor vigtigt det er. Eksempelvis kan vi sikkert alle blive enige om, at negative tests er vigtige for at sikre, at softwaren kan håndtere utænkte situationer på uden at gå helt i brædderne. Men det er ikke vigtigere end at teste om softwaren er i stand til at udføre den opgave den bliver bygget til. Derfor bør man begynde at teste om softwaren kan det den skal.

Eftefølgende kan man lave de negative test og se om man kan få systemet til at brase sammen. Det kan eksempelvis være test med invalide data eller grænseværdi-tests.

Vane nr. 4 - Se det som et vinderspil
I mange organisationer forsøger testere og udviklere at skubbe aben over til hinanden, når der opstår problemer. Det kan være meget ødelæggende for udviklingsprocessen.

Udviklere og testere bør have samme mål - at sikre at softwaren får en høj kvalitet. Når man har det som fælles mål giver det langt mere mening for alle deltagere at hjælpe hinanden.

Vane nr. 5 - Forstå først og bliv forstået bagefter
Mange har den dårlige vane, at de ikke lytter ordentlig med på diskussionerne, fordi de er så opsatte på selv at få fortalt deres eget syn på sagen. Alle i et projekt deltager med forskellig erfaringsbaggrund og har forskellige perspekiver på processerne.

Før man kan løse et problem er det vigtigt at lytte grundigt til, hvad projektdeltagerene har at sige for at kunne forstå problematikken til bunds. Efter alle har sagt det, de ville er det tid til at opstille flere mulige løsninger på problemet. Flere løsningsmodeller giver mulighed for at diskutere problematikken bedre igennem, og det giver projektdeltagerne mulighed for at komme frem til bedre løsninger, der rækker længere end den første indskydelse.

Hvis man er uenig om løsningen er det vigtigt ikke at virke aggressiv overfor den person, der har stillet løsningsforslaget. Forklar i stedet for, hvorfor du synes løsningen er knap så god.

Vane nr. 6 - Skab synergi
Hold-arbjede er nøglen til at skabe synergi. Et team med synergipotentiale består af forskellige typer, der har forskellige styrker, baggrunde og perspektiver. Sørg for at forskellighederne kommer i spil på bedst mulige måde.

Man er mere effektiv, når man ved, hvad ens teammedlemmer er ved at lave. Derfor er teams mere effektive, når de kommunikerer med hinanden. Det kan eksempelvis være at man deler et fælles dokumentbibliotek, der beskriver best practice indenfor det pågældende arbejdsområde.

Vane nr. 7 - Skærp kniven
Den vane kan beskrives ganske kort. De testere, der vedligeholder og uddyber deres evner er også bedst til at levere det bedste stykke arbejde.

De fokuserer på at gøre deres arbejde bedre og nemmere ved eksempelvis at automatisere testcases og gennemføre best practices.


Det er ikke mig, der har fundet på de syv gode vaner for testere. Det er amerikaneren Steve Miller fra Pragmatic Software. Han er til gengæld blevet inspireret af Stephen R. Covey der i 1989 udgav bogen The Seven Habits of Highly Effective People.

Tak til min kollega Jan Nellemann, der fik mig på sporet af artiklen.


Christian Carlsen er testkonsulent i Sogeti