when stop testing
Merila za izhod v preskušanju:
»Dobro začelo je na pol narejeno« - Velja povsod, tudi preskušanje programske opreme.
Na začetku projekta preizkuševalce programske opreme pogosto vidimo zelo navdušene. Ustvarjamo testiranje dokumentov kot so testna strategija, testni načrt ali testni primeri nestrpno in navdušeno.
Potem smo prišli do testiranja programske opreme z bangom! To samo še povečujejo zanimive napake, ki jih najdemo na začetku projekta. Če jih bomo rešili, bomo to samo še povečali.
Ko najdemo veliko napak in zaključimo prvo vožnjo, preidemo na naslednjo fazo. Ko pridemo do druge vožnje, se nekako sprostimo in, kot je splošna človeška težnja dolgčas s testiranjem iste stvari v drugi vožnji.
brezplačna programska oprema za mala podjetja
Mnogi preizkuševalci menijo, da to postane monotono delo v poznejših tekih in začnite izgubljati zanimanje za preizkušanje iste programske opreme znova in znova. Ko pridemo do, morda tretje vožnje, nas začne preganjati eno vprašanje, in sicer 'Kdaj ustaviti testiranje programske opreme?'
Stavim, da ste se gotovo počutili enako in vsaj enkrat vprašali: »Kdaj ustaviti testiranje?«. Rekel bi, da je vprašanje 'Kdaj, kje in kako ustaviti testiranje?' :)
Konceptualno smo prebrali in mnogi preizkuševalci verjamejo, da ne more obstajati poseben pogoj ali enačba za odločitev 'Kdaj ustaviti testiranje?' Preden zaključimo to vprašanje, moramo upoštevati številne dejavnike.
V današnjem članku bi rad delil svoje misli o tem, kako zaključiti testiranje, ko pridemo do točke v našem ciklusu testiranja, kjer lahko rečemo, da je to testiranje dovolj. To bomo storili s pomočjo nekaj resničnih primerov v običajnem preskusnem ciklu.
Kaj se boste naučili:
- Kdaj je dovolj testiranja?
- Ustavitev, ko so odkrite vse napake: Ali je to mogoče?
- Odločitev o prenehanju testiranja: Merila za izstop
- Kaj so kriteriji dokončanja ali izstopa?
- Kaj mora biti prisotno v merilih izstopa?
- Preskušanje se lahko ustavi, kadar:
- Zaključek:
- Priporočeno branje
Kdaj je dovolj testiranja?
Kdaj lahko rečemo, da je tolikšno testiranje dovolj? Se lahko testiranje kdaj zaključi?
Da bi odgovorili na ta vprašanja, bomo morali analizirati dejavnosti testiranja od začetka do konca. Upoštevajte, da - te dejavnosti bom opredelil v smislu nestrokovnjakov - ne v modnem tehničnem smislu.
Upoštevajmo, da začnete s testiranjem novega projekta.
Začetne dejavnosti:
- Preizkusna skupina prejme zahteve.
- Skupina za testiranje začne načrtovanje in oblikovanje.
- Začetni testni dokumenti so pripravljeni in pregledani.
Testiranje # 1)
- Preizkusna skupina začne izvajanje preizkusa ko prejmejo razviti izdelek.
- Med fazo testiranja izvajajo različne scenarije, da bi zlomili programsko opremo in našli številne napake. (Tudi tu je stopnja napak višja, ker je aplikacija nova in je prvič v fazi ocenjevanja.)
- Napake razvijalci odpravijo in vrnejo nazaj preskusni skupini za ponovno testiranje.
- Preizkusna skupina ponovno preskusi napake in izvede regresijo.
- Ko je večina napak visoke resnosti odpravljena in je programska oprema videti stabilna, razvojna skupina izda naslednjo različico.
Testiranje # 2)
- Preizkusna skupina začne drugi poizkus testiranja in podobne dejavnosti se izvajajo kot potek 1.
- V tem postopku se med drugim poskusnim zagonom zajame še nekaj napak.
- Napake razvijalci odpravijo in vrnejo preskusni skupini na ponovni preizkus.
- Preskusna skupina napake ponovno preizkusi in izvede regresija .
To se lahko nadaljuje večno. Zaženite 3, zaženite 4 naprej, dokler ne najdete vseh napak v programski opremi in programska oprema ne postane brez napak.
Če želimo sestaviti diagram poteka za te dejavnosti, bo videti približno tako kot spodaj:
Iz zgornjega diagrama poteka lahko jasno sklepamo, da se lahko testiranje nadaljuje, dokler ne odkrijemo vseh napak v programski opremi.
Toda vprašanje je - ali je mogoče najti vsako napako v programski opremi? Poskusimo najti odgovor na to vprašanje za milijon dolarjev :).
Ustavitev, ko so odkrite vse napake: Ali je to mogoče?
Večina programske opreme je zapletena in ima ogromen obseg testiranja. Ni nemogoče najti vseh napak v programski opremi, vendar bo trajalo večno.
Tudi po iskanju številnih napak v programski opremi, nihče dejansko ne more zagotoviti, da programska oprema zdaj nima napak. V nobenem primeru ne moremo samozavestno trditi, da smo zaključili testiranje, odkrili vse napake v programski opremi in v njej ni več napak.
Poleg tega namen testiranja ni najti vsako napako v programski opremi. Namen testiranja programske opreme je dokazati, da programska oprema deluje, kot je bilo predvideno, tako da jo prekine ali ugotovi odstopanje med trenutnim vedenjem in pričakovanim vedenjem.
Napake v programski opremi so neomejene in zato je nepraktično preizkušati, dokler ne najdejo vseh napak, saj nikoli ne moremo vedeti, katera napaka je zadnja. Resnica je, da se za zaključek našega testiranja ne moremo zanašati na odkritje vseh napak v programski opremi.
Iskreno rečeno, testiranje je neskončno in cikli testiranja se bodo nadaljevali, dokler ne bo sprejeta odločitev, kdaj in kje se ustaviti. Zdaj je še bolj zapleteno sprejeti odločitev o prenehanju testiranja. Če 'ustavitev, ko so odkrite vse napake' ni merilo za prekinitev testiranja, na podlagi česa bi se bilo treba odločiti?
Odločitev o prenehanju testiranja: Merila za izhod
Poskusimo zdaj razumeti - Kateri so najpomembnejši dejavniki, ki jih je treba upoštevati pri zaključku preizkusnih dejavnosti? Menim, da je odločitev o prenehanju testiranja večinoma odvisna od Čas, proračun in obseg testiranja.
Najpogostejši pristop je ustaviti se, ko se izčrpata čas / proračun ali izvedejo vsi testni scenariji. Vendar bomo s tem pristopom ogrozili kakovost testiranja in to ne bo dalo dovolj zaupanja v programsko opremo; kako?
Poglejmo sprimer.
Testni scenarij:
Recimo, da preizkušate programski modul. Za kritje ste dobili določen proračun. Časovni okvir projekta je en mesec. Skupno testnih scenarijev je 200. Edini, ki preizkušate ta modul.
Scenarij št. 1)
1. teden: Napako showstopper / resnost 1 najdete 1. dan in celotno testiranje je blokirano za 3 dni. Zato ne morete izvesti nobenega od scenarijev, dokler ne odpravite napake Severnost 1. Po izgubi 3 dni je blokator razrešen in nadaljujete z izvajanjem.
Konec tedna izpolnite 20 scenarijev z nekaj pomembnejšimi najvišjimi prednostne napake .
2. teden: Začnete preizkušati programsko opremo in se bolj osredotočite na odkrivanje napak. V drugem tednu odprete še nekaj napak Severnost 1, Severnost 2 in Severnost 3, konec tedna pa lahko pokrijete 70 scenarijev.
3. teden: Do začetka 3rdteden boste odpravili vse visoko prioritetne napake, zato boste morali skupaj z izvajanjem čakajočih scenarijev znova preizkusiti vse napake, ki so pristale v preskusnem vedru. V nadaljevanju dobrega napredka pokrivate 120 scenarijev z dodatnimi napakami.
V tem času so vse visoko prioritetne napake že najdene in prijavljene. Torej, zdaj so vam na voljo le napake resnosti 3.
4. teden: Do 4. tedna morate ponovno preizkusiti večino odprtih napak in preostalih 80 scenarijev. S tem lahko do konca 4. tedna dokončate do 180 scenarijev z odpravljenimi in ponovno preizkušenimi vsemi napakami visoke in srednje prioritete.
Vnos teh informacij v tabelarni obliki:
Tedni | Opravljene testne dejavnosti | Rezultat ob koncu tedna |
---|---|---|
1. teden | • 1. dan - pokaži odkrivanje pomanjkljivosti zamaška. • Testiranje je blokirano zaradi napake resnosti 1, najdene 1. dan. • Napaka blokatorja odpravljena 4. dan. • Izvajanje testa se je nadaljevalo do konca 1. tedna. | • Odprte prednostne / kritične napake. • Izdelanih 20 scenarijev. |
2. teden | • Večji poudarek na odkrivanju napak. • Izvedba preostalih testnih scenarijev. • Ponovno testiranje odpravljenih napak. | • Odprlo se je še nekaj napak resnosti 1, resnosti 2 in resnosti 3. • Skupna pokritost 70 zajetih scenarijev. |
3. teden | • Ponovno testiranje vseh visoko prioritetnih napak. • Izvedba preostalih testnih scenarijev. • Najdene so le še napake resnosti 3. | • Odprlo se je še nekaj napak resnosti 1, resnosti 2 in resnosti 3. • Skupna pokritost 120 zajetih scenarijev. |
4. teden | • Ponovno testiranje vseh visokih in srednje prioritetnih napak. • Izvedba preostalih testnih scenarijev. | • Odprlo se je še nekaj napak Severnost 3. • Skupna pokritost 180 zajetih scenarijev. |
Bi se morali ustaviti tukaj?
Razlog, ki ste ga izčrpali Čas testiranja v celoti in poročali in odpravili večino visoko prioritetnih napak. Ali vam bo ustavitev na tej točki dala zaupanje v programsko opremo? Ne zaradi spodnjih razlogov:
- Scenariji se ne izvajajo v celoti.
- Le malo tokov niti enkrat ni preizkušenih.
- Vsi zajeti scenariji se izvedejo samo enkrat.
- Programska oprema ima še vedno napake.
- Regresija ni zajeta.
Scenarij št. 2)
1. teden: Napako Severity 1 najdete 1. dan in celotno testiranje je blokirano za 3 dni. Zato ne morete izvesti nobenega od scenarijev, dokler ne odpravite napake Severity 1. Po izgubi 3 dni je blokator razrešen in nadaljujete z izvajanjem.
Konec tedna izpolnite 20 scenarijev z nekaj več napakami. Ta teden ostaja enak scenariju 1.
2. teden: V drugem tednu odprete še nekaj napak Severnost 1, Severnost 2 in Severnost 3, vendar se osredotočite na več scenarijev za pokrivanje zaostankov od 1. tedna. Konec tedna lahko pokrijete 120 scenarijev.
ki ni ena od vrst predmetov, ki se preizkuša med testiranjem sistema?
3. teden: Do začetka 3rdteden boste rešili vse odprte napake, zato boste morali skupaj z izvajanjem čakajočih scenarijev znova preizkusiti vse napake, ki so pristale v preskusnem vedru. Še vedno dobro napredovanje na koncu število zaključenih scenarijev postane 200 z dodatnimi napakami.
Zdaj lahko poročate le o napakah Severnost 2 in Severnost 3.
Vnos teh informacij v tabelarni obliki:
Tedni | Opravljene testne dejavnosti | Rezultat ob koncu tedna |
---|---|---|
1. teden | • 1. dan - Najdite pomanjkljivost zamaška. • Testiranje je blokirano zaradi napake resnosti 1, najdene 1. dan. • Napaka blokatorja odpravljena 4. dan. • Izvajanje testa se je nadaljevalo do konca 1. tedna. | • Odprte prednostne / kritične napake. • Izdelanih 20 scenarijev. |
2. teden | • Osredotočeni smo na izvajanje več scenarijev, da bi pokrili zaostanke iz prejšnjega tedna. • Ponovno testiranje odpravljenih napak. | • Odprtih je bilo še nekaj napak resnosti 1, resnosti 2 in resnosti 3. • Skupna pokritost 120 zajetih scenarijev. |
3. teden | • Ponovno testiranje vseh visoko prioritetnih napak. • Izvedba preostalih testnih scenarijev. • Najdenih je bilo le pomanjkljivosti Severnost 3 in nekaj napak Severnost 2. | • Odprtih je bilo še nekaj napak resnosti 1, resnosti 2 in resnosti 3. • Vsi zajeti scenariji. |
Bi se morali ustaviti tukaj?
Imaš v celoti zajel vse scenarije testiranja enkrat in so odkrili nekaj večjih napak. Ali vam bo ustavitev na tej točki dala zaupanje v programsko opremo?
Ne zaradi spodnjih razlogov:
- Vsi scenariji se izvedejo samo enkrat.
- Programska oprema ima v sebi še vedno veliko večjih napak.
- Regresija ni zajeta.
Vidimo, da je zgoraj v obeh scenarijih kakovost ogrožena. Najboljši pristop bo najti točko, kjer bodo zajeti vsi dejavniki iz scenarija 1 in scenarija 2 in kakovost tudi ne bo ogrožena. Da bi to dosegli, bomo morali na začetku testiranja določiti nekatera merila.
Ta merila se imenujejo merila za dokončanje ali izstop. To je odgovor na naše vprašanje - 'Kdaj ustaviti testiranje?'.
Kaj so kriteriji dokončanja ali izstopa?
Merila za izhod se ocenijo na koncu preskusnega cikla in so opredeljena v preskusnem načrtu. Nabor pogojev ali dejavnosti, ki jih je treba izpolniti, da se preskus zaključi.
Merila za izhod določajo, koliko testiranja je dovolj in kdaj je mogoče preskusne dejavnosti razglasiti za zaključene. Pokritost in merila za dokončanje se kombinirajo, da se določijo izstopna merila za testiranje.
Kaj mora biti prisotno v merilih izstopa?
V idealnem primeru je merilo izstopa ali zaustavitve določeno s kombinacijo različnih dejavnikov in je zato edinstveno za vse projekte. To je odvisno od zahteve projekta in ga je zato treba določiti med načrtovanjem preskusov; na začetku projekta. V njem opredeljene parametre je treba čim bolj količinsko opredeliti.
Spodaj je nekaj napotkov, ki jih je treba upoštevati pri določanju izhodnih meril v primeru funkcionalnega ali sistemskega testiranja. Lahko kombinirate nekaj ali vse spodnje dejavnike, medtem ko se odločite, kje ustaviti testiranje v skladu s potrebami vašega projekta.
Preskušanje se lahko ustavi, kadar:
Zahteve:
- Doseženo je 100% kritje zahtev.
Napake:
- Doseženo je število definiranih / želenih napak.
- Vse napake ali blokatorji Show Stopper so odpravljene in v stanju odprtosti ni nobene znane napake Kritična / resnost 1.
- Vse napake visoke prioritete so prepoznane in odpravljene.
- Stopnja napak pade pod določeno sprejemljivo stopnjo.
- Zelo malo napak s srednjo prednostjo je odprtih in jih je mogoče rešiti.
- Zelo malo odprtih napak z nizko prioriteto, ki ne vplivajo na uporabo programske opreme.
- Vse napake visoke prioritete so ponovno preizkušene in zaprte, ustrezni regresijski scenariji pa uspešno izvedeni.
Testna pokritost:
- Testna pokritost mora biti dosežena v 95%.
- Stopnja uspešnosti v testnem primeru mora biti 95%. To lahko izračunamo s formulo
- (Skupno število sprejetih TC / skupno število TC) * 100.
- Vsi kritični primeri so opravljeni.
- 5% testnih primerov je lahko neuspešnih, vendar neuspešni testni primeri so nizke prioritete.
- Dosežena je popolna funkcionalna pokritost.
- Vsi glavni funkcionalni / poslovni tokovi se uspešno izvajajo z različnimi vložki in dobro delujejo.
Roki:
- Rok za projekt ali rok za zaključek preizkusa je dosežen.
Testni dokumenti:
- Vsi testni dokumenti / rezultati (primer - Povzetek poročila o preskusu ) so pripravljeni, pregledani in objavljeni.
Proračun:
- Popoln proračun za testiranje je izčrpan.
Sestanki »Pojdi / Ne pojdi«:
- ' Pojdi / ne pojdi ' srečanje je bil izveden z zainteresiranimi stranmi in sprejeta je odločitev, ali naj se projekt začne proizvajati ali ne.
Zaključek:
Naj bo na koncu zelo preprosto.
Na vprašanja odgovorite s preprostim da ali ne
Če dobite večino odgovorov z Da, to pomeni, da lahko na tem mestu prenehate s testiranjem. Če je večina odgovorov ne, to pomeni, da morate preveriti, kaj manjka pri testiranju, in to vam lahko pomaga najti uhajajočo proizvodno napako :)
- Ali so vsi testni primeri izvedeni vsaj enkrat?
- Ali je stopnja uspešnosti preizkusnega primera opredeljena?
- Ali je doseženo popolno kritje preskusov?
- Ali se vsi funkcionalni / poslovni tokovi izvajajo vsaj enkrat?
- Ali je doseženo število odločenih napak?
- Ali so vse večje prednostne napake odpravljene in zaprte?
- Ali so bile vse napake ponovno preizkušene in zaprte?
- Ali je bila opravljena regresija za vse odprte napake?
- Ste izčrpali proračun za testiranje?
- Je končni čas testiranja dosežen?
- Ali so vsi testni rezultati pregledani in objavljeni?
O avtorju: To je članek Renuke K. za goste. Ima že več kot 11 let izkušenj s testiranjem programske opreme.
Upam, da vam je bil članek v pomoč. Rad bi slišal tudi vaše misli / komentarje na to temo.
Srečno testiranje!
Priporočeno branje
- Najboljša orodja za testiranje programske opreme 2021 (QA Test Automation Tools)
- Testiranje programske opreme QA Assistant Job
- Učni načrt tečaja za preizkušanje programske opreme - podroben načrt usposabljanja za spletni tečaj
- Tečaj preizkušanja programske opreme: kateremu inštitutu za preizkušanje programske opreme naj se pridružim?
- Izbira preizkušanja programske opreme kot vaše kariere
- Preizkušanje programske opreme Tehnična vsebina Writer Freelancer Job
- Nekaj zanimivih vprašanj za preskušanje programske opreme
- Povratne informacije in pregledi tečaja za preizkušanje programske opreme