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.
