Jeg er stor fortaler for at bruge QTP til automatisering af GUI. Det er et rigtig godt værktøj, hvis man forstår at bruge det rigtigt. Det er kun én ting, som begrænser brugen af QTP - det er prisen.
Prisen for en licens ligger i hvert fald i det leje, hvor en lille virksomhed som min, ikke har råd til at benytte sig af de fantastiske ting man kan med QTP.
Nu er jeg så heldig at jeg kan scripte QTP og har endda bygget et framework, som gør det rigtig nemt at automatisere især webapplikationer, men hvad nytter det, når jeg ikke kan bruge det til mine egne applikationer.
Så hvad gør jeg, når jeg har både BSBoksen og Rojabo.com med funktionalitet til en masse brugere, men ikke har råd til at have testere gående eller råd til at købe en QTP licens? Jeg bygger selvfølgelig mit eget GUI test framework, bygget op over NUnit.
Jeg bruger NUnit til al unit test på backend systemerne til rojabo.com og NUnit og ASPUnit til bsboksen.dk. Men jeg manglede at gå et niveau længere op i V-modellen for at få dækket behovet for regressions test på brugergrænsefladen.
Frameworket er meget inspireret af hvordan QTP fungerer, så mange af metodekaldene er de samme. Men da det er bygget i VB.NET, så har jeg pludselig meget nemmere adgang til at bygge et framework, som er bygget op efter alle kunstens regler for en lag opdelt applikation.
Indtil jeg for taget mig sammen til at skrive et indlæg omkring, hvordan frameworket er bygget op, så kan du more dig med en lille videooptagelse af hvordan mit framework løber igennem 33 regressionstests med i alt 100 assertions på under 4 min.
fredag den 28. maj 2010
Spar tid på både udvikling og test
Vil du gerne spare mange udviklingstimer på tilbageløb og fejlrettelser, og ville dine testere godt undvære at afvikle regressionstesten manuelt gang på gang?
Vil dine udviklere gerne have hurtigt svar tilbage fra testen, så fejlrettelser bliver gjort mens udvikleren har koden frisk i hukommelsen og opgaverne derved bliver rigtig lukket?
Hvis ja - så er løsningen er testautomatisering – men pas på !!!
Der er mange som igangsætter testautomatisering, men havner i en af de mange faldgrupper der findes. Det som jeg oftest har set er, at man sætter en ung udvikler eller en tester uden udviklerbaggrund til at begynde automastisering af testen. I starten ser det rigtig godt ud og alle klapper i hænderne over det magiske i, at se sin applikation blive betjent af en maskine – se helt uden hænder :-)
Desværre viser det sig, at den kode som er blevet genereret af værktøjet ikke er holdbart i det lange løb. Efter noget tid, og fordi applikationen man tester udvikler sig, begynder man ikke at kunne afvikle sine scripts så smertefrit som i starten og man begynder at bruge rigtig meget tid på vedligeholdelse. Til sidst opgiver man helt at køre testen automatisk, da scriptet simpelthen fejler så mange gange, at det kræver en mand på sidelinien til at køre det. Resultat er, at testautomatiseringen stoppes, og bliver lagt på hylden med store skuffelser og tabte investeringer.
Desværre er mange automatiseringsværktøjer så som QTP er tidligere blevet solgt på, at det stort set bare drejer som om capture/replay og en smule scripting. Men automatisering af test er absolut ikke nogen banal opgave. Automatisering er programmering/udvikling på linie med gængs applikationsudvikling. Man skal starte rigtig, bygge koden op efter alle kunstens regler med lag opdelt applikations layout og at testene skal være er designet rigtigt.
Alt i alt så kræver automatisering en stor værktøjskasse, med masser af erfaring inden for applikationsdesign, platforme, sprog, databasedesign, scripting og testdesign.
Udover alle de hardcore tekniske kompetancer det kræves, så er gode kommunikationsevner og pædagogisk indsigt værd at foretrække, da det kræver sit, at få testere og udviklere til at samarbejde og få begge parter til at forstå hinandens berettigelse.
Men når det hele går op i en højere enhed, så er genvinsten stor.
Organisationsmæssigt så har man ofte kompetancen inhouse til at fortsætte automatisering og vedligeholdelsen, for den besides ofte af en senior udvikler og en tester i samarbejde.
Vil dine udviklere gerne have hurtigt svar tilbage fra testen, så fejlrettelser bliver gjort mens udvikleren har koden frisk i hukommelsen og opgaverne derved bliver rigtig lukket?
Testautomatisering betyder: automatisk afvikling af test og automatisk rapportering af fejl.
Dvs. der er ingen personer til at starte testen og ingen personer til at afvikle testen – kun en person til at læse og forstå rapporten om, hvordan testen af applikationen gik.
Dvs. der er ingen personer til at starte testen og ingen personer til at afvikle testen – kun en person til at læse og forstå rapporten om, hvordan testen af applikationen gik.
Hvis ja - så er løsningen er testautomatisering – men pas på !!!
Der er mange som igangsætter testautomatisering, men havner i en af de mange faldgrupper der findes. Det som jeg oftest har set er, at man sætter en ung udvikler eller en tester uden udviklerbaggrund til at begynde automastisering af testen. I starten ser det rigtig godt ud og alle klapper i hænderne over det magiske i, at se sin applikation blive betjent af en maskine – se helt uden hænder :-)
Desværre viser det sig, at den kode som er blevet genereret af værktøjet ikke er holdbart i det lange løb. Efter noget tid, og fordi applikationen man tester udvikler sig, begynder man ikke at kunne afvikle sine scripts så smertefrit som i starten og man begynder at bruge rigtig meget tid på vedligeholdelse. Til sidst opgiver man helt at køre testen automatisk, da scriptet simpelthen fejler så mange gange, at det kræver en mand på sidelinien til at køre det. Resultat er, at testautomatiseringen stoppes, og bliver lagt på hylden med store skuffelser og tabte investeringer.
Desværre er mange automatiseringsværktøjer så som QTP er tidligere blevet solgt på, at det stort set bare drejer som om capture/replay og en smule scripting. Men automatisering af test er absolut ikke nogen banal opgave. Automatisering er programmering/udvikling på linie med gængs applikationsudvikling. Man skal starte rigtig, bygge koden op efter alle kunstens regler med lag opdelt applikations layout og at testene skal være er designet rigtigt.
Alt i alt så kræver automatisering en stor værktøjskasse, med masser af erfaring inden for applikationsdesign, platforme, sprog, databasedesign, scripting og testdesign.
Udover alle de hardcore tekniske kompetancer det kræves, så er gode kommunikationsevner og pædagogisk indsigt værd at foretrække, da det kræver sit, at få testere og udviklere til at samarbejde og få begge parter til at forstå hinandens berettigelse.
Men når det hele går op i en højere enhed, så er genvinsten stor.
- Kvaliteten af softwaren bliver højere
- Udviklingstiden bliver mindre
- Refactoring af applikationen bliver overskueligt
- Udviklerne føler sig i høj grad hjulpet
- Testerne føler sig forstået.
- Kunderne bliver gladere
- Leverance tidspunkterne bliver nemmere at overholde
- Og ikke mindst – Du får ro i maven når du releaser
Organisationsmæssigt så har man ofte kompetancen inhouse til at fortsætte automatisering og vedligeholdelsen, for den besides ofte af en senior udvikler og en tester i samarbejde.
Abonner på:
Opslag (Atom)
