Meny

Exploratory Testing vs Scripted Testing: Who Wins?

exploratory testing vs scripted testing

Prøv Instrumentet Vårt For Å Eliminere Problemer

Virkelige fordeler ved utforskende testing:

Tradisjonelt har programvaretesting vært en veldig stiv aktivitet, men de siste årene har det vært et skifte fra skriptbasert testing. Utforskende testing , som er mer kontekstdrevet, har kommet frem. Det er fordi det gir testere mer frihet til å utnytte ferdighetene og kunnskapene, og det gjør dem ansvarlige for å optimalisere verdien av eget arbeid.

Exploratory Testing vs Scripted Testing

Ikke alle selges på verdien av utforskende testing. Den opplevde mangelen på formalitet og vekt på personlig ansvar kan få alarmklokkene til å ringe. Men den bekymringen er i stor grad basert på en feiltolkning av utforskende testing. Det handler ikke om å kaste regler ut av vinduet og teste tilfeldig, det er faktisk veldig strukturert og systematisk. Og det er også veldig effektivt.

Skeptikere vil ha konkret bevis på at det gjør mer enn å forbedre testernes moral. Derfor bestemte vi oss for å gjennomføre en studie som ville sette sammenhengsbasert, utforskende testing direkte mot en manusbasert testtilnærming. Resultatene var veldig interessante, som du er i ferd med å finne ut av.

Hva du vil lære:

hvordan man skriver testsaker i manuell testing

Kontekstbasert (Exploratory Testing) vs Scripted Testing Teams

To lag, to tilnærminger:

Vi startet med å dele testerne i to lag på tre. Testere i hvert team hadde samme sammenlignbare applikasjonskunnskap. De samme definisjonene for defekt alvorlighetsgrad (major, minor) ble etablert for begge lag. Begge lagene fikk den samme applikasjonsbygningen levert til seg. Det ene teamet (“skriptet”) vil bruke en tradisjonell manusbasert testtilnærming, og det andre teamet (“utforskende”) vil bruke en kontekstdrevet testtilnærming. Testaktivitetene vil bli delt inn i to faser på tre dager hver.

Det manusbaserte teamet identifiserte fem forretningsstrømmer for å teste og genererte 15 testsaker. Testtilfellene var begrenset, så testere hadde ikke frihet til å utforske utenfor rammen av skriptet.

Det utforskende teamet opprettet to visuelle tankekart , en som identifiserte testdekning og testcharter, og den andre som dekker produktkomponenter / moduler. Prosessen produserte totalt 24 testcharter. De definerte charterene var på høyt nivå og tillot kontekstuell tolkning, og utvidet omfanget av testøkten for testerne.

Fase 1:

Det skriptede teamet klarte å fullføre 6 testsaker i løpet av de tre tildelte dagene. De rapporterte om 6 store mangler på den tiden.

Det undersøkende teamet klarte å gjennomføre 13 testøkter fra 30 minutter til 180 minutter hver. De rapporterte om 10 større feil og 5 mindre feil.

skript vs utforskende testing 1

Interessant rapporterte det utforskende teamet alle manglene som skriptlaget hadde rapportert.

Fase 2:

Skriptlaget klarte å fullføre 9 prøvesaker denne gangen. De rapporterte 10 store feil og 8 mindre feil .

Utforskerteamet fullførte 18 økter. De rapporterte 14 store mangler og 5 mindre feil.

skript vs utforskende testing 2

I fase 2 rapporterte det skriptede teamet to større og en mindre mangel som det undersøkende teamet ikke fant, men det undersøkende teamet rapporterte om 3 større og en mindre mangel som det skriptede teamet ikke rapporterte.

Dette tar ikke hensyn til de relative kompleksitetene i arbeidsflytene som testerne har valgt i løpet av disse øktene og testtilfellene, men vi kan likevel trekke noen interessante konklusjoner.

Hva betyr det?

Det ser ut til at en utforskende tilnærming, og ansvaret og fleksibiliteten den gir, resulterer i en mer effektiv form for testing. Det kan være mulig å dekke mer grunn ved å utvikle og tilpasse testcharterene dine etter hvert som testøktene utvikler seg, basert på hva som er fornuftig i sammenheng. Denne friheten mangler i manusbasert testing, og det kan forhindre oppdagelse av feil.

implementeringsfase i livssyklus for programvareutvikling

Å holde seg stift til skript skaper godt slitte stier, og det er bare ved å avvike fra de stiene vi skal avdekke alle feilene. Som nevnt flere ganger av tanke-ledere innen testmiljøet, “Hvis du forestiller deg et produkt som et felt av landminer og hver landmin er en defekt, så er det ganske klart at det å gå den samme veien om og om igjen ikke er måten å finne dem på alle.'

Til slutt var ingen av tilnærmingene perfekte, fordi hvert lag rapporterte feil som det andre laget ikke identifiserte, selv om det utforskende teamet rapporterte mer totalt sett.

Realistisk kan dette bety at den riktige tilnærmingen, med hensyn til å komme så nær som mulig 'minimale' feil, vil være en blanding av de to. Men det er mange fordeler med kontekstdrevet tilnærming som snakker til fordel for den. Det krever mindre forberedelsestid, mindre dokumentasjon, identifiserer problemer tidligere, og utfordrer testere til å bruke analytiske ferdigheter og deduktivt resonnement. De får en dypere og grundigere forståelse av produktet og fungerer virkelig som talsmenn for sluttbrukeren.

Konklusjon

Sluttresultatet viser at utforskende testing fører til rapportering av flere feil før live-live, noe som resulterer i et bedre produkt levert av teamet, og til slutt mer fornøyde / oppfylte testere som alle er ønskelige resultater, uansett hvordan du ser på det.

om forfatteren

Mush Honda er QA Director hos KMS-teknologi , en leverandør av IT-tjenester på tvers av livssyklusen for programvareutvikling med kontorer i Atlanta, GA og Ho Chi Minh-byen, Vietnam. Han var tidligere tester hos Ernst & Young, Nexidia, Colibrium Partners og Connecture. KMS-tjenester inkluderer applikasjonsadministrasjon, testing, support, profesjonelle tjenester og personalforstørrelse.

Er du enig? Legg gjerne ut kommentarene dine, spørsmålene nedenfor.

PREV Opplæring | NESTE veiledning nr.4: Utforskende testing med HP Sprinter

Anbefalt lesing

^