tirsdag den 7. juni 2016

4 ting alle testere bør kunne…

Egentlig kan jeg ikke lide disse liste artikler, så det virker sådan set lidt paradoksalt at skrive en, men jeg kunne ikke komme på en bedre titel.

Sagen er den at hvis man i dag vi skrive tester på visit kortet så er der nogen generelle ting som man forventes at kunne. Disse ting er efter min mening et klokke klart krav hvis man gerne vil arbejde med test på et professionelt plan uanset om det som skrivebordsjob eller som konsulent. De 4 ting jeg har tænkt mig at se på her er på ingen måde en fyldestgørende liste, men 4 ting som jeg har set en del gange mangle hos testere, og i enkelte tilfælde har disse testere heller ikke udvist villighed til at lære, hvilket også har sat dem i en situation der var problematisk.

1. Teknisk indsigt

Nej jeg siger ikke at alle testere skal kunne læse kode, det er en god egenskab at have som tester, men ikke et krav. Det er imidlertid et krav at man kan sætte sig ind i hvordan systemer virker. Man behøver ikke at forstå de store arkitektoniske buzzwords, men forstå det skal man kunne, og det er helt klart en god ide hvis man er lidt opsøgende omkring det. Kan man ikke få dokumentation på et niveau hvor det virker forståeligt, så kan man altid få fat i en udvikler eller lign. der kan oversætte det til almindelig dansk eller engelsk alt efter ens preferencer.

Et eksempel kunne være et distribueret system som måske også indeholder en ESB eller lignende brooker. Her skal man naturligvis ikke kunne forstå alt omkring de messages der bliver sendt rundt i brookeren, men det er vigtigt at forstå at der for en given funktion i systemer indgår nogle beskeder som man kan måle på når man skal tjekke at backend har modtaget info fra en frontend system.

2. Automatiserings viden

Nej alle testere skal ikke kun orkestrere en distribueret end-to-end test via de seneste kommercielle superværktøjer, heller ikke noget det bare kommer i nærheden af, men der er virkeligt mange opgaver som man udfører som tester som er repetitive og som man virkeligt kan vinde meget tid ved at automatisere. Da vi som testere som regel har nem adgang til automatiserings værktøjer og det også op til os at gå foran med et godt eksempel i forhold til at bruge disse automatiseringsværktøjer til at af-bureaukratisere vores verden.

Hvis du ikke har adgang til disse værktøjer er de stadig nemme at få fat på. Du skal f.eks bare have Java installeret, noget man ofte har på firma PC’ere, for at kunne anvende SikuliX. SikuliX bruger et pixel genkendelses værktøj til at forestå automatiseringen, så hvis det er på din skærm og du kan klikke på det eller skrive i det med tastaturet, så kan SikuliX automatisere det. Det kræver ikke engang du er administrator på maskinen. Jeg har f.eks brugt det til at automatisere et SAP tidsregistreringsværktøj som er implementeret på en anden host og køres på min maskine via Citrix. Dette kunne fint lade sig gøre med SikuliX. Der er også auto-it og andre lignende værktøjer der kan hjælpe med automatiseringen.

3. Gode kommunikative egenskaber

Som tester er det sådan set ens arbejde at fortælle andre hvad det er de gør forkert. Det kan nogen gange være en tricky opgave, specielt hvis man har med nærtagende personer at gøre. Det er selv sagt en klar nødvendighed at kunne fortælle en udvikler på en pæn måde at det kode han eller hun har lavet (og som han eller hun føler for som var det deres barn) ikke er helt godt nok og de nok har vundet en ommer. It’s a dirty job but someone has to do it :-)

Men det er ikke det eneste sted hvor de gode kommunikations egenskaber skal bruges. Det kan også nogen gange være sin sag at få en projektleder til at forstå at der altså ikke nødvendigvis er en direkte relation i forhold til hvor mange fejl der er fundet i en release og den tid det tager at rette dem.
I fejlløsnings situationer kan testerenogså bidrage til at få folk som normalt ikke snakker samme sprog (forretningseksperten og udvikleren f.eks), til at kommunikere direkte sådan at man hurtigst muligt for løst en fejl, og vel at mærke vælger den rigtige løsning.

4. Testdesign teknikker

Som professionel tester kan man ikke forventes at kunne udføre en fyldestgørende test med en bare nogen lunde styret dækningsgrad uden at have gjort brug af en eller flere testdesign teknikker. Uanset om det er de meget intuitive teknikker som f.eks grænseværdig analyse og ækvivalens partitionering eller om det er de lidt mere komplekse som data kombinations test, så ligger det helt fast at hvis du har styr på dine testdesign tekinkker, så har du bedre kontrol over din indsats på alle planer og du vil formentlig også nå meget hurtigere frem til den.

Man skal også se testdesign teknikker som et kommunikations redskab. Testere imellem kan vi bruge disse testdesign teknikker på sammen måde som udviklere kommunikere via design patterns. Den mere erfarne tester kan sige til junior testeren at: “Her kan vi bruge en data kombinationsteknik til at afdække alle mulige input til skærmbillederne for denne usecase…” og hvis testeren har en ide om hvad denne teknik dækker over, så skulle det være ret så indlysende at gå igang og man har i processen også overført noget viden og erfaring om hvor denne teknik giver mening at anvende.

Det var så listen. Som jeg skrev i starten så er det ikke en fyldestgørende liste, men de 4 her er vigtige. Tak fordi du læste den.