Automatiseret testning er blevet så integreret i visse 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 produktionstakten på, at have en fuldt automatiseret samlebåndslinje. 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 kunne ikke sættes ordentligt på fælgene.
Hvad skete der? Det viste sig, at robotter ikke kan se særlig godt. Den AI, der havde ansvaret for at samle Model 3, var ude af stand til at tilpasse sig uventede komplikationer eller mindre 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 testcase. I udviklingscyklussen vil den samme testcase blive testet flere gange.
Nogle af de testcases, som 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 branchestandard.
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 inden for 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 voksende pres for at automatisere en stor del af testprocessen vil føre til en generation af testere, som ved, hvilke handlinger der skal udføres, 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. Det betyder typisk, 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 tests
Indlejring af automatiserede tests betyder, at flere automatiserede tests kører 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 tests er blevet indlejret i andre automatiserede tests, som igen er indlejret i andre automatiserede tests.
Automatiseret UI-testning uden overvågning
Testning af brugergrænsefladen sikrer, at der ikke er noget, en bruger kan gøre på brugergrænsefladen, som får programmet til at bryde sammen eller forårsager fejl. 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 vokser, og flere funktioner kræver testning.
Med automatiseret testning bliver processen hurtigere, men den kan stadig kræve fuld kapacitet fra en QA-testers computer i 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. Giver det mening, ikke?
På overfladen virker det som det fornuftige 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 brugergrænsefladen 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, 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-automatiseringsværktøjer reducere sådanne tilfælde betydeligt.
Automatisering af de forkerte ting
Automatiseret testning tager tid at sætte op. 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 normalt køres én gang om måneden, bliver automatiseret, er indsatsen ikke det 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.
Du kan ikke kun automatisere opgaver, der forekommer for sjældent til at være indsatsen værd; nogle opgaver kan ganske enkelt ikke automatiseres let.
Erstatning af manuel testning
Automatiseret testning kan kun opdage det, den får besked på at lede efter. Hvis skrifttyperne på en webside ser mærkelige ud, men testen kun kontrollerede, at alle links på webstedet virkede, 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 plads til at finde uventede fejl, efterhånden som de opstod, selv hvis det ikke var det, vedkommende oprindeligt ledte efter. Når automatiseret testning fokuserer på én 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 der absolut udføres automatiseret testning. 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 sandsynligvis ikke begå en fejl.
En god tommelfingerregel for at beslutte, hvornår automatiseret testning bør anvendes 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 higer efter fornyelse og kobler mentalt fra, når vi gør det samme for længe. Det gør det muligt for fejl 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 opdagede, at så mange af hans arbejdsdage som tester gik med at udføre de samme opgaver – opgaver, som han syntes 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-professionelle, der er skeptiske over for automatiseret testning, ved, at det i mange tilfælde tjener et formål.
Hvorfor manuel testning aldrig vil forsvinde
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 på, 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 lader automatiseringsværktøjer arbejde alene.
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 bør QA-testere kunne være rolige og vide, at AT ikke vil overtage deres roller i den nærmeste fremtid.
More Articles
Manuel testning bruger eksplorativ testning
Når en tester udfører en eksplorativ test, undersøger vedkommende softwaren uden en foruddefineret plan. Det er en af de mest populære former for testning inden for QA.
Eksplorativ testning kan kun udføres ved manuel testning.
Fordelen ved eksplorativ testning er, at testeren kan tilpasse sig sine fund undervejs uden behov for at skrive endnu et testtilfælde.
Eksplorativ testning giver også mulighed for samarbejde, teoriudvikling og samarbejde 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 tilstrækkeligt agil til eksplorativ testning. Den fungerer bedst i et rigidt miljø, hvor den ved præcis, hvad den skal lede efter. Eksplorativ testning er det stik modsatte - den instruerer QA-testeren i at gå hvorhen, 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? Mener du, at vi er klar til AI i testning?
Abonner på nyhedsbrevet fra The CTO Club for at få de seneste artikler og opdateringer fra brancheeksperter.