Meni

Ad-hoc testiranje: Kako najti napake brez formalnega postopka testiranja

ad hoc testing how find defects without formal testing process

Preizkusite Naš Instrument Za Odpravo Težav

Sam izraz ad-hoc pomeni pomanjkanje strukture ali kaj takega, kar ni metodično. Ko govoriš o ad-hoc testiranje , to pomeni, da gre za obliko a Črna škatla ali vedenjsko testiranje, izvedeno brez kakršnega koli formalnega postopka.

Formalni postopek tukaj pomeni, da imamo dokumentacijo, kot so dokumenti o zahtevah, testni načrti, testni primeri in pravilno načrtovanje preskusov glede na svoj urnik in vrstni red izvedenih testov. Tudi vsa dejanja, izvedena med preskušanjem, običajno niso dokumentirana.

Ad-hoc testiranje

To se v glavnem naredi z namenom odkriti napake ali napake, ki jih ni mogoče zajeti s tradicionalnimi ali formalnimi postopki, ki se izvajajo med preskusnim ciklom.

Kot smo že razumeli, je bistvo tega testiranja neobstoj formalnega ali strukturiranega načina testiranja. Ko se izvajajo takšne tehnike naključnega testiranja, je očitno preizkuševalci to izvajajo brez kakršnega koli posebnega primera uporabe, da bi prekinili sistem.

Zato je vsekakor še bolj očitno, da takšna intuitivna ali kreativna metodologija testiranja zahteva tester naj bo izredno usposobljen, sposoben in ima poglobljeno znanje o sistemu. Ad-hoc testiranje zagotavlja, da je opravljeno testiranje popolno in je še posebej koristno pri določanju učinkovitosti testnega vedra.

Priporočeno branje=> Raziskovalno testiranje - kako razmišljati dlje od tradicionalnih mej testiranja?

Kaj se boste naučili:

Začnimo z ad hoc primerom testiranja

Tu je primer, kako lahko izvedemo to testiranje, ko gre za čarovnika za uporabniški vmesnik.

Recimo, da morate s pomočjo tega čarovnika za uporabniški vmesnik ustvariti načrt ali predlogo za nekakšno nalogo. Čarovnik je vrsta podoken, ki imajo uporabniški vnos, kot so ime, opis itd.

Ko čarovnik napreduje: recimo v eno od podoken je treba vnesti uporabniške podatke, ki vključujejo čarovnika uporabniškega vmesnika, da vrže pojavno okno s kontekstom, ki doda povezane podatke za dokončanje čarovnika in čarovnika za uvajanje / aktiviranje.

Za preizkušanje tega preizkuševalca opravlja redna testiranja, kot so:

izvedba sklada v c ++ z uporabo polja
  • Čarovnika uspešno dopolnite z vsemi veljavnimi podatki in ustvarite načrt.
  • Preklic čarovnika na sredini.
  • S čarovnikom uredite ustvarjeni načrt.
  • Izbrišite ustvarjeni načrt in se prepričajte, da na njem ni ostankov.
  • V čarovnika vnesite negativno vrednost in si oglejte ustrezna sporočila o napakah.

Zdaj pa za zgornji primer tukaj je nekaj testnih primerov za ad hoc teste ki bi jih lahko izvedli odkriti čim več napak:

  • Medtem ko poskušate dodati negativne podatke, dodajte nekatere posebne znake, ki niso omejeni, da vidite, ali se z njimi pravilno ravna. Na primer, včasih čarovniki ne omejujejo {ali (oklepajev, toda v določenih situacijah je to lahko v nasprotju s kodo, ki temelji na jeziku, v katerem je napisana, in povzroči zelo nezanesljivo vedenje.
  • Drugi test je posebej v zvezi s pojavnimi okni. Uporabnik lahko povzroči, da se pojavno okno zažene in nato poskusi pritisniti gumb za vrnitev na tipkovnico. Velikokrat sem že opazil, da s tem čarovnik za ozadje popolnoma izgine in se izgubijo vsi uporabniški podatki, ki so bili vneseni do trenutka, ko se je pojavilo pojavno okno!

Značilnosti ad-hoc testiranja:

Če opazite zgornje scenarije, boste videli nekaj zelo značilnih značilnosti te vrste preskušanja.

To so:

  • Vedno so v skladu s testnim ciljem. Vendar pa gre za nekatere drastične teste, ki so bili opravljeni z namenom, da se sistem zlomi.
  • Preizkuševalec mora imeti popolno znanje in zavedanje o sistemu, ki se preskuša. Rezultat tega testiranja najde napake, ki skušajo poudariti vrzeli v postopku testiranja.
  • Če pogledamo tudi zgornja dva testa, bi bila naravna reakcija nanjo takšna - tovrstni preskus je mogoče izvesti samo enkrat, saj ponovni test ni izvedljiv, razen če obstaja kakšna napaka.

Kdaj opravljamo priložnostna testiranja?

Zares vprašanje za milijon dolarjev!

Večina časovnih preskusnih skupin je vedno obremenjena s preveč funkcijami, da bi jih lahko testirali v omejenih rokih. V tem omejenem časovnem obdobju je veliko preizkusnih dejavnosti, ki izhajajo iz formalnega postopka, ki ga je treba tudi zaključiti. V takih situacijah je priložnostno testiranje zelo majhno.

Iz mojih izkušenj pa lahko en krog priložnostnih preizkusov naredi čudeže glede kakovosti izdelka in sproži številna vprašanja glede oblikovanja.

Ker je ad-hoc testiranje bolj tehnika preizkušanja 'divjih otrok', ki je ni treba strukturirati, je splošno priporočilo, da jo je treba izvesti po zaključku trenutne skupine testov. Drugo stališče je, da bi to lahko storili, kadar podrobnega testiranja zaradi manj časa ni mogoče izvesti.

Po mojem bi to rekel priložnostno testiranje lahko izvedemo skoraj kadar koli - na začetku, proti sredini in proti koncu! V vsakem trenutku preprosto najde svoje mesto. Kadar pa je treba izvesti ad hoc testiranje, da se doseže največja vrednost, najbolje presodi izkušen preizkuševalec, ki ima poglobljeno znanje o sistemu, ki se testira.

Kdaj ne izvršiti?

Če je bilo prejšnje vprašanje vredno milijon dolarjev, bi moralo biti vredno milijardo!

Čeprav smo ugotovili, kako učinkovito in plodno lahko je ad-hoc testiranje, moramo kot usposobljen in sposoben preizkuševalec razbrati tudi, kdaj ne bi smeli vlagati v tovrstno testiranje. Čeprav preskuševalec odloči o tem, tukaj so nekaj priporočil / primerov, kadar to morda ni potrebno.

  • Izogibajte se temu testiranju, če obstaja testni primer, za katerega obstaja napaka. V takem primeru je treba dokumentirati točko okvare testnega primera in nato preveriti / znova preizkusiti napako, ko je odpravljena. Zato tukaj ne bo uporaben.
  • Obstajajo lahko tudi določeni scenariji, v katere je mogoče povabiti stranke ali stranke preizkusite beta različico programske opreme . V takih primerih tega testiranja ne bi smeli izvajati.
  • Drug scenarij je, ko je dodan zelo preprost zaslon uporabniškega vmesnika. Tradicionalno pozitivno in negativno testiranje bi tu moralo zadoščati, da bi ugotovili največje število napak.

Vrste ad-hoc testiranja

Ad-hoc testiranje lahko spodaj razdelimo v tri kategorije:

# 1) Družabno testiranje

V tej obliki preskušanja bosta za istega modula izbrana testni član in razvojni član. Takoj po razvijalec zaključi testiranje enote , tester in razvijalec sedita skupaj in delo na modulu. Tovrstno testiranje omogoča ogled funkcije v širšem obsegu za obe strani.

Razvijalec bo pridobil perspektivo vseh različnih testov, ki jih izvaja preizkuševalec, in preizkuševalec bo dobil perspektivo, kakšna je lastna zasnova, ki mu bo pomagala, da se izogne ​​oblikovanju neveljavnih scenarijev in s tem prepreči neveljavne napake. Enemu bo pomagalo razmišljati tako, kot misli drugemu.

# 2) Testiranje parov

Pri tem testiranju dva preizkuševalca sodelujeta na modulu z enako nastavitvijo preskusa, ki si ju delita. Zamisel, ki stoji za to obliko preskušanja, da bi dva preizkuševalca zamislila ideje in metode, da bi imeli številne napake. Oba si lahko delita delo pri testiranju in pripravita potrebno dokumentacijo vseh opravljenih opažanj.

# 3) Testiranje opic

To preskušanje se v glavnem izvaja na ravni enote. Preizkuševalec razčleni podatke ali preskusi na povsem naključen način, da zagotovi, da sistem zdrži morebitne zrušitve. To preskušanje lahko nadalje razvrstimo v dve kategoriji:

najbolj priljubljena orodja za analizo velikih podatkov

Prednosti ad-hoc testiranja

Testiranje zagotavlja testerju z veliko moči, da je kreativen, kolikor je potrebno.

To poveča kakovost in učinkovitost testiranja, kot je prikazano spodaj:

  • Največja prednost, ki izstopa, je, da lahko preizkuševalnik odkrije število napak kot pri običajnem preizkušanju zaradi različnih inovativnih metod, ki jih lahko uporabijo za preizkušanje programske opreme.
  • Ta oblika testiranja se lahko uporablja kjer koli v SDLC; ni omejena samo na preskusno skupino. Razvijalci lahko izvedejo tudi to testiranje, ki jim bo pomagalo k boljšemu kodiranju in tudi napovedovanju morebitnih težav.
  • Lahko ga združite z drugim testiranjem, da dobite najboljše rezultate, ki lahko včasih skrajšajo čas, potreben za redno testiranje. To bi omogočilo ustvarjanje bolj kakovostnih testnih primerov in boljšo kakovost izdelka v celoti.
  • Ne zahteva nobene dokumentacije, ki preprečuje dodatno obremenitev preizkuševalca. Tester se lahko osredotoči na dejansko razumevanje osnovne arhitekture.
  • V primerih, ko za testiranje ni na voljo veliko časa, se to lahko izkaže za zelo dragocenega v smislu pokritosti in kakovosti preskusov.

Ad-hoc preskušanje pomanjkljivosti

Ad-hoc testiranje ima tudi nekaj pomanjkljivosti. Oglejmo si nekaj poudarjene pomanjkljivosti:

Ker ni zelo organiziran in ni zahtevane dokumentacije, je najbolj očitna težava, da si mora preizkuševalec zapomniti in si zapomniti vse podrobnosti priložnostnih scenarijev v spominu. To je lahko še bolj zahtevno, zlasti v scenarijih, kjer je med različnimi komponentami veliko interakcij.

  • Če sledimo iz prve točke, bi to tudi povzročilo, da ne bi mogli ponovno ustvariti napak v nadaljnjih poskusih, če bi jih prosili za informacije.
  • Drugo zelo pomembno vprašanje, ki ga to razkrije, je odgovornost napora. Ker to ni načrtovano / strukturirano, nikakor ne moremo upoštevati časa in truda, vloženega v tovrstno testiranje.
  • Ad-hoc testiranje mora v ekipi izvesti samo zelo dobro podkovan in usposobljen preizkuševalec, saj zahteva proaktivnost in intuicijo v smislu predvidevanja morebitnih napak, prevoženih z napakami.

Najboljše prakse za izboljšanje učinkovitosti tega testiranja

Dolgo smo razpravljali o prednostih in slabostih, povezanih s tem testiranjem.

Idealno bi bilo, da bi priložnostno testiranje našlo svoje mesto v SDLC, vendar se lahko, če se nanj ne loti na ustrezen način, izkaže za drago in izgubo dragocenega časa za testiranje. Spodaj je torej nekaj napotkov za učinkovito ad-hoc testiranje:

# 1) Prepoznajte območja, nagnjena k napakam:

Ko boste dobro preizkusili določen del programske opreme, se boste strinjali, da obstajajo nekatere funkcije, ki so bolj nagnjene k napakam kot druge. Če ste nov v sistemu, pojdite naprej in preverite lastnosti v / s napak, ki so se odprle proti njim.

Število napak v določeni funkciji vam bo pokazalo, da je občutljiva, zato morate natančno izbrati ravno to območje za izvedbo priložnostnih preskusov. To se izkaže za zelo časovno učinkovit način razkritja nekaterih resnih napak.

# 2) Gradnja strokovnega znanja:

Nedvomno je tester, ki ima več izkušenj, bolj intuitiven in lahko ugiba, kje bi lahko bile napake, v primerjavi z nekom, ki nima veliko izkušenj. Rekel bi, izkušen ali ne, od posameznika je odvisno, ali se bo odločil in gradil strokovno znanje o sistemu, ki se preskuša.

Da, izkušeni preizkuševalci imajo prednost, saj jim z leti pridobljene veščine pridejo prav, toda novi preizkuševalci bi morali to uporabiti kot platformo za pridobivanje čim več znanja za oblikovanje boljših priložnostnih scenarijev.

# 3) Ustvarite preskusne kategorije:

Ko se seznanite s seznamom funkcij, ki jih je treba preizkusiti, si vzemite nekaj minut časa, da se odločite, kako jih boste kategorizirali in preizkusili. Na primer, odločite se, da boste funkcije, ki so najbolj vidne in jih uporabnik najpogosteje uporablja, preizkusili pred vsem drugim, saj se zdijo ključne za uspeh programske opreme.

Potem bi jih lahko kategorizirali glede na funkcionalnost / prednost in jih preizkusili po segmentih.

Drug primer, pri katerem je to še posebej pomembno, je integracija komponent ali modulov. V teh primerih lahko pride do številnih nepravilnosti. Uporaba kategorizacije bi pomagala, da se vsaj enkrat ali dvakrat dotaknete te vrste testa.

# 4) Imajte grob načrt:

Da, da, ta točka bi vas lahko nekoliko zmedla, saj smo ad hoc testiranje opisali kot testiranje, ki ne bi smelo imeti načrtovanja ali dokumentacije. Ideja tukaj je, da se držimo bistva ad hoc testiranja, a vseeno naj se zapiše nekaj grobih napotkov, kako nameravate testirati.

Zelo osnovni primer je, da si včasih morda ne boste mogli zapomniti vseh testov, ki jih nameravate opraviti. Torej, če bi jih zapisali, bi zagotovili, da ne boste ničesar zamudili.

# 5) Orodja:

Vzemimo primer, s katerim se zelo pogosto srečujemo vsi. Če velikokrat opazite, je preizkušanje funkcionalnosti samo po sebi uspešno, ne da bi pri njegovem vedenju poročali o neskladju. Vendar lahko zakulisni dnevniki poročajo o nekaterih izjemah, ki bi jih preizkuševalci lahko zamudili, saj nikakor ne ovirajo cilja preskusa.

Lahko so celo resne. Zato je za nas zelo pomembno, da se učimo in orodij, ki bodo to pomagala takoj ugotoviti.

# 6) Dokument za več napak:

Spet razumem, da lahko to spet dvigne nekaj obrvi. Ni treba, da je dokumentacija podrobna, ampak le majhna opomba za lastno sklicevanje na vse različne zajete scenarije, odstopanja v korakih in beleženje teh napak za določeno kategorijo preskusnih lastnosti.

To vam bo pomagalo izboljšati celotno serijo preizkusov, pri čemer se boste lahko odločili, kako improvizirati obstoječe testne primere ali po potrebi dodati več.

Zaključek

Podrobno smo razpravljali o priložnostnih tehnikah testiranja - njegovih prednostih, slabostih in situacijah, ko bi to koristilo in ne bi bilo koristno.

To je ena preskusna tehnika, ki zagotavlja maksimalno zadovoljevanje in preizkušanje kreativnosti preizkuševalca. V mojem celotnem testna kariera , Največje zadovoljstvo dobim s priložnostnimi testiranji, saj inovacija ni omejena, na koncu pa ste le bolj razgledani.

Po vsem tem bi se bilo treba vrniti iz vseh zgornjih informacij določite, kako izkoristiti ad hoc prednosti preizkušanja in jim dodati vrednost celotnemu preskusnemu procesu in kakovosti izdelka.

O avtorju: To je gostujoči članek Snehe Nadig. Deluje kot preizkusna vodja z več kot 7-letnimi izkušnjami pri projektih ročnega testiranja in avtomatizacije.

Ali pri svojem projektu izvajate priložnostna testiranja? Kakšni so vaši predlogi za uspešno ad-hoc testiranje?

Priporočeno branje

^