Meni

Ad-hoc testiranje: Kako pronaći nedostatke bez formalnog postupka ispitivanja

ad hoc testing how find defects without formal testing process

Isprobajte Naš Instrument Za Uklanjanje Problema

Sam pojam ad-hoc podrazumijeva nedostatak strukture ili nešto što nije metodično. Kad govoriš o ad-hoc testiranje , to znači da je to oblik a Crna kutija ili testiranje ponašanja provedeno bez ikakvog formalnog postupka.

Formalni postupak ovdje znači posjedovanje dokumentacije kao što su dokumenti sa zahtjevima, planovi ispitivanja, slučajevi ispitivanja i pravilno planiranje ispitivanja u smislu rasporeda i redoslijeda izvedenih testova. Također, sve radnje izvršene tijekom testiranja obično nisu dokumentirane.

Ad-hoc testiranje

To se uglavnom radi s ciljem pokušaja otkrivanja nedostataka ili nedostataka koji se ne mogu otkriti tradicionalnim ili formalnim postupcima koji se slijede tijekom ciklusa ispitivanja.

Kao što smo već shvatili, suština ovog testiranja leži u nepostojanju formalnog ili strukturiranog načina testiranja. Kad se izvode takve vrste tehnika slučajnog testiranja, očito je da testeri to izvode bez ikakvog posebnog slučaja upotrebe s ciljem da razbiju sustav.

Stoga je definitivno još očitije što takva intuitivna ili kreativna metodologija testiranja zahtijeva ispitivač da bude izuzetno vješt, sposoban i ima dubinsku stručnost u radu sa sustavom. Ad-hoc ispitivanje osigurava da je obavljeno testiranje završeno i posebno je vrlo korisno u određivanju učinkovitosti ispitne posude.

Preporučena literatura=> Istraživačko testiranje - kako razmišljati dalje od tradicionalnih granica testiranja?

Što ćete naučiti:

Počnimo s ad-hoc primjerom testiranja

Evo primjera kako možemo izvršiti ovo testiranje kada je UI Wizard u pitanju.

Recimo da trebate izraditi plan ili predložak za neku vrstu zadatka koji će se izvesti pomoću ovog čarobnjaka za korisničko sučelje. Čarobnjak je niz okna koja imaju korisničke unose poput imena, opisa itd.

Kako čarobnjak napreduje: recimo u jedno od okna, treba unijeti korisničke podatke koji uključuju čarobnjaka korisničkog sučelja za bacanje kontekstnog skočnog okvira koji dodaje povezane podatke za dovršavanje čarobnjaka i postavljanje / aktiviranje čarobnjaka.

Da bi testirao ovog testera, vrši redovita testiranja, kao što su:

najbolji besplatni youtube downloader za pc
  • Uspješno dovršite čarobnjaka sa svim važećim podacima i izradite plan.
  • Otkažite čarobnjaka na sredini.
  • Uredite stvoreni plan putem čarobnjaka.
  • Izbrišite stvoreni plan i uvjerite se da od njega nema ostataka.
  • U čarobnjak unesite negativnu vrijednost i pogledajte odgovarajuće poruke o pogrešci.

Sada, za gornji primjer evo nekoliko slučajeva za ad-hoc testove to bi se moglo izvesti otkriti što više nedostataka:

  • Pokušavajući dodati negativne podatke, dodajte određene posebne znakove koji nisu ograničeni kako biste vidjeli je li s njima pravilno postupano. Na primjer, čarobnjaci ponekad ne ograničavaju {ili (zagrade, ali u određenim situacijama to se može sukobiti s kodom na temelju jezika na kojem je napisan i prouzročiti vrlo nepouzdano ponašanje.
  • Drugi se test odnosi posebno na skočne prozore. Korisnik može uzrokovati pokretanje skočnog prozora, a zatim pokušati pritisnuti tipku za povratak na tipkovnici. Mnogo sam puta primijetio da čineći to, čarobnjak za pozadinu potpuno nestaje i gube se cjelokupni korisnički podaci koji su uneseni do trenutka pokretanja skočnog prozora!

Karakteristike ad-hoc testiranja:

Ako primijetite gornje scenarije, vidjet ćete nešto vrlo različito obilježje ove vrste testiranja.

Oni su:

  • Uvijek su u skladu s testnim ciljem. Međutim, to su određeni drastični testovi izvedeni s namjerom da razbiju sustav.
  • Ispitivač mora imati potpuno znanje i svijest o sustavu koji se ispituje. Rezultat ovog testiranja pronalazi programske pogreške koje pokušavaju istaknuti rupe u procesu testiranja.
  • Također, gledajući gornja dva testa, prirodna reakcija na njih bila bi takva - ova vrsta testa može se izvesti samo jednom jer ponovni test nije izvediv ako nema pridruženih kvarova.

Kada radimo ad-hoc testiranje?

Pitanje od milijun dolara doista!

Većina vremenskih testnih timova uvijek je opterećena previše značajkama za testiranje u ograničenim vremenskim rokovima. U tom ograničenom vremenskom rasponu postoji mnoštvo ispitivanja izvedenih iz formalnog postupka koji također mora biti dovršen. U takvim situacijama ad-hoc testiranje je put do testiranja tanak.

Međutim, prema mom iskustvu, jedan krug ad-hoc testiranja može učiniti čuda za kvalitetu proizvoda i pokrenuti mnoga dizajnerska pitanja.

Budući da je ad-hoc testiranje više tehnika testiranja 'divljeg djeteta' koja ne mora biti strukturirana, općenita je preporuka da se to mora provesti nakon što se izvrši izvršavanje trenutnog segmenta testa. Drugo je stajalište da bi se to moglo učiniti kad se detaljna ispitivanja ne mogu izvršiti zbog manje vremena.

Po mom mišljenju, rekao bih to ad-hoc testiranje može se obaviti gotovo u bilo kojem trenutku - na početku, prema sredini i prema kraju! Jednostavno pronalazi svoje mjesto u bilo kojem trenutku. Međutim, kada se moraju provesti ad-hoc testiranja kako bi se postigla maksimalna vrijednost, najbolje je procijeniti iskusni ispitivač koji ima dubinsko znanje o sustavu koji se ispituje.

Kada ne izvršiti?

Ako je prethodno pitanje vrijedilo milijun dolara, ovo bi trebalo vrijediti milijardu!

Iako smo ustanovili koliko učinkovito i plodno može biti ad-hoc testiranje, kao vješt i sposoban ispitivač također moramo dešifrirati kada ne treba ulagati u ovu vrstu testiranja. Iako to odlučuje ispitivač, evo neke preporuke / primjeri kada to možda nije potrebno.

  • Izbjegavajte ovo ispitivanje kada postoji testni slučaj za koji postoji nedostatak. U takvoj je situaciji potrebno dokumentirati točku otkaza testnog slučaja, a zatim provjeriti / ponovno testirati kvar kad je otklonjen. Stoga ovdje neće biti primjenjivo.
  • Mogu postojati i određeni scenariji u koje se mogu pozvati kupci ili klijenti testirajte beta verziju softvera . U takvim se slučajevima ovo ispitivanje ne bi trebalo provoditi.
  • Drugi je scenarij kada se doda vrlo jednostavan zaslon korisničkog sučelja. Ovdje bi trebala biti dovoljna tradicionalna pozitivna i negativna ispitivanja kako bi se otkrile maksimalne greške.

Vrste ad-hoc testiranja

Ad-hoc testiranje može se podijeliti u tri kategorije u nastavku:

# 1) Baddy testiranje

U ovom obliku testiranja bit će član testnog člana i razvojni član koji će biti izabrani za rad na istom modulu. Odmah nakon programer dovršava jedinično testiranje , ispitivač i programer sjede zajedno i rad na modulu. Ova vrsta testiranja omogućuje gledanje značajke u širem opsegu za obje strane.

Razvojni programer dobit će perspektivu svih različitih testova koje ispitivač izvodi, a ispitivač će dobiti perspektivu kako je svojstveni dizajn koji će mu pomoći da izbjegne dizajniranje nevaljanih scenarija, čime će spriječiti nevaljane nedostatke. Pomoći će jednima da misle kao i drugima.

# 2) Ispitivanje parova

U ovom testiranju dva testera rade zajedno na modulu s istim postavkama testa koje se međusobno dijele. Ideja koja stoji iza ovog oblika testiranja da dva testera razmisle o idejama i metodama koje imaju brojne nedostatke. Oboje mogu podijeliti posao ispitivanja i izraditi potrebnu dokumentaciju svih izvršenih zapažanja.

# 3) Ispitivanje majmuna

Ovo se ispitivanje uglavnom provodi na razini jediničnog ispitivanja. Ispitivač analizira podatke ili testove na potpuno slučajan način kako bi osigurao da sustav može podnijeti bilo kakve padove. Ovo se ispitivanje može dalje klasificirati u dvije kategorije:

koji je moj internetski sigurnosni ključ

Prednosti ad-hoc testiranja

Testiranje jamči testeru s puno snage da bude kreativan koliko je potrebno.

To povećava kvalitetu i učinkovitost ispitivanja kako je navedeno u nastavku:

  • Najveća prednost koja se ističe je da ispitivač može pronaći broj nedostataka nego u tradicionalnom ispitivanju zbog različitih inovativnih metoda koje mogu primijeniti za testiranje softvera.
  • Ovaj oblik testiranja može se primijeniti bilo gdje u SDLC-u; nije ograničen samo na ispitni tim. Programeri također mogu provesti ovo testiranje, što bi im pomoglo da bolje kodiraju, a također mogu predvidjeti koji bi se problemi mogli pojaviti.
  • Može se povezati s drugim testiranjem kako bi se dobili najbolji rezultati koji ponekad mogu skratiti vrijeme potrebno za redovno testiranje. To bi omogućilo generiranje kvalitetnijih testnih slučajeva i bolju kvalitetu proizvoda u cjelini.
  • Ne zahtijeva izradu bilo kakve dokumentacije koja sprečava dodatno opterećenje testera. Tester se može usredotočiti na stvarno razumijevanje temeljne arhitekture.
  • U slučajevima kada nema dovoljno vremena za testiranje, to se može pokazati vrlo vrijednim u smislu pokrivenosti i kvalitete ispitivanja.

Ad-hoc testiranje nedostataka

Ad-hoc testiranje također ima nekoliko nedostataka. Pogledajmo neke od nedostaci koji su izraženi:

Budući da nije previše organiziran i nema propisane dokumentacije, najočitiji je problem što se ispitivač mora sjetiti i prisjetiti svih detalja ad-hoc scenarija u memoriji. To može biti još izazovnije, posebno u scenarijima u kojima postoji puno interakcija između različitih komponenata.

  • Slijedom prve točke, to bi rezultiralo i nemogućnošću ponovnog stvaranja nedostataka u sljedećim pokušajima ako se zatraže informacije.
  • Još jedno vrlo važno pitanje koje ovo izlazi na vidjelo je odgovornost za napore. Budući da ovo nije planirano / strukturirano, ne postoji način da se uzme u obzir vrijeme i trud uloženi u ovu vrstu testiranja.
  • Ad-hoc testiranje mora provoditi samo vrlo upućen i vješt ispitivač u timu, jer zahtijeva proaktivnost i intuiciju u smislu predviđanja potencijalnih područja s nedostacima.

Najbolji postupci kako bi ovo testiranje bilo učinkovitije

Opširno smo razgovarali o prednostima i nedostacima povezanim s ovim ispitivanjem.

U idealnom slučaju, ad-hoc testiranje trebalo bi naći svoje mjesto u SDLC-u, međutim, ako mu se ne pristupi na odgovarajući način, može se pokazati skupim i gubljenjem dragocjenog vremena za testiranje. Tako je u nastavku dato nekoliko uputa kako bi ad-hoc testiranje bilo učinkovito:

# 1) Prepoznajte područja sklona oštećenjima:

Kad dobro uspijete testirati određeni softver, složit ćete se da će postojati određene značajke koje su sklonije pogreškama od ostalih. Ako ste novi u sustavu, provjerite značajke v / s nedostataka otvorenih protiv njih.

Broj nedostataka u određenoj značajki pokazat će vam da je osjetljiv i trebali biste precizno odabrati upravo to područje za provođenje ad-hoc testiranja. To se pokazalo vrlo vremenski učinkovitim načinom otkrivanja nekih ozbiljnih nedostataka.

# 2) Stvaranje stručnosti:

Nesumnjivo je da je ispitivač koji ima više iskustva intuitivniji i može pogoditi gdje bi mogle biti pogreške u usporedbi s nekim tko nema puno iskustva. Rekao bih, iskusan ili ne, na pojedincu je da odluči i izgradi stručnost na sustavu koji se ispituje.

Da, iskusni testeri imaju prednost jer im vještine izgrađene tijekom godina dobro dođu, ali novi testeri to bi trebali koristiti kao platformu za stjecanje što više znanja za osmišljavanje boljih ad-hoc scenarija.

# 3) Stvorite kategorije za testiranje:

Kad ste svjesni popisa značajki koje treba testirati, odvojite nekoliko minuta da odlučite kako ćete te značajke kategorizirati i testirati. Na primjer, trebali biste odlučiti testirati značajke koje su najvidljivije i koje korisnik najčešće koristi prije bilo čega drugog, jer bi se činile presudnima za uspjeh softvera.

Tada biste ih mogli kategorizirati prema funkcionalnosti / prioritetu i testirati ih segment po segment.

Sljedeći je primjer gdje je ovo osobito važno ako postoji integracija između komponenata ili modula. U tim slučajevima može se dogoditi puno abnormalnosti. Korištenje kategorizacije pomoglo bi dotaknuti ovu vrstu testa barem jednom ili dva puta.

# 4) Imajte okvirni plan:

Da, da, ova bi vas točka mogla malo zbuniti jer smo ad-hoc testiranje opisali kao testiranje koje ne bi trebalo imati planiranje ili dokumentaciju. Ideja je ovdje držati se suštine ad-hoc testiranja, ali ipak neka se zabilježe neka gruba uputstva o tome kako planirate testirati.

Vrlo osnovni primjer je da se ponekad možda jednostavno nećete moći sjetiti svih testova koje namjeravate provesti. Dakle, njihovo bilježenje osiguralo bi vam da ništa ne propustite.

# 5) Alati:

Uzmimo primjer s kojim se vrlo često susrećemo svi. Puno puta ako primijetite, testiranje funkcionalnosti samo po sebi je uspješno, a u njegovom ponašanju nije zabilježeno odstupanje. Međutim, zapisnici iza kulisa mogu izvještavati o nekim izuzecima koje bi testeri mogli propustiti jer to ni na koji način ne ometa cilj ispitivanja.

Oni bi mogli biti čak i ozbiljni. Stoga nam je vrlo važno naučiti i alate koji će to odmah pomoći utvrditi.

# 6) Dokument za više nedostataka:

Opet, razumijem da bi ovo moglo opet podići neke obrve. Dokumentacija ne mora biti detaljna, već samo mala napomena za vlastitu referencu svih različitih obuhvaćenih scenarija, odstupanja u koracima i evidentiranje tih nedostataka za određenu kategoriju testnih značajki.

To će vam pomoći poboljšati cjelokupni skup testova, pri čemu biste mogli odlučiti kako improvizirati postojeće test slučajeve ili dodati više ako je potrebno.

Zaključak

Detaljno smo raspravljali o ad-hoc tehnikama testiranja - njegovim snagama, slabostima, situacijama u kojima bi to moglo i ne bi bilo korisno.

Ovo je jedna tehnika testiranja koja jamči maksimalno udovoljavanje i zadovoljavanje kreativnosti testera. U cijeloj mojoj testna karijera , Najveće zadovoljstvo stječem iz ad-hoc testiranja, jer nema ograničenja za inovacije, a vi ste na kraju samo upućeniji.

Kad smo to već rekli, glavna stvar koju bismo trebali uzeti iz svih gore navedenih informacija bila bi odrediti kako iskoristiti ad hoc snage testiranja i učiniti da to doda vrijednost cjelokupnom procesu ispitivanja i kvaliteti proizvoda.

O autoru: Ovo je gostujući članak Snehe Nadig. Radi kao voditeljica testiranja s više od 7 godina iskustva u projektima ručnog i automatiziranog ispitivanja.

Provodite li ad-hoc testiranje na svom projektu? Koji su vaši prijedlozi za uspješno ad-hoc testiranje?

Preporučena literatura

^