Meni

Raziskovalno preizkušanje vs preizkus po scenariju: kdo zmaga?

exploratory testing vs scripted testing

Preizkusite Naš Instrument Za Odpravo Težav

Resnične prednosti raziskovalnega testiranja:

Tradicionalno je bilo preizkušanje programske opreme zelo toga dejavnost, v zadnjih letih pa je prišlo do premika od testiranja na podlagi skript. Raziskovalno preskušanje , ki je bolj odvisen od konteksta, je prišel do izraza. To pa zato, ker preskuševalcem daje več svobode pri izkoriščanju njihovih veščin in znanja, zaradi česar so odgovorni za optimizacijo vrednosti lastnega dela.

Raziskovalno preskušanje vs testiranje po scenariju

Niso vsi prodani na vrednost raziskovalnega testiranja. Zaznana neformalnost in poudarek na osebni odgovornosti lahko sprožijo alarmne zvonove. Toda ta skrb v veliki meri temelji na napačni interpretaciji raziskovalnega testiranja. Ne gre za metanje pravil skozi okno in naključno testiranje, pravzaprav je zelo strukturirano in sistematično. In je tudi zelo učinkovit.

Skeptiki želijo konkreten dokaz, da naredi več kot le izboljšanje morale preizkuševalca. Zato smo se odločili, da bomo izvedli študijo, ki bo kontekstualno raziskovalno preizkušanje primerjala neposredno s pristopom testiranja na podlagi skript. Rezultati so bili zelo zanimivi, kar boste kmalu ugotovili.

Kaj se boste naučili:

glasbeni video posnetki YouTube brezplačno prenesete programsko opremo

Kontekstne (raziskovalno testiranje) vs skriptne preskusne skupine

Dve ekipi, dva pristopa:

Začeli smo z razdelitvijo preizkuševalcev v dve skupini po trije. Preizkuševalci v vsaki skupini so imeli enako primerljivo znanje o uporabi. Enake opredelitve za resnost napake (glavni, manjši) sta bili ustanovljeni za obe ekipi. Obe ekipi sta imeli dostavljeno enako sestavo aplikacij. Ena skupina (»scenarij«) bi uporabila tradicionalni pristop testiranja, ki temelji na skriptu, druga skupina (»raziskovalno«) pa bi sprejela pristop testiranja, ki temelji na kontekstu. Dejavnosti testiranja bi bile razdeljene v dve fazi po tri dni.

Ekipa, ki temelji na scenariju je opredelil pet poslovnih tokov dela za testiranje in ustvaril 15 testnih primerov. Preizkusni primeri so bili omejeni, zato preizkuševalci niso imeli svobode raziskovanja izven okvirov skripta.

Raziskovalna skupina ustvaril dva vizualni miselni zemljevidi , ena, ki je opredelila testno pokritost in testne listine, druga pa sestavne dele / module izdelka. S postopkom je bilo skupaj izdelanih 24 testnih listin. Določene listine so bile na visoki ravni in so omogočale kontekstualno interpretacijo, kar je razširjevalo obseg preizkusne seje za preizkuševalce.

1. faza:

Skupini scenarijev je v treh dodeljenih dneh uspelo opraviti 6 testnih primerov. Takrat so poročali o 6 večjih napakah.

Raziskovalni skupini je uspelo opraviti 13 preizkusnih sej, ki so trajale od 30 minut do 180 minut. Poročali so o 10 večjih in 5 manjših napakah.

scenarij vs raziskovalno testiranje 1

Zanimivo je, da je raziskovalna skupina poročala o vseh napakah, o katerih je poročala scenaristična skupina.

2. faza:

Skriptirano ekipo je uspelo dokončati 9 testnih primerov tokrat. Poročali so 10 večjih napak in 8 manjših napak .

Raziskovalna skupina je opravila 18 sej. Poročali so 14 večjih napak in 5 manjših napak.

skriptno in raziskovalno testiranje 2

V 2. fazi je scenaristična ekipa poročala o 2 večjih in 1 manjši napaki, ki jih raziskovalna skupina ni našla, vendar je raziskovalna skupina poročala o 3 večjih in 1 manjši napaki, ki jih skriptna ekipa ni prijavila.

Pri tem se ne upošteva relativne zapletenosti delovnih tokov, ki so jih preizkuševalci morda izbrali v teh sejah in testnih primerih, vendar lahko vseeno pripeljemo nekaj zanimivih zaključkov.

Kaj to pomeni?

Zdi se, da raziskovalni pristop ter odgovornost in prilagodljivost, ki ju ustvarja, vodijo do učinkovitejše oblike testiranja. Z razvojem in prilagajanjem testnih listin boste med napredovanjem testnih sej morda lahko pokrili več temeljev, glede na to, kaj je smiselno v kontekstu. Te svobode primanjkuje pri testiranju na podlagi skript in lahko prepreči odkrivanje napak.

testni načrt in testna razlika

Togo držanje skript ustvarja obrabljene poti in šele z odstopanjem od teh poti bomo odkrili vse napake. Kot so večkrat omenili voditelji misli v okviru preskusne skupnosti, »če si izdelek predstavljate kot polje protipehotnih min in je vsaka mina napaka, je povsem jasno, da znova in znova potepanje po isti poti ni način, kako jih najti vsi. '

Na koncu noben pristop ni bil popoln, ker je vsaka ekipa poročala o napakah, ki jih druga ekipa ni prepoznala, četudi je raziskovalna skupina na splošno poročala o več.

Realno to lahko pomeni, da bo pravi pristop, kolikor je le mogoče blizu 'minimalnim' napakam, mešanica obeh. Vendar pa ima veliko prednosti pristop, ki temelji na kontekstu ki govorijo v njegovo korist. Zahteva manj časa za pripravo, manj dokumentacije, prej prepozna težave in preizkuševalce izzove, da uporabijo analitične sposobnosti in deduktivno sklepanje. Pridobijo globlje in temeljitejše razumevanje izdelka in resnično delujejo kot zagovorniki končnega uporabnika.

Zaključek

Končni rezultat kaže, da raziskovalno testiranje vodi do poročanja o več napakah pred zagonom, kar ima za posledico boljši izdelek, ki ga dostavi ekipa, in na koncu, bolj zadovoljni / izpolnjeni preizkuševalci ki so vsi zaželeni rezultati, kakor koli že gledate.

O avtorju

Mush Honda je direktor QA pri KMS tehnologija , ponudnik IT storitev v celotnem življenjskem ciklu razvoja programske opreme s pisarnami v Atlanti, GA in Ho Chi Minh Cityju v Vietnamu. Pred tem je bil preizkuševalec v Ernst & Young, Nexidia, Colibrium Partners in Connecture. Storitve KMS vključujejo upravljanje aplikacij, testiranje, podporo, strokovne storitve in povečanje števila zaposlenih.

Ali se strinjaš? Svoje komentarje, vprašanja lahko objavite spodaj.

PREV Vadnica | NASLEDNJA Vadnica # 4: Raziskovalno testiranje s HP Sprinter

Priporočeno branje

^