Test strategi for software test automation

Software test automation er regressionstest, det vil sige. at man tester om det, der virkede i går, også virker i dag.

Testware holder næsten 40 års akkumuleret viden omkring, hvordan man laver software test automation, der giver værdi i mange år.

Vi har fejlet. Og vi har været succesfulde.

Derfor har vi gennem erfaring opnået viden om, hvad der kan lade sig gøre indenfor en overskuelig fremtid. Og vi har erfaring med, hvad der ikke kan lade sig gøre.

Men vigtigst af alt, så har vi lært, hvad der giver værdi til et projekt:

• Pålidelige test der afvikles ofte og hurtigt

Dette er også den proces Jez Humble m.fl. foreslår i “The DevOps Handbook”:

In other words, we start with a small number of reliable automated tests and add them over time, creating an ever-increasing level of assurance that we will quickly detect any changes to the system that take us out of a deployable state.

Man starter altså med mindre simple test cases (eksempelvis 10), og får dem til at blive afviklet, som en del af build processen. Først herefter udbygges.

Efter denne første “test bølge”, så kan man starte den næste test bølge, der er accept testen, som afvikles mod rigtige data. Denne test tager ofte længere tid at afvikle.

Hvilke tests skal man så vælge

Vi vil gerne automatisere flest mulige af de manuelle tests, da det frigør testerne til mere interessante opgaver end trivielle regressions tests. Eller man kan benytte testen til hurtigere at validere en release.

Men man skal passe på, da man ikke ønsker non-deterministiske tests, der ukontrolleret fejler eller er ok. Disse tests kan skyldes dårlig performance, uforudset state pga stubbing, fejl i udgangspunktet, eller at man deler et test miljø. Har man mange af denne type tests vil værdien af testen mindskes for til slut helt at forsvinde.

Automatiseret GUI test er kostbart at udvikle, og ofte tager disse længere tid at udvikle end lavere liggende test. Se eventuelt Mike Cohns test automation pyramide, eller Martin Fowlers “The ideal test automation pyramid” (se nedenfor).

Det er vigtigt at have et godt fundament, inden man starter på Automatiserede GUI end-to-end scenarier.

Man skal sikre sig, at unit test kører, og at der er udviklet og afviklet komponent tests på applikationen. Ovenpå dette kan man lægge den automatiske end-to-end valideringstest, hvis man derimod starter med automatisk GUI test, vil man komme til at bruge mere tid og flere ressourcer, end ved at vælge den ideelle vej.

Testware har afprøvet begge veje og anbefaler altid “Ideal Test Automation Pyramid”. Det giver værdi for projektet.