Ad hoc-testning er en type softwaretestning, som udviklere og softwarevirksomheder gennemfører, når de kontrollerer softwarens aktuelle iteration. Denne form for testning giver et større niveau af indsigt i programmet og lokaliserer problemer, som konventionel testning måske ikke er i stand til at fremhæve.
Det er afgørende, at testteams har en fuldstændig forståelse af ad hoc-testprocessen, så de ved, hvordan de kan omgå udfordringerne og sikre, at teamet kan implementere denne teknik med succes.
Ved at vide præcis, hvordan ad hoc-testning fungerer, og hvilke værktøjer der kan lette gennemførelsen heraf, kan en virksomhed løbende forbedre sine egne kvalitetssikringsprocedurer. Den formelle testproces følger meget specifikke regler, hvilket kan resultere i, at teamet overser visse fejl – ad hoc-kontroller kan omgå disse blinde pletter og hurtigt teste alle softwarefunktioner.
I denne artikel ser vi nærmere på ad hoc-testning, og hvordan du kan bruge den til din fordel, når du udvikler et softwareprodukt.
Ad hoc-testning Betydning: Hvad er Ad-Hoc Testing?
Ad hoc-testning er en kvalitetssikringsproces, der undgår formelle regler og dokumentation, og som hjælper testerne med at finde fejl i deres applikation, som konventionelle metoder ikke kan identificere. Dette kræver typisk et omfattende kendskab til softwaren, før testen starter – herunder en forståelse af programmets indre funktioner. Disse ad hoc-kontroller har til formål at bryde programmet på måder, der afspejler brugerens input, og tage højde for forskellige potentielle situationer, så udviklerne kan rette op på eventuelle eksisterende problemer.
Manglen på dokumentation er central for denne teknik, som ikke indeholder nogen tjekliste eller testcases, der kan vejlede testerne i alle funktioner i en applikation. Ad hoc-testning handler udelukkende om at teste softwaren på den måde, som et team beslutter, at det er effektivt på det pågældende tidspunkt. Dette kan tage hensyn til allerede eksisterende formelle test, men kan også blot bestå i at gennemføre så mange test som muligt i den (sandsynligvis begrænsede) tid, der er afsat til denne teknik.
1. Hvornår og hvorfor skal du lave ad hoc-testning i forbindelse med softwaretestning?
Hovedårsagen til, at virksomheder udfører ad hoc-testning, er, at den kan afdække fejl, som traditionelle metoder ikke kan finde. Dette kan skyldes mange forskellige årsager, f.eks. at konventionelle testcases følger en særlig standardiseret proces, som ikke kan tage højde for en applikations særpræg.
Hver testtype kan tilbyde nye perspektiver og interessante tilgange til kvalitetssikring – dette viser også problemer med den sædvanlige teststrategi. Hvis ad hoc-testning f.eks. kan identificere et problem, som teamets testcases ikke tager højde for, tyder det på, at de kan have gavn af at omkalibrere deres testmetodologi.
Testerne kan foretage ad hoc-kontroller på et hvilket som helst tidspunkt i testprocessen. Dette tjener typisk som et supplement til traditionel (og mere formel) kvalitetssikring, og med dette i tankerne kan testerne udføre ad hoc-inspektioner, mens deres kolleger udfører mere formelle undersøgelser. Men de foretrækker måske i stedet at gemme ad hoc-kontroller til efter den formelle testproces som en opfølgning, der specifikt er rettet mod potentielle blinde pletter.
Ad hoc-testning kan også være nyttig, når tiden er særlig begrænset på grund af manglende dokumentation – det rette tidspunkt afhænger af virksomheden og dens foretrukne fremgangsmåde.
2. Når du ikke behøver at lave ad hoc-test
Hvis der ikke er tilstrækkelig tid til at udføre både ad hoc- og formel testning, er det vigtigt, at teamet prioriterer sidstnævnte, da dette sikrer en betydelig testdækning – selv om der stadig er nogle huller.
Hvis teamets formelle tests finder fejl, der skal rettes, er det generelt bedre at vente med ad hoc-kontroller, indtil udviklerne har gennemført de nødvendige ændringer. Ellers kan de resultater, de leverer, hurtigt blive forældede, især hvis testene vedrører en komponent, der allerede er fejlbehæftet.
Desuden skal ad hoc-testning finde sted før beta-testfasen.
3. Hvem er involveret i Ad-Hoc-testning?
Der er flere vigtige roller involveret i Ad-Hoc-testprocessen, herunder:
– Softwaretestere er de vigtigste teammedlemmer, der udfører ad hoc-kontroller. Hvis du anvender buddy- eller partestning, vil flere af disse testere arbejde sammen på de samme komponenter.
– Udviklerne kan uafhængigt af hinanden bruge disse kontroller før den formelle kvalitetssikringsfase til hurtigt at inspicere deres egen software, selv om dette er mindre dybtgående end dedikeret ad hoc-testning.
– Team- eller afdelingsledere godkender den overordnede teststrategi – de hjælper testerne med at afgøre, hvornår de skal begynde ad hoc-testning, og hvordan de skal udføre den uden at forstyrre andre kontroller.
Fordele ved Ad-Hoc-testning
Fordelene ved ad hoc-testning i forbindelse med softwaretestning er bl.a.:
1. Hurtige beslutninger
Da disse tests ikke kræver hyppig dokumentation før, under eller efter kontrollen, er det muligt for teamene at identificere problemer meget hurtigere. Denne enkelhed giver testerne en enorm frihed.
Hvis de f.eks. tester en komponent og ikke kan identificere nogen fejl, går teamet måske bare videre til den næste test uden at notere dette i et dokument.
2. Supplerer andre testtyper
Ingen teststrategi er perfekt, og det er normalt umuligt at opnå 100 % dækning – selv med en omfattende plan. Der vil altid være huller i konventionelle test, så det er vigtigt, at virksomhederne integrerer flere metoder.
Ad hoc-testning har specifikt til formål at finde de problemer, som formel testning ikke kan dække, hvilket garanterer en bredere samlet testdækning.
3. Fleksibel gennemførelse
Ad hoc-testning kan finde sted på et hvilket som helst tidspunkt i kvalitetssikringsprocessen før betatestning, så virksomheder og teams kan selv bestemme, hvornår det er bedst at udføre disse kontroller. De kan vælge at udføre ad hoc-test i forbindelse med konventionelle test eller vente til bagefter – uanset hvad, har teamet gavn af de valgmuligheder, de har til rådighed.
4. Større samarbejde
Udviklerne er mere involveret i denne proces end i mange andre former for testning – især hvis virksomheden anvender buddy- og pair testing.
Som følge heraf får udviklerne et bedre indblik i deres egne applikationer og kan måske rette op på fejl på en højere standard. Det er med til at forbedre softwarens overordnede kvalitet yderligere.
5. Forskellige perspektiver
Ad hoc-testning kan vise applikationen fra nye vinkler og hjælpe testerne med at engagere sig i disse funktioner på nye måder. Yderligere perspektiver er afgørende under hele afprøvningen, da formelle kontroller ofte har i det mindste mindre huller.
Hvis ad hoc-testere bruger softwaren med den specifikke hensigt at bryde den, vil de lettere kunne finde frem til programmets begrænsninger.
Udfordringer ved ad hoc-testning
Ad-hoc-testprocessen har også flere udfordringer, f.eks:
1. Vanskeligheder med rapportering
Manglen på dokumentation gør ad hoc-testning meget hurtigere, men kan også gøre det vanskeligt at rapportere om andet end større problemer.
F.eks. kan en tidligere udført kontrol blive mere relevant på et senere tidspunkt, selv om den ikke oprindeligt førte til væsentlige resultater. Uden omfattende dokumentation er holdet måske ikke i stand til at forklare disse test.
2. Mindre gentagelig
På samme måde er testerne måske ikke helt klar over den nøjagtige tilstand, der er nødvendig for at forårsage de reaktioner, de observerer. F.eks. kan en ad hoc-kontrol, der returnerer en fejl, ikke indeholde tilstrækkelige oplysninger til, at teamet kan træffe foranstaltninger. De er måske ikke klar over, hvordan de kan gentage denne test og få det samme resultat.
3. Kræver erfaring med software
Da hastighed er nøglen til ad hoc-testning, og da det normalt indebærer at forsøge at bryde programmet, er det vigtigt, at disse testere har et indgående kendskab til programmet.
Ved at vide, hvordan den fungerer, kan testerne bryde og manipulere softwaren på flere måder, men det kan øge kravene til færdighederne i forbindelse med ad hoc-testning betydeligt.
4. Begrænset ansvarlighed
Manglende dokumentation kan skabe flere problemer end blot dårlig rapportering; det kan også utilsigtet forlænge testprocessen og påvirke nytten af hurtige individuelle ad hoc-tests.
Testerne kan have svært ved at holde styr på deres fremskridt uden tilstrækkelig dokumentation i hver fase. Det kan endda føre til, at de gentager en kontrol, som andre testere allerede har udført.
5. Kan ikke afspejle brugeroplevelsen
Formålet med stort set alle testtyper er at tage højde for fejl, der påvirker slutbrugerne på en eller anden måde. Ad hoc-testning er primært baseret på, at en erfaren tester forsøger at efterligne en uerfaren bruger, og dette bør være konsekvent ved hver enkelt kontrol indtil og med deres forsøg på at ødelægge applikationen.
Karakteristika ved ad hoc-test
De vigtigste kendetegn ved vellykkede ad hoc-tests er bl.a:
1. Undersøgelse
Ad hoc-testning har som hovedprioritet at identificere fejl i applikationen ved hjælp af teknikker, som konventionelle kontroller ikke tager højde for. Ad hoc-undersøgelser gennemsøger denne software med det udtrykkelige formål at finde huller i teamets testprocedure, herunder dækningen af deres testcases.
2. Ustruktureret
Ad hoc-kontroller har normalt ingen fast plan ud over at udføre så mange test som muligt uden for de typiske rammer for formel kvalitetssikring. Testerne vil typisk gruppere kontrollerne efter komponent for at gøre det nemmere, men det er ikke nødvendigt – de kan endda udtænke kontrollerne, mens de udfører dem.
3. Erfaringsbaseret
Ad hoc-testere bruger deres eksisterende softwareerfaring til at vurdere, hvilke tests der vil give størst udbytte og afhjælpe de almindelige blinde pletter i formelle tests.
Selv om testprocessen stadig er helt ustruktureret, anvender testerne deres viden om tidligere ad hoc-kontroller, mens de beslutter deres strategi.
4. Bredt dækkende
Der findes ingen nøjagtige retningslinjer for, hvilke kontroller teamet bør udføre under ad hoc-testning, men de dækker typisk en række komponenter – muligvis med mere fokus på applikationens mere følsomme aspekter. Dette hjælper testerne med at sikre, at deres undersøgelser fuldt ud kan supplere den formelle testning.
Hvad tester vi i ad hoc-test?
Kvalitetssikringsteams tester normalt følgende under ad hoc-testning:
1. Software-kvalitet
Disse kontroller har til formål at identificere fejl i applikationen, som konventionelle test ikke kan afdække; det betyder, at processen primært tester applikationens generelle tilstand.
Jo flere fejl, der kan findes ved ad hoc-testning, jo flere forbedringer kan udviklerne gennemføre inden deadline.
2. Testcases
Ad hoc-testning implementerer generelt ikke testcases – og det er netop for at teamet kan undersøge, hvor effektive de er til at give tilstrækkelig dækning. Testcases er sandsynligvis utilstrækkelige, hvis ad hoc-kontroller kan finde fejl, som konventionelle testprocesser ikke kan finde.
3. Testpersonale
Målet kan også være at kontrollere testteamets færdigheder og viden, selv om testcases er tilstrækkelige. F.eks. kan deres metode til implementering af cases være utilstrækkelig, og ad hoc-testning kan være afgørende for at afhjælpe de resulterende huller i testdækningen.
4. Grænser for software
Ad hoc-testning søger også at forstå applikationens begrænsninger – f.eks. hvordan den reagerer på uventede input eller høj systembelastning. Testerne kan specifikt undersøge programmets fejlmeddelelser, og hvor godt programmet fungerer, når det er under stort pres.
Jeg rydder lidt op i forvirringen:
Ad hoc-testning og udforskende testning
Nogle mennesker mener, at ad hoc- og udforskende testning er synonyme, men sandheden er mere kompliceret end som så.
1. Hvad er udforskende testning?
Eksplorativ testning henviser til kvalitetssikringsprocedurer, der undersøger softwaren fra et holistisk synspunkt og specifikt kombinerer opdagelses- og testprocesserne i en enkelt metode. Dette er typisk en mellemting mellem fuldt struktureret testning og helt frie ad hoc-kontroller.
Udforskende testning fungerer bedst i specifikke scenarier, f.eks. når der er behov for hurtig feedback, eller hvis teamet skal behandle edge cases. Denne type testning opnår normalt sit fulde potentiale, når teamet bruger scriptet testning ved siden af den.
2. Forskelle mellem udforskende testning
og ad hoc-testning
Den største forskel mellem ad hoc- og udforskende testning er førstnævntes brug af dokumentation for at registrere og lette kontrollen, mens ad hoc-testning helt undgår dette. Udforskende testning lægger mere vægt på testfrihed, men aldrig på samme niveau som en ad hoc-tilgang, som er helt ustruktureret.
Udforskende testning indebærer også, at man lærer om applikationen og dens indre funktioner under disse kontroller – ad hoc-testere har i stedet ofte et omfattende kendskab til softwarens funktionalitet, før de begynder.
Typer af ad hoc-test
Der er tre hovedformer af ad hoc-testning inden for softwaretestning, herunder:
1. Abeforsøg
Monkey tests er måske den mest populære type ad hoc-testning, hvor et team tilfældigt kigger på forskellige komponenter.
Dette sker typisk under enhedstestprocessen og omfatter en række kontroller uden testcases. Testerne undersøger uafhængigt dataene på helt ustrukturerede måder, så de kan undersøge systemet i bred forstand og dets evne til at modstå intens belastning fra brugerinput.
Ved at observere resultatet af disse uscriptede teknikker kan testteamet identificere fejl, som andre enhedstests har overset på grund af mangler i konventionelle testmetoder.
2. Buddy-testning
I en ad hoc-sammenhæng bruger buddy-tests mindst to medarbejdere – typisk en tester og en udvikler – og finder primært sted efter enhedstestfasen. “Buddies” arbejder sammen på det samme modul for at finde fejl. Deres forskellige kompetencer og omfattende erfaring gør dem til et mere effektivt team, hvilket hjælper med at afhjælpe mange af de problemer, der opstår på grund af manglende dokumentation.
Udvikleren kan endda selv foreslå en række af testene, så de kan identificere de komponenter, der måske har brug for mere opmærksomhed.
3. Parvise test
Partestning ligner den, at den involverer to medarbejdere, men der er normalt tale om to separate testere, hvoraf den ene udfører de faktiske test, mens den anden tager noter.
Selv uden formel dokumentation kan holdet ved hjælp af notater uformelt holde styr på individuelle ad hoc-kontroller. Rollerne som tester og skribent kan skifte afhængig af testen, eller parret kan beholde deres tildelte roller under hele processen.
Den tester, der har mest erfaring, er typisk den, der udfører de egentlige kontroller – selv om de altid deler arbejdet med hinanden.
Manuelle eller automatiserede ad hoc-tests?
Automatiseret testning kan hjælpe teams med at spare endnu mere tid i hele kvalitetssikringsfasen, hvilket giver testerne mulighed for at få flere kontroller ind i deres tidsplan. Selv uden en bestemt struktur er det vigtigt, at testerne arbejder for at maksimere dækningen, og automatisering fremmer mere dybdegående inspektioner af denne software.
Automatiserede ad hoc-kontroller er generelt mere præcise end manuelle tests, fordi de kan undgå menneskelige fejl under rutineopgaver – dette er især nyttigt, når de samme tests udføres i forskellige iterationer. Succesen af denne procedure afhænger normalt af det automatiserede testværktøj, som teamet vælger, og dets funktionalitet.
Automatiseret testning har dog visse begrænsninger. Ad hoc-testning har f.eks. den største styrke, at den kan efterligne brugerinput og gennemføre tilfældige kontroller, efterhånden som testeren finder på dem. Disse tests kan miste deres tilfældighed, hvis organisationens testprogram har svært ved at udføre komplekse kontroller.
Den tid, det tager at automatisere disse meget specifikke opgaver, kan også begrænse den typiske tidsbesparelse ved denne proces. Det er vigtigt, at teams undersøger de tilgængelige automatiseringsværktøjer grundigt for at finde et værktøj, der passer til virksomhedens projekt.
Hvad skal du bruge for at starte Ad-Hoc-testning?
Her er de vigtigste forudsætninger for ad hoc-testning:
1. Kvalificeret personale
Da ad hoc-tests er hurtige, tilfældige inspektioner af softwarens indre funktioner, er det typisk en fordel at have testere, der har erfaring med softwaren. De bør også have et praktisk kendskab til de vigtigste testprincipper – det gør det nemt for dem at identificere de mest effektive kontroller.
2. En ustruktureret tilgang
Testerne skal være villige til at opgive deres sædvanlige strategier for ad hoc-testning; denne tankegang er lige så afgørende som selve kvalitetskontrollen. Denne metode kan kun lykkes uden struktur og dokumentation, og det er vigtigt, at testerne husker dette i alle faser.
3. Automationssoftware
Selv om ad hoc-testning er mere baseret på testning af tilfældige input og betingelser, er automatisering stadig en meget effektiv teknik i enhver sammenhæng.
Derfor bør ad hoc-kontroller stadig implementere automatiserede testværktøjer, hvor det er muligt, da den rigtige applikation kan strømline processen betydeligt.
4. Andre former for prøvning
Ad hoc-tests fungerer bedst sammen med andre kontroller, der har en mere formel tilgang, og hjælper teamet med at sikre en betydelig dækning af hele softwaren. Det er vigtigt, at testerne blander forskellige teknikker, selv om det kan være før, under eller efter ad hoc-testning.
Ad hoc-testningsproces
De sædvanlige trin, som testere bør følge, når de udfører ad hoc-testning i forbindelse med softwaretestning, er:
1. Fastlæggelse af ad hoc-testmål
Denne fase er begrænset på grund af manglen på dokumentation og struktur, men det er stadig afgørende, at teamet har et klart fokus. Testerne kan begynde at dele vage idéer om, hvilke kommende tests der skal køres, og hvilke komponenter der skal prioriteres.
2. Udvælgelse af ad hoc-testgruppen
Når teamet udtænker en række potentielle ad hoc-kontroller, finder de også ud af, hvilke testere der ville være bedst til denne type test. De vælger normalt testere, der har et indgående kendskab til applikationen, og de kan også parre dem med en udvikler.
3. Udførelse af ad hoc-test
Efter at have besluttet, hvilke testere der er de rette til denne fase, begynder disse teammedlemmer deres kontrol på et aftalt tidspunkt i testen. Deres mål er at udføre så mange ad hoc-kontroller som muligt – som testerne måske ikke finder ud af før denne fase.
4. Evaluering af testresultaterne
Når testerne har afsluttet testene (eller endda mellem de enkelte kontroller), evaluerer testerne resultaterne, men uden at dokumentere dem formelt i en testcase. Hvis de opdager problemer med ansøgningen, registrerer de dem uformelt og drøfter teamets næste skridt.
5. Indberetning af eventuelle fejl, der opdages
Når de har evalueret resultaterne, skal testerne informere udviklerne om de fejl, der er i softwaren, så de har god tid til at rette dem, inden de frigives.
Testteamet bruger også oplysningerne til at bestemme, hvordan de kan forbedre deres formelle testprocesser.
6. Om nødvendigt gentestning
Testteamet vil sandsynligvis gentage ad hoc-processen for nye iterationer af applikationen for at kontrollere, hvor godt den håndterer opdateringer. Da testerne vil have rettet mange af de tidligere identificerede huller i deres testcases, vil fremtidige ad hoc-kontroller måske kræve en anden tilgang.
Bedste praksis for ad hoc-testning
Der er visse metoder, som testteams bør anvende under ad hoc-testning, herunder:
1. Målretning af potentielle testhuller
Selv om ad hoc-testning indebærer langt mindre planlægning end andre typer testning, har teamet stadig til formål at afhjælpe mangler i kvalitetssikringen. Hvis ad hoc-testerne har mistanke om specifikke problemer med teamets testcases, bør de prioritere dette, mens de udfører deres kontrol.
2. Overvej automatiseringssoftware
Automatiseringsstrategier som f.eks. hyperautomatisering kan give mange fordele for virksomheder, der ønsker at udføre ad hoc-test.
Om dette lykkes afhænger af flere nøglefaktorer, herunder det værktøj, som virksomheden vælger, samt den generelle kompleksitet af deres ad hoc-tests.
3. Tag omfattende noter
Manglen på dokumentation i ad hoc-testning er primært med til at strømline denne proces yderligere – teamet kunne med fordel lave uformelle notater, mens de fortsætter. Dette giver testerne en klar registrering af disse kontroller og deres resultater, hvilket øger deres samlede gentagelighed.
4. Fortsæt med at forbedre testene
Ad hoc-testere finjusterer løbende deres tilgang for at tage højde for ændringer i teamets teststrategi. Når de ser på nyere versioner af virksomhedens software, kan de f.eks. justere disse kontroller som reaktion på nyere og mere omfattende formelle testcases.
7 fejl og faldgruber ved implementering af
Ad hoc-undersøgelser
Som med enhver testproces er der en lang række potentielle fejl, som teamet bør arbejde på at undgå, f.eks:
1. Uerfarne testere
For at opretholde det forventede tempo for ad hoc-testning skal teamlederen tildele testere på baggrund af deres viden og færdigheder. Mens mange former for testning kan tilpasses kvalitetssikringspersonale på begynderniveau, kræver ad hoc-kontroller teammedlemmer, der forstår softwaren fuldt ud; helst med erfaring i at udføre disse test.
2. Ufokuserede kontroller
Ad hoc-testning kan forbedre testdækningen betydeligt på grund af det hurtigere tempo – teamet behøver ikke at udfylde omfattende dokumentation før og efter hver kontrol.
Ad hoc-testerne skal dog stadig have et stærkt fokus; de kan f.eks. beslutte at prioritere visse komponenter med større risiko for fejl.
3. Ingen planlægning
Hvis man undgår enhver form for plan, kan det begrænse effektiviteten af ad hoc-testning. På trods af denne fremgangsmådes ustrukturerede karakter er det vigtigt, at teamet har en grov idé om, hvilke tests der skal køres, før de begynder.
Tiden er knap i denne proces, og det kan give mange fordele at vide, hvordan man skal gå frem, og det kan give mange fordele.
4. Overdrevent struktureret
I den modsatte ende af spektret er denne tilgang typisk baseret på manglende planlægning, da dette hjælper testerne til aktivt at undergrave testcases og finde skjulte fejl.
Ad hoc-testning er også kendt som tilfældig testning, og hvis man tvinger en struktur på den, kan det forhindre disse kontroller i at finde fejl.
5. Ingen langsigtede ændringer
Formålet med ad hoc-testning er at identificere eventuelle svagheder i teamets testcases; dette undersøger deres overordnede strategi lige så meget som selve softwaren.
Det betyder imidlertid, at ad hoc-tests generelt kun er effektive, hvis teamet bruger disse oplysninger til at forbedre deres formelle kontroller over tid.
6. Ukompatible datasæt
Stort set alle former for testning kræver en form for simulerede data for at vurdere, hvordan programmet reagerer; nogle værktøjer lader testere automatisk fylde et program med simulerede data.
Dette afspejler dog muligvis ikke, hvordan en bruger ville bruge softwaren – ad hoc-kontroller kræver datasæt, som softwaren sandsynligvis vil støde på.
7. Informationssiloer
Det er vigtigt, at testere og udviklere er i konstant kommunikation med hinanden, selv om sidstnævnte ikke er en del af ad-hoc-testprocessen.
Dette hjælper alle med at forstå, hvilke tests der er blevet udført – og viser de næste handlinger, der skal udføres, samtidig med at det forhindrer testerne i at gentage visse kontroller unødigt.
Typer af output fra ad hoc-test
Ad hoc-kontroller giver flere forskellige resultater, herunder:
1. Testresultater
De enkelte test giver forskellige resultater, der er specifikke for den nøjagtige komponent og fremgangsmåde, der er involveret – det kan tage mange former.
Det er normalt testerens ansvar at afgøre, om resultaterne udgør en fejl, selv om manglende dokumentation gør det vanskeligt at sammenligne dette med deres forventninger. Teamet sender disse resultater videre til udviklerne, hvis de opdager problemer.
2. Testprotokoller
Selve softwaren bruger et kompliceret system af interne logfiler til at overvåge brugerinput og fremhæve en række fil- eller databaseproblemer, der kan opstå.
Dette kan pege på en intern fejl, herunder den specifikke del af softwaren, der forårsager problemet. Med disse oplysninger kan ad hoc-testere og udviklere meget nemmere løse de problemer, de opdager.
3. Fejlmeddelelser
Mange ad hoc-kontroller har specifikt til formål at bryde softwaren og afsløre dens begrænsninger, hvilket betyder, at applikationens fejlmeddelelser er et af de mest almindelige resultater af disse tests.
Ved bevidst at forårsage fejlmeddelelser kan teamet vise, hvad den gennemsnitlige slutbruger ser, når de uventede handlinger, de foretager, har en negativ indvirkning på programmets funktion.
Eksempler på ad hoc-testning
Her er tre ad hoc-testscenarier, der viser, hvordan et team kan implementere den til forskellige applikationer:
1. Webapplikation til e-handel
Hvis en virksomhed ønsker at teste en e-handelsbaseret webapp, kan de bruge ad hoc-testning – specielt abetestning – for at se, hvor godt platformen håndterer uventede brugerinteraktioner.
Testerne kan forsøge at presse hver enkelt funktion til det yderste, f.eks. ved at lægge varer i kurven i urealistiske mængder eller forsøge at købe varer, der ikke er på lager. De er ikke begrænset af teamets testcases, og der er kun få begrænsninger for, hvilke kontroller de kan udføre; testerne kan endda forsøge at gennemføre køb ved hjælp af forældede URL’er.
2. Desktop-applikation
Ad hoc-testere kan også implementere disse teknikker til desktop-applikationer med et muligt fokus på forskellige maskiner, og hvor godt de hver især kan håndtere programmet.
Teamets medlemmer kan udføre disse kontroller gentagne gange for at se, hvordan ændrede hardware- eller softwareindstillinger påvirker et programs generelle ydeevne. Et bestemt grafikkort kan f.eks. have svært ved at gengive grænsefladen.
Alternativt kan disse testere blot give deres program umulige input og se, hvordan det reagerer, f.eks. om det kan vise fejlmeddelelser korrekt, som forklarer problemet tilstrækkeligt for slutbrugeren.
3. Mobilapplikation
En måde, ad hoc-testere kan undersøge en mobilapplikation på, er at teste dens sikkerhedsprotokoller – de kan f.eks. forsøge at få direkte adgang til appens udviklingsværktøjer.
Teamet kan forsøge at se, om de er i stand til at udføre uautoriserede handlinger ved at finde almindelige smuthuller og udnyttelser; de kan specifikt bede medarbejdere med erfaring inden for appsikkerhed om at lette dette.
Dette kan også involvere par-testning med udviklerne på grund af deres indsigt i appens design, så en tester kan bryde softwaren og vise præcis, hvor sikkerheden er mangelfuld.
Typer af fejl og fejl, der er opdaget
gennem ad hoc-testning
Ad hoc-kontroller kan afsløre mange problemer med et program, f.eks:
1. Fejl i funktionaliteten
Ved at bruge ad hoc-testning til at undersøge en applikations grundlæggende funktioner kan man afsløre alvorlige fejl, som påvirker slutbrugernes brug af applikationen.
For eksempel vil en abe-test af et e-handelswebsteds betalingsmuligheder illustrere de betingelser, der forhindrer transaktionen.
2. Problemer med ydeevne
Testerne kan specifikt arbejde på at skabe problemer med ydeevnen i programmet – f.eks. ved at fylde databasen med forskellige spam-input.
Dette kan manifestere sig i form af betydelig forsinkelse eller endog generel ustabilitet i softwaren, hvilket sandsynligvis vil føre til et (potentielt systemkollaps).
3. Problemer med brugervenlighed
Disse kontroller kan også afsløre fejl i grænsefladen og den generelle brugeroplevelse. Brugergrænsefladen i en mobilapp kan f.eks. se anderledes ud på et andet styresystem eller en anden skærmopløsning. En dårlig grænseflade kan føre til, at brugerne har svært ved at betjene programmet.
4. Sikkerhedsbrister
Ad-hoc-testningernes tilfældige karakter gør det muligt at dække en række almindelige og sjældne sikkerhedsproblemer; en tester kan bruge disse kontroller til at finde et programs administrative bagdøre.
Alternativt kan deres inspektion vise, at softwaren ikke har nogen datakryptering.
Almindelige ad hoc-testningsmålinger
Ad hoc-testning anvender forskellige målinger for at lette resultaterne, herunder:
1. Effektivitet af defektdetektion
Denne måling ser på, hvor effektiv testprocessen er til at finde fejl på tværs af alle former for testning, herunder ad hoc-testning. Effektiviteten af fejlopdagelse er procentdelen af fundne fejl divideret med det samlede antal problemer – hvilket viser, hvor effektive testene er.
2. Testdækningsgrad
En hjælpefunktion ved ad hoc-testning er at øge dækningen ved at kontrollere komponenter på en måde, som testcases ikke tager højde for. Det betyder, at testerne også vil stræbe efter at øge testdækningen radikalt på tværs af alle kontroller så meget som muligt.
3. Testens samlede varighed
Ad hoc-testning er meget hurtigere end andre kvalitetssikringsprocesser – og det er vigtigt, at testerne arbejder for at bevare denne fordel. Testvarighedsmålinger viser teammedlemmerne, hvordan de kan spare tid og øge fordelene ved ad hoc-strategier endnu mere.
4. Antallet af ulykker
Disse test har ofte til formål at ødelægge softwaren og forårsage et nedbrud eller en alvorlig fejl – hvilket gør det muligt at gå ud over typiske teststrategier og finde uventede problemer. Det kan derfor være nyttigt at vide, hvor ofte softwaren går ned, og hvad der forårsager disse problemer.
5 bedste værktøjer til ad hoc-testning
Der findes mange gratis og betalte testværktøjer til ad hoc-testning i forbindelse med softwaretestning – de fem bedste er som følger:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST er et omfattende program til softwaretestning, der tilbyder et højt niveau af test + RPA-funktionalitet i både gratis- og virksomhedsversionen.
Denne full-stack softwareautomatisering + RPA Suite giver mulighed for fuld testning på forskellige desktop- og mobilplatforme; softwarens 1SCRIPT-teknologi gør det også muligt for brugerne at udføre de samme kontroller gentagne gange uden besvær. Derudover udnytter værktøjet den nyeste teknologi inden for computervision, hvilket gør det muligt for ZAPTEST at udføre ad hoc-tests fra et menneskeligt perspektiv.
2. BrowserStack
BrowserStack er en cloud-platform, der kan lette testning på over 3.000 forskellige maskiner, med den ekstra funktion at automatisere Selenium-scripts. Selv om den giver en god dækning af softwareprojekter, fungerer den bedst med browser- og mobilapplikationer.
BrowserStack-testløsninger omfatter også en gratis prøveversion med 100 minutters automatiseret testning – men denne kan have begrænset brug.
Selv om den cloud-baserede tilgang kan være nyttig, påvirker den også platformens svartid negativt.
3. LambdaTest
LambdaTest anvender ligeledes cloud-baseret teknologi og lægger stor vægt på browsertest, hvilket kan begrænse effektiviteten i forbindelse med andre applikationer – selv om det stadig passer godt til iOS- og Android-programmer. Dette er en nyttig platform, når skalerbarhed er et problem, og den kan integreres med mange andre testhosting-tjenester.
Nogle brugere har dog blandede reaktioner på applikationens prisfastsættelse på tværs af de forskellige ikke-testmuligheder, der er tilgængelige, hvilket potentielt begrænser tilgængeligheden for mindre organisationer.
4. TestRail
TestRail er generelt ret tilpasningsdygtigt, da det kører udelukkende i browseren, og på trods af et stærkt fokus på effektive testcases kan det også prale af direkte ad hoc-funktionalitet. De analyser, som den giver efter hver test, kan også hjælpe teams, der aktivt undgår at lave deres egen uafhængige dokumentation, samtidig med at de stadig kan validere deres testproces.
Større suiter kan dog have svært ved at håndtere det browserbaserede format, hvilket kan begrænse tidsbesparelsen ved ad hoc-testning betydeligt.
5. Zephyr
Zephyr er en teststyringsplatform fra SmartBear, der hjælper kvalitetssikringsteams med at forbedre deres testsynlighed og samtidig integreres godt med anden software til sporing af fejl.
Denne funktion er dog begrænset til visse applikationer, hvor Confluence og Jira er de applikationer, der har mest gavn af Zephyr – disse er måske ikke de mest effektive løsninger for alle virksomheder. Der er flere skalerbare programmer til rådighed under Zephyr-brandet til forskellige priser.
Tjekliste, tips og tricks til ad hoc-testning
Her er yderligere tips til teams, som de skal tage højde for, når de udfører ad hoc-test:
1. Prioritering af følsomme komponenter
Nogle funktioner eller komponenter er naturligvis mere udsat for fejl end andre, især hvis de er vigtige for programmets overordnede funktion.
Enhver tilgang til testning bør identificere de dele af en applikation, der kan have gavn af mere grundig opmærksomhed. Dette er især nyttigt, når den samlede tid til testning er begrænset.
2. Undersøge forskellige testværktøjer
Det værktøj, som en organisation anvender til at lette sine tests, kan påvirke dækningen og pålideligheden af disse kontroller.
Med ad hoc-testning er det værd at se på så mange programmer som muligt for at finde dem, der passer til det brugerorienterede aspekt. Software, der anvender computer vision-teknologi, som ZAPTEST, kan anvende en menneskelignende strategi til ad hoc-tests.
3. Indtag en ad hoc-tankegang
Ad hoc-testning giver en enorm frihed i hele kvalitetssikringsfasen, men teamet skal forpligte sig til det for at få de vigtigste fordele ved strategien.
F.eks. bør ad hoc-testere undlade at bruge alle deres sædvanlige dokumenter ud over grundlæggende notater, og de skal inspicere softwaren fra et helt nyt perspektiv.
4. Stol på dine instinkter
Erfaring med ad hoc-testning eller generelle softwarekontroller kan hjælpe med at fremhæve almindelige fejlpunkter, og det hjælper testerne med at finde ud af, hvordan de kan opdage fejl af alle typer.
Det er vigtigt, at testerne stoler på deres instinkt og altid bruger denne viden til deres fordel – de kan ane, hvilke ad hoc-kontroller der vil være mest nyttige.
5. Fuldstændig registrering af fundne fejl
Selv om ad hoc-testning ikke har nogen formel dokumentation og for det meste er baseret på uformelle noter, er det stadig vigtigt, at teamet er i stand til at identificere og kommunikere årsagen til en softwarefejl.
De skal logge alle oplysninger, som testen giver, og som er relevante for udviklerne, f.eks. potentielle årsager til disse problemer.
6. Tag altid hensyn til brugeren
Enhver form for testning har til formål at imødekomme brugerens samlede oplevelse til en vis grad – og ad hoc-testning er ingen undtagelse. Selv om de ofte ser nærmere på applikationens indre funktioner og endda dens interne kode, bør ad hoc-testere forsøge at bryde denne software på måder, som brugerne teoretisk set kunne bryde den.
7. Forbedre processen løbende
Testteams bør finpudse deres tilgang til ad hoc-testning mellem flere iterationer af den samme software og fra et projekt til det næste.
De kan indsamle feedback fra udviklerne for at se, hvor godt deres ad hoc-tests hjalp kvalitetssikringsfasen, og om de var i stand til at øge testdækningen betydeligt.
Konklusion
Ad hoc-testning kan hjælpe organisationer af alle slags med at bekræfte deres softwareteststrategi, men den måde, de implementerer denne teknik på, kan være en væsentlig faktor for dens effektivitet.
Det er vigtigt at afbalancere de forskellige testtyper for at få mest muligt ud af ad hoc-kontroller – især da denne form for testning har til formål at supplere de andre ved at udfylde et strategisk hul.
Med en applikation som ZAPTEST er det muligt for teams at udføre ad hoc-tests med større sikkerhed og fleksibilitet, især hvis de implementerer automatisering. Uanset teamets specifikke tilgang kan deres engagement i ad hoc-testning revolutionere hele programmet eller projektet.
