Automatisert testing har blitt så integrert i enkelte rutiner at noen testere lurer på om det vil erstatte manuell testing fullstendig.
Ikke med det første.
Da Teslas team utviklet Model 3, var én av måtene de ønsket å øke produksjonstakten på å ha et helautomatisert samlebånd. AI skulle sette sammen bilen med nesten ingen overvåking fra mennesker.
Planen mislyktes katastrofalt.
Biler krasjet inn i hverandre, dører ble boret inn i vinduer, og dekkene kom ikke ordentlig på felgene.
Hva skjedde? Jo, det viste seg at roboter ikke ser særlig godt. AI-en som hadde ansvaret for å sette sammen Model 3, klarte ikke å tilpasse seg uventede komplikasjoner eller små feiljusteringer. Hvis alt ikke var perfekt justert, gjorde den katastrofale feil.
Det samme gjelder automatisert testing innen QA. Enkelte former for testing har for mange variabler og krever at den manuelle testeren kan korrigere kursen og feilsøke underveis.
Hva er automatisert testing?
Automatisert testing betyr at en QA-tester bruker et verktøy til å gjennomføre en testtilfelle. I utviklingssyklusen vil det samme testtilfellet bli testet flere ganger.
Noen av testtilfellene som ville tatt et team med QA-testere flere timer å gå gjennom manuelt, kan utføres av et automatiseringsverktøy på noen få minutter. Flere verktøy for automatisert testing har blitt bransjestandard.
Baksiden av automatisert testing
Andre bransjer, håndverk og yrker har måttet håndtere innføringen av automatisering på sitt felt. Når det har skjedd, enten det gjelder luftfart med autopilot, teppeveving eller testing, mister arbeidstakerne på det feltet forståelsen av «hvorfor» bak arbeidet sitt.
Dette er et fenomen som QA-eksperten Jan Jaap Cannegieter la merke til at begynte å skje med testere. Hans største frykt er at hvor enkelt automatisert testing er, og det økende presset om å automatisere store deler av testprosessen, vil føre til en generasjon testere som vet hvilke handlinger de skal utføre, men som mangler forståelse for hvorfor.
Mange testere vet alt om bestemte verktøy eller programmeringsspråk, men de kan ikke fortelle meg hva de tester, eller hvorfor de tester det. Og det er en dårlig ting.
Have an account? Log In
Eksempler på dårlig automatisert testing
Mange QA-testere ser det samme potensialet i automatisert testing. Vanligvis betyr det at det finnes observerbare trender og vanlige feil som en QA-tester kan gjøre. Her er noen vanlige eksempler på dårlig automatisert testing.
Nestede automatiserte tester
Nestede automatiserte tester innebærer at flere automatiserte tester kjører oppå hverandre. Når dette skjer, blir det vanskelig å finne ut hva som har gått galt når en feil oppstår.
På kort sikt er de fleste tilfeller av automatisert testing positive. QA-testeren bruker riktig verktøy og kjører det på riktig måte.
Mange eksempler på dårlig automatisert testing blir først dårlige seks måneder senere, når automatiserte tester har blitt nestet inne i andre automatiserte tester, som igjen ligger inne i andre automatiserte tester.
UI-automatisert testing uten tilsyn
Testing av brukergrensesnittet sikrer at det ikke finnes noe en bruker kan gjøre i brukergrensesnittet som vil ødelegge programmet eller føre til feil. Når det testes manuelt, kan dette kreve mange testere og mye arbeidskraft. Det er ærlig talt ineffektivt å teste på denne måten, særlig når programmet blir større og flere funksjoner må testes.
Med automatisert testing blir prosessen raskere, men den kan fortsatt kreve full kapasitet fra en QA-testers datamaskin en hel dag. For å håndtere dette kjører QA-testere testen på slutten av dagen, lar den arbeide over natten og kommer tilbake på jobb neste morgen med resultatene klare. Det gir mening, ikke sant?
Ved første øyekast virker det som det smarte å gjøre. QA-testeren bruker datamaskinen sin til å teste andre programmer i løpet av dagen, og kjører deretter den automatiserte UI-testingen om natten.
Det er nettopp fordi det gir intuitiv mening, at dette er en vanlig feil. Mye kan gå galt når automatisert testing utføres uten tilsyn.
Hvis noe går galt tidlig, vil resten av resultatene bli feil. En hel dags testing ga ingen nyttig informasjon på grunn av en feil som enkelt kunne ha blitt oppdaget og rettet hvis noen hadde vært til stede for å kontrollere at automatiseringstesten fungerte som den skulle.
Selv om automatisert testing noen ganger kan føre til falske positive resultater, kan valg av riktige verktøy for QA-automatisering redusere slike tilfeller betydelig.
Automatisering av feil ting
Det tar tid å sette opp automatisert testing. QA må sørge for at automatiseringsverktøyene passer til prosjektet, og at QA-testerne vet hvordan de skal bruke verktøyene på riktig måte.
Alt dette krever mye tid og organisering, og hvis sluttresultatet er at en test som vanligvis kjøres én gang i måneden blir automatisert, er det ikke verdt innsatsen. Før du begynner med automatisert testing, må du sørge for at det du skal automatisere, vil spare QA-testere for en målbar mengde tid.
Du kan ikke bare automatisere oppgaver som forekommer for sjelden til at det er verdt innsatsen; noen oppgaver kan ganske enkelt ikke automatiseres på en enkel måte.
Erstatte manuell testing
Automatisert testing kan bare oppdage det den får beskjed om å lete etter. Hvis skriftene på en nettside ser merkelige ut, men testen bare kontrollerte at alle lenkene på nettstedet fungerte, løser den ett problem (lenkene), men vet ikke at det er noe galt med det andre (skriftene).
Manuell testing kan oppdage ting utenfor testens opprinnelige omfang. Metoden med utforskende testing ble utviklet for å gi QA-testeren rom til å finne uventede feil etter hvert som de oppstod, selv om det ikke var dette de opprinnelig lette etter. Når automatisert testing er begrenset til én enkelt oppgave, kan den være grundig. Det den ikke kan være, er omfattende.
Eksempler på god automatisert testing
Testautomatisering utføres for å minimere risiko. Når en QA-tester kan minimere risikoen og maksimere effektiviteten, bør automatisert testing absolutt utføres. Det er ingen grunn til at en QA-tester skal bruke flere timer på å kontrollere lenkene på et nettsted manuelt når en nettsøker kan utføre den samme aktiviteten på kortere tid og med liten sannsynlighet for å gjøre en feil.
En god tommelfingerregel for å avgjøre når automatisert testing bør brukes i stedet for manuell testing, er å spørre om testen vil være rask eller kontinuerlig. Hvis testen skal kjøres kontinuerlig, er automatisert testing veien å gå.
Mennesker er dårligere enn maskiner når det gjelder å utføre repetitive oppgaver konsekvent på et høyt nivå. Vi ønsker variasjon og kobler oss mentalt fra når vi gjør det samme for lenge. Dette gjør at feil kan slippe gjennom.
Da vil en QA-tester innse at de har: a) brukt mer tid enn de ville ha gjort ved å kjøre automatisert testing, og b) gjort en dårligere jobb og skapt flere problemer senere.
Jason Huggins, grunnleggeren av det populære automatiseringstestverktøyet Selenium, utviklet programmet fordi han oppdaget at så mange av dagene hans som tester gikk med til å utføre de samme oppgavene – oppgaver han mente var så enkle og rett frem at selv en robot kunne gjøre dem. Derfor utviklet han et skript som automatisk testet nettleserfunksjonalitet for ham. Det ble en umiddelbar suksess og ble raskt bransjestandarden.
Selv QA-fagfolk som er skeptiske til automatisert testing, vet at det i mange tilfeller har en hensikt.
Hvorfor manuell testing aldri vil dø
Vi har gått gjennom de gode, de dårlige og de svært dårlige sidene ved AT. Vi vet i hvilke situasjoner det fungerer godt, og hvor det får samlebånd til å kaste bildekk rundt i fabrikken. La oss se litt på manuell testing og hvorfor det fortsatt er så viktig for QA-testere.
Automatisert testing krever tilsyn
Som nevnt ovenfor, med Musks Model 3-problem og risikoen ved å kjøre automatisert testing over natten, kan ting gå veldig galt når du lar automatiseringsverktøyene være alene.
De store fordelene med automatisert testing oppstår når den utføres sammen med manuell testing, eller under tilsyn av en QA-tester. Bare av den grunn bør QA-testere kunne slappe av i visshet om at AT ikke kommer til å overta rollene deres i overskuelig fremtid.
More Articles
Manuell testing benytter utforskende testing
Når en tester utfører en utforskende test, utforsker vedkommende programvaren uten en forhåndsdefinert plan. Det er en av de mest populære testformene innen QA.
Utforskende testing kan bare utføres gjennom manuell testing.
Fordelen med utforskende testing er at testeren kan tilpasse seg funnene sine underveis, uten å måtte skrive et nytt testtilfelle.
Utforskende testing åpner også for samarbeid, teoriutvikling og læring underveis.
Ettersom den smidige utviklingsteorien har blitt mer fremtredende, har også utforskende testing blitt det.
Automatisert testing mangler fleksibiliteten og kreativiteten som kreves for å være smidig nok til utforskende testing. Den fungerer best i et rigid miljø der den vet nøyaktig hva den skal se etter. Utforskende testing er det stikk motsatte – QA-testeren får beskjed om å gå dit vedkommende ønsker.
Hva synes du?
Noen sverger til automatisert testing, mens andre fortsatt mener at manuell testing er veien å gå. Hvordan mener du QA-team kan få mest mulig ut av automatisert testing? Synes du vi er klare for KI i testing?
Abonner på nyhetsbrevet til The CTO Club for å få de nyeste artiklene og oppdateringene fra bransjeeksperter.
