technicaltester

[technicaltester]

Nogen gange kan den her tester mentalitet gå lidt for vidt. Som f.eks. her i weekenden, da jeg erfarede at Holland var blevet smidt ud af melodi Grand Prix, følte jeg det nærmest som en pligt og forsøge at stemme på dem. Det kunne man naturligvis ikke, men det var da forsøget værd 😂😜

[technicaltester]

Specielt fejlsektionen af den linkede artiker en en super god måde håndtere fejlsituationer i HTTP baserede API baseret på en fejltype (application/problem-json) hvori man både kan komme med en egentlig fejlbesked til brugeren samt give gode meta informationer om den fejl der er opstået og hvad der skal til på klientsiden for at fikse fejlen inden næste forsøg.

Jeg er fan!

[technicaltester]

Hvorfor følger de ikke mine anbefalinger når nu vi har lagt så meget arbejde i at finde frem til dem?!?

En ting der ofte kan være lidt frustrerende er når man som tester på et projekt lægger et godt stykke arbejde i at undersøge om et givet system er klar til brug eller om der stadig er en fejl eller to som forhindre systemets virke. For så at se dem man udføre dette arbejde for så ikke følger ens anbefalinger. Forud for anbefalingen ligger ikke kun mit arbjde, men også arbejdet for de af mine peers der er på projektet, hvilket godt kan beløbe sig til en anselig udgift man lidt føler lige bliver skullet ud i W.C’et.

Sagen er bare den at der er mange faktore i spil når en ledelse beslutter hvorvidt et system eller en ændring til et system skal idriftsættes, og ofter er de andre faktore så tungtvejende at de tilsidesætter konklusionen i testrapporten, i det tilfælde at den ikke er enig.

Min erfaring siger at disse faktore også kan spille en meget vigtig rolle i forhold til hvorvidt et system skal idriftsættes uanset det måske stadig mangler lidt for at være “færdig”:

Hvis det system som bliver erstattet af det nye system og er meget buggy, så kan det være at det stadig er en forbedring overordnet set.

Hvis der er licensomkostninger med at vente med en release, kan de gøre at det er mere attraktivt forretningsmæssigt at kører lidt langsommere et par måneder, grundet mange fejl, end at skulle betale en ny licens for en periode for det system som evt erstattes ved en idriftsættelse.

Hvis man har lovet evt samarbdspartnere adgang til nogen data som det nye system facilitere, og har lovet det til en given dato, og den dato er en del af en større kontrakt, så kan det være at det er bedre at acceptere fejl i software frem for at genforhandle den aftlale der er indgået med samarbejdspartner(ne).

Og igen, men skal ikke undervurdere ego’et på chefer der sidder med go / no-go beslutningen. Det er set flere gange at “nogen” i den position har taget en direkte dårlig beslutning for ikke at tabe ansigt på andre områder.

Men hvad kan vi så gøre for at gøre vores arbejde bedre gældende når vores input kun er en del af det der skal tages stilling til

Vi skal levere det der hedder et go-live advise, og dette levere vi som oftes i form af en test rapport. Sagen er den at denne testrapport ofte indeholder rigtigt meget data om hvordan det er gået under testen, hvilke fejl der er fundet og rettet som en del af testen, og lignende. Denne del af informationen bliver ret ofte ikke læst, og den rigtige grund til at vi overhovedet rapportere det, er for at bevise at vi rent faktisk har lavet noget som testere på projektet. Det er imidlertid ikke det som en ledelse har behov for at se. Oftes er det ikke muligt at ændre på formatet af testrapporten så vi skal have en anden løsning.

Problemet med den traditionelle testrapport er at den er alt for tung. Dens format er oftest en del af en leverance kontrakt eller skabelonen den leveres ud fra er dikteret “oppefra” og skal overholdes for at lave en fyldestgørende leverace, uanset om der nogen sinde er nogen der læser den, eller for den sags skyld forstår den indhold og dets betydning. Tiden er løbet fra testrapporten og vi har længe haft meget bedre glææde af dashboards i stedet, men det er et helt andet blogpost.

Der er imidlertid en del af testrapproten der er guld værd, og det er naturligvis selve go-live advise delen. Mit forslag er at trække dette ud i et bilag sådan at vi kan frigøre det fra alt det der tynger det ned ved at være en del af testrapporten. Her kan vi så definere følgende:

En sektion der opsummere go-live advise i form af hvad test organisationen mener om hvorvidt det er OK at release systemet i dets nuværende tilstand.

For hver fejl af en vis grad, så dokumenter kort hvad fejlen er, om der er en workaround og hvor stor impact er på daglig drift som hvis muligt hvilke områder der er berørte.

Det er vigtigt at holde dette bilag kort, kontant og fri for følelser, det skal bare være de nøgterne data på hvor vi er og konsekvensen ved et go-live lige nu.

Dette er for at give ledelsen et godt værktil at tage med op til en samlet vurdering i forhold til de andre ting de skal vurdere hvorvodt der skal gives grøndt lyd for en idriftsættelse. Så kan kvaliteten deltage på lige fod med de andre faktore i stedet for bare at være noget som bliver tilsidesat det det ikke siger det man gerne vil høre. (jo det sker, ofte!)

Har du gode kommentare så hører jeg gerne fra dig!

[technicaltester]

Hvilket testniveau er det rigtige for en regressionstest?

Jeg er blevet stillet dette spørgsmål et par gange, og her er hvad jeg mener om hvordan en regressionstest skal se ud.

En regressionstest handler om at sikre at vi ikke ser regressioner, så alt funktionel test kan mere eller mindre falde ind under denne kategori, men det som de fleste forbinder med en regressionstest, så er det en test der er fokuseret på at fejl vi har oplevet ikke kommer igen samt at sikre god testdækning af højrisiko områder. Højrisikoområder bør i deres natur allerede have en høj testdækning, men somme tider får de ekstra kærlighed i regressionstesten også.

Da regressiontesten som regel har meget til fælles med en standard systemtest, så har man også en tendens til at lægge den på det niveau, og det er nok heller ikke helt forkert. Vi har dog lært dels af shift-left bevægelsen i test samt af almindelig sund fornuft, at det er en god ide at fange regressioner så tidligt som muligt. Det betyder at komponent testen nok også er et ret godt sted at placere den.

Min anbefaling til placering af regresionstest er derfor følgende: Den skal både være på komponent niveau og på systemtest niveau. Her kommer en kort forklaring:

Komponent niveau regressionstesten fanger regressioner hurtigst muligt og, lidt afhængig af build opsætning, sikkert allerede inden udvikleren, der har introduceret en regression, har committet koden til et repositorie. Hvis ikke er det helt klart en forbedringsmulighed til build setup’et. Problemet med denne test er imidlertid at den ofte kan have rigtigt mange permutationer før at den fanger alle scenarier, og det er ikke altid at udviklere er opmærksom på dem. Derfor er det helt sikkert også en god ide at lige tjekke på niveauet ovenover.

En anden ting er at der som regel ikke er nogen testrapportering andet en en dæknings metrik, så der er ikke nogen andre en udvikleren og eventuelt den tester der har hjulpet udvikleren med at lave komponent testen, som ved at der bliver testet for regressioner som en del af komponent testen. Det betyder at projekt personer som ikke er udviklere eller testere, som regel ikke ved at regresionstesten eksistere hvis den kun findes på dette niveau.

Systemtest niveau regressionstesten er sådan set at betragte som en fuldkommen klassisk systemtest, dog hvor der er fokus på at alle de fejl der er fundet i systemet gennem dets levetid har en eller flere testcases der sikre at disse fejl ikke kommer igen.

Det god ved at have regressionstest på dette niveau er at der formentligt vil være en eller anden form for testrapport som vil afspejle at denne test er blevet foretaget. Det gør at projektets interessenter kan blive informeret om at regressiontesten er blevet udført som en del af testrapporten.

En anden god ting er også at systemtesten som regel laves på et integreret miljø hvor forudsætningerne er lidt anderledes end på udviklerens lokale miljø. Det gør at det giver mening at køre testen begge steder da man ikke vil finde regressioner relateret til integrationer på udviklerens lokale miljø. Dog koster det også mere at afvikle test på dette niveau end det gør på komponent niveau, men man skal her også huske at man kan opnå store besparelser på afviklingsomkostningerne hvis man automatisere testen, og en regressionstest er en prima kandidat til at blive automatiseret da den i natur er tjekkende mere end den er udforskende, men mere om det i en anden artikel.

Konklusion er at regressionstest bør findes både på komponenttest niveau og på systemtest niveau. Hvert niveau har sine fordele og selv om noget vil være duplikeret, så vil der også være mange steder hvor testen komplimetere hinanden.

[technicaltester]

Så har vi fået det der AI...

Der har været så meget snak om AI at det føles som om alle er ved at drukne i det. Der er også de frelste som lovpriser det som om det er det bedste der er sket i verden. Jeg personligt syntes at det er lidt svært at vide hvad man skal gøre med det.

Det er helt tydeligt at mange har en mening, og mange er glade for at kunne slippe for repetitive og kedeligt arbejde, men der er lige det med det her AI, at du lidt er nødt til at tjekke alt hvad den laver for den lyver også meget overbevisende. Faktisk, når man tænker over det, så er det lidt ironisk at menneskeligheden opfinder kunstig intelligens, og det første den kan finde ud af er den del jeg personligt syntes mindst godt om hos mennesker, nemlig at de lyver hele tiden. Nu har vi lave et maskine der kan lyve for os meget hurtigere og med langt højere overbevisning end hvad vi selv kan finde ud af. Vi har simpelt hen taget menneskelighedens værste træk og fået en computer til at gøre det hurtigere og mere overbevisende. Det er da tidsspile på højere plan.

Jeg har adgang til GPT3 fra OpenAI via en app kaldet Craft. Det er en notetagningsapp som har GPT funktionaliteten indlejret. Jeg spurgte den om følgende:

Man har en 8 liters dunk og en 12 liters dunk, hvordan kan man måle 8 liter vand af?

Den svarede:

Først fyldes 12 liters dunken helt op med vand, derefter hældes noget af vandet fra 12 liters dunken over i 8 liters dunken. Når 8 liters dunken er fyldt, er det præcis 8 liter vand. Til sidst hældes resten af vandet tilbage i 12 liters dunken.

Selv om det ikke er teknisk forkert, så er det ikke en smart opskrift. Jeg vil mene det er væsentlig nemmere at bare måle de 8 liter af via 8 liters dunken...

Og det her kendetegner meget af det jeg har set AI gøre, netop det hvor at den levere et resultat der muligvis kan virke, men bestemt ikke er det mest optimale, og nogen gange er den ret så dum okring at gøre det. På den anden side er den super hurtig til at komme med de resultater den kommer med, og man kan bruge det til at komme igang med at tænke over den rigtige løsning ved at se på en klodset AI genereret løsning og så gå i gang med at forbedre.

Der er også den situation hvor man vidensmæssigt er 100% uforstående om hvordan man skal løse en opgave, og man er sådan set ligeglad med at løse den optimalt, hvis man bare kan komme hen til at man rent faktisk kan løse den, og her vil AI kunne bruges til at levere en løsning, men man skal ikke være særlig kræsen inden man vil have lyst til at optimere på den løsning.

[technicaltester]

Aftenhimlen over Glostrup