Automatiseret testning er blevet så integreret i bestemte rutiner, at nogle testere spekulerer på, om det helt vil erstatte manuel testning.
Ikke foreløbig.
Da Teslas team designede Model 3, var en af måderne, de ønskede at øge produktionshastigheden på, at have et fuldautomatisk samlebånd. AI skulle samle bilen med næsten ingen overvågning fra mennesker.
Planen mislykkedes katastrofalt.
Biler kolliderede med hinanden, døre blev boret ind i vinduer, og dækkene kom ikke ordentligt på deres fælge.
Hvad skete der? Det viste sig, at robotter ikke kan se særlig godt. Den AI, der stod for at samle Model 3, var ude af stand til at tilpasse sig uventede komplikationer eller små fejljusteringer. Hvis alt ikke var justeret helt korrekt, begik den katastrofale fejl.
Det samme gælder for automatiseret testning inden for QA. Nogle former for testning har for mange variabler og kræver, at den manuelle tester kan korrigere kursen og fejlfinde undervejs.
Hvad er automatiseret testning?
Automatiseret testning betyder, at en QA-tester bruger et værktøj til at udføre en testsag. I udviklingscyklussen vil den samme testsag blive testet flere gange.
Nogle af de testsager, som det ville tage et team af QA-testere flere timer at gennemgå manuelt, kan udføres af et automatiseret værktøj på få minutter. Flere værktøjer til automatiseret testning er blevet branchestandarden.
Den mørke side af automatiseret testning
Andre brancher, håndværk og erhverv har måttet håndtere indførelsen af automatisering inden for deres område. Når det er sket, hvad enten det har været inden for luftfart med autopilot, tæppevævning eller testning, mister de ansatte på området deres forståelse af ‘hvorfor’ bag deres arbejde.
Dette er et fænomen, som QA-fagpersonen Jan Jaap Cannegieter bemærkede var begyndt at ske blandt testere. Hans største frygt er, at den nemme adgang til automatiseret testning og det stigende pres for at automatisere en stor del af testprocessen vil føre til en generation af testere, der ved, hvilke handlinger de skal udføre, men mangler en forståelse af hvorfor.
Mange testere ved alt om bestemte værktøjer eller programmeringssprog, men de kan ikke fortælle mig, hvad de tester, og hvorfor de tester det. Og det er en dårlig ting.
Have an account? Log In
Eksempler på dårlig automatiseret testning
Mange QA-testere ser det samme potentiale i automatiseret testning. Typisk betyder det, at der er observerbare tendenser og almindelige fejl, som en QA-tester kan begå. Her er nogle almindelige eksempler på dårlig automatiseret testning.
Indlejring af automatiserede test
Indlejring af automatiserede test betyder, at flere automatiserede test køres oven på hinanden. Når det sker, bliver det svært at finde ud af, hvad der er gået galt, når der opstår en fejl.
På kort sigt er de fleste tilfælde af automatiseret testning positive. QA-testeren bruger det rigtige værktøj og kører det korrekt.
Mange eksempler på dårlig automatiseret testning bliver først dårlige seks måneder senere, når automatiserede test er blevet indlejret i andre automatiserede test, som igen er indlejret i andre automatiserede test.
Automatiseret brugerfladetestning uden overvågning
Brugerfladetestning sikrer, at der ikke er noget, en bruger kan gøre på brugerfladen, som får programmet til at gå i stykker eller forårsager funktionsfejl. Når det testes manuelt, kan det kræve mange testere og mange arbejdstimer. Det er helt ærligt ineffektivt at teste på den måde, især når programmet bliver større, og flere funktioner kræver testning.
Med automatiseret testning bliver processen hurtigere, men den kan stadig kræve en QA-testers computers fulde kapacitet en hel dag. For at håndtere det kører QA-testere testen sidst på dagen, lader den arbejde natten over og kommer tilbage på arbejde næste morgen, hvor resultaterne ligger klar og venter på dem. Det giver mening, ikke?
På overfladen virker det som det smarte at gøre. QA-testeren bruger sin computer til at teste andre programmer i løbet af dagen og kører derefter den automatiserede testning af brugerfladen om natten.
Det er netop, fordi det giver intuitiv mening, at dette er en almindelig fejl. Der kan gå meget galt, når automatiseret testning udføres uden overvågning.
Hvis noget går galt tidligt i processen, vil resten af resultaterne være forkerte. En hel dags testning gav ingen nyttige oplysninger på grund af en fejl, der nemt kunne være blevet opdaget og rettet, hvis nogen havde været til stede for at kontrollere, at automatiseringstesten fungerede korrekt.
Selvom automatiseret testning nogle gange kan føre til falske positive resultater, kan valget af de rigtige QA-værktøjer til testautomatisering reducere sådanne tilfælde betydeligt.
Automatisering af de forkerte ting
Automatiseret testning tager tid at opsætte. QA skal sikre, at automatiseringsværktøjerne passer til projektet, og at QA-testerne ved, hvordan værktøjerne bruges korrekt.
Alt dette kræver masser af tid og organisering, og hvis slutresultatet er, at en test, der typisk køres én gang om måneden, bliver automatiseret, er det ikke besværet værd. Før du begynder med automatiseret testning, skal du sikre dig, at det, du vil automatisere, vil spare QA-testerne for en målbar mængde tid.
Ikke alene kan du automatisere opgaver, der forekommer for sjældent til at være besværet værd, nogle opgaver kan ganske enkelt ikke automatiseres nemt.
Erstatning af manuel testning
Automatiseret testning kan kun opdage det, den er blevet instrueret i at lede efter. Hvis skrifttyperne på en webside ser mærkelige ud, men testen kun kontrollerede, om alle links på webstedet fungerede, løser den ét problem (linkene), men ved ikke, at der er noget galt med det andet (skrifttyperne).
Manuel testning kan opdage ting uden for testens oprindelige omfang. Metoden med eksplorativ testning blev udviklet for at give QA-testeren mulighed for at finde uventede fejl, efterhånden som de opstod, selvom det ikke var det, vedkommende oprindeligt ledte efter. Når automatiseret testning er fokuseret på en enkelt opgave, kan den være grundig. Men den kan ikke være omfattende.
Eksempler på god automatiseret testning
Testautomatisering udføres for at minimere risikoen. Når en QA-tester kan minimere risikoen og maksimere effektiviteten, bør automatiseret testning absolut udføres. Der er ingen grund til, at en QA-tester bruger timer på manuelt at kontrollere links på et websted, når en webcrawler kan udføre den samme aktivitet på kortere tid og med mindre sandsynlighed for at begå en fejl.
En god tommelfingerregel for at afgøre, hvornår automatiseret testning bør bruges i stedet for manuel testning, er at spørge, om testen vil være hurtig eller kontinuerlig. Hvis testen skal køre kontinuerligt, er automatiseret testning vejen frem.
Mennesker er dårligere end maskiner, når det gælder om konsekvent at udføre gentagne opgaver på et højt niveau. Vi søger fornyelse og kobler mentalt fra, når vi gør det samme for længe. Det giver fejl mulighed for at slippe igennem.
På den måde vil en QA-tester indse, at vedkommende: a) har brugt mere tid, end hvis automatiseret testning var blevet kørt, og b) har udført et dårligere stykke arbejde og skabt flere problemer senere.
Jason Huggins, grundlæggeren af det populære automatiseringstestværktøj Selenium, udviklede programmet, fordi han oplevede, at så mange af hans dage som tester gik med at udføre de samme opgaver – opgaver, som han mente var så enkle og ligetil, at selv en robot kunne udføre dem. Derfor udviklede han et script, der automatisk testede browserfunktionalitet for ham. Det blev en øjeblikkelig succes og blev hurtigt branchestandarden.
Selv de QA-fagfolk, der er skeptiske over for automatiseret testning, ved, at den i mange tilfælde tjener et formål.
Hvorfor manuel testning aldrig vil dø
Vi har gennemgået de gode, de dårlige og de meget dårlige aspekter af AT. Vi ved, i hvilke situationer det fungerer godt, og hvor det får samlebånd til at kaste bildæk rundt på fabrikken. Lad os et øjeblik se på manuel testning, og hvorfor den stadig er så vigtig for QA-testere.
Automatiseret testning kræver overvågning
Som nævnt ovenfor i forbindelse med Musks Model 3-problem og risikoen ved at køre automatiseret testning natten over kan tingene gå helt galt, når du overlader automatiseringsværktøjerne til sig selv.
De store fordele ved automatiseret testning opstår, når den udføres sammen med manuel testning eller under overvågning af en QA-tester. Alene af den grund kan QA-testere være rolige og vide, at AT ikke vil overtage deres roller i den nærmeste fremtid.
More Articles
Manuel testning anvender eksplorativ testning
Når en tester udfører en eksplorativ test, undersøger vedkommende softwaren uden nogen foruddefineret plan. Det er en af de mest populære former for testning inden for QA.
Eksplorativ testning kan kun udføres gennem manuel testning.
Fordelen ved eksplorativ testning er, at testeren kan tilpasse sig sine fund undervejs uden at skulle skrive et nyt testtilfælde.
Eksplorativ testning giver også mulighed for samarbejde, udvikling af teorier og samarbejde – alt sammen undervejs.
Efterhånden som den agile udviklingsteori er blevet mere fremtrædende, er eksplorativ testning også blevet det.
Automatiseret testning mangler den fleksibilitet og kreativitet, der skal til for at være agil nok til eksplorativ testning. Den fungerer bedst i et fast miljø, hvor den ved præcis, hvad den skal lede efter. Eksplorativ testning er det stik modsatte – QA-testeren instrueres i at gå hen, hvor vedkommende ønsker.
Hvad synes du?
Nogle sværger til automatiseret testning, mens andre stadig mener, at manuel testning er vejen frem. Hvordan mener du, at QA-teams kan få mest muligt ud af automatiseret testning? Synes du, at vi er klar til AI i testning?
Abonner på The CTO Club-nyhedsbrevet for at få de seneste artikler og opdateringer fra brancheeksperter.
