Ad-hoc testiranje je vrsta testiranja softvera koju programeri i softverske tvrtke provode kada provjeravaju trenutnu iteraciju softvera. Ovaj oblik testiranja daje veću razinu uvida u program, lociranje problema koje konvencionalno testiranje možda ne bi moglo istaknuti.
Najvažnije je da timovi za testiranje potpuno razumiju proces ad hoc testiranja kako bi znali kako zaobići njegove izazove i bili sigurni da tim može uspješno implementirati ovu tehniku.
Točno poznavanje načina na koji funkcionira ad-hoc testiranje i koji alati mogu olakšati njegovu provedbu omogućuje tvrtki da kontinuirano poboljšava vlastite postupke osiguranja kvalitete. Formalni postupak testiranja slijedi vrlo specifična pravila, što bi moglo rezultirati time da tim propusti određene pogreške – ad hoc provjere mogu zaobići ove mrtve točke i brzo testirati svaku značajku softvera.
U ovom članku pomno ispitujemo ad-hoc testiranje i kako ga možete koristiti u svoju korist pri razvoju softverskog proizvoda.
Značenje ad-hoc testiranja: Što je ad-hoc testiranje?
Ad-hoc testiranje je proces osiguranja kvalitete koji izbjegava formalna pravila i dokumentaciju – pomaže ispitivačima da pronađu pogreške u svojoj aplikaciji koje konvencionalni pristupi ne mogu identificirati. To obično zahtijeva sveobuhvatno poznavanje softvera prije početka testiranja – uključujući razumijevanje unutarnjeg rada programa. Ove ad-hoc provjere imaju za cilj razbiti aplikaciju na načine koji odražavaju korisnički unos, uzimajući u obzir različite potencijalne situacije kako bi programeri mogli popraviti sve postojeće probleme.
Nedostatak dokumentacije ključan je za ovu tehniku, koja ne uključuje kontrolni popis ili testne slučajeve koji bi vodili testere kroz značajke aplikacije. Ad-hoc testiranje u potpunosti se odnosi na testiranje softvera na koji god način tim odluči da je učinkovit u tom određenom trenutku. Ovo bi moglo uzeti u obzir već postojeće formalne testove, ali bi također moglo jednostavno uključivati provođenje što je moguće više testova u (vjerojatno ograničenom) vremenu koje je dodijeljeno ovoj tehnici.
1. Kada i zašto trebate napraviti Ad-Hoc testiranje u testiranju softvera?
Glavni razlog zašto tvrtke provode ad-hoc testiranje je njegova sposobnost da otkrije pogreške koje tradicionalni pristupi ne mogu pronaći. To može biti iz raznih razloga, kao što su konvencionalni testni slučajevi nakon posebno standardiziranog procesa koji ne može objasniti idiosinkrazije aplikacije.
Svaka vrsta testiranja može ponuditi nove perspektive i zanimljive pristupe osiguranju kvalitete – to također pokazuje probleme s uobičajenom strategijom testiranja. Na primjer, ako se ad-hoc testiranjem može identificirati zabrinutost koju testni slučajevi tima ne rješavaju, to sugerira da bi mogli imati koristi od ponovne kalibracije svoje metodologije testiranja.
Testeri mogu provoditi ad-hoc provjere u bilo kojem trenutku u procesu testiranja. To obično služi kao dopuna tradicionalnom (i formalnijem) osiguranju kvalitete i, imajući to na umu, ispitivači mogu obavljati ad hoc inspekcije dok njihovi kolege provode formalnija ispitivanja. Međutim, možda će umjesto toga radije sačuvati ad hoc provjere do završetka formalnog procesa testiranja kao nastavak koji posebno cilja na potencijalne mrtve točke.
Ad-hoc testiranje također može biti korisno kada je vrijeme posebno ograničeno zbog nedostatka dokumentacije – pravo vrijeme ovisi o tvrtki i njenom preferiranom pristupu.
2. Kada ne trebate raditi Ad-Hoc testiranje
Ako nema dovoljno vremena za provođenje i ad-hoc i formalnog testiranja, važno je da tim potonjem da prioritet jer to osigurava značajnu pokrivenost testom – čak i ako još uvijek postoje neki nedostaci.
Ako službeni testovi tima pronađu greške koje je potrebno popraviti, općenito je bolje pričekati dok razvojni programeri ne dovrše potrebne izmjene kako bi se izvršile ad hoc provjere. U suprotnom, rezultati koje daju mogli bi uskoro zastarjeti, osobito ako se testovi odnose na komponentu koja već ima greške.
Osim toga, ad hoc testiranje mora se dogoditi prije faze beta testiranja.
3. Tko je uključen u ad-hoc testiranje?
Postoji nekoliko ključnih uloga uključenih u Ad-Hoc proces testiranja, uključujući:
• Testeri softvera glavni su članovi tima koji provode ad hoc provjere. Ako provodite testiranje prijatelja ili u paru, tada će nekoliko ovih ispitivača raditi zajedno na istim komponentama.
• Programeri mogu neovisno koristiti ove provjere prije formalne faze osiguranja kvalitete kako bi brzo pregledali vlastiti softver, iako je to manje dublje od namjenskog ad-hoc testiranja.
• Voditelji tima ili odjela odobravaju cjelokupnu strategiju testiranja – pomažući ispitivačima da odrede kada započeti ad-hoc testiranje i kako ga izvesti bez ometanja drugih provjera.
Prednosti ad-hoc testiranja
Prednosti ad-hoc testiranja u testiranju softvera uključuju:
1. Brza rješenja
Budući da ovi testovi ne uključuju čestu dokumentaciju prije, tijekom ili nakon provjera, moguće je da timovi puno brže identificiraju probleme. Ova jednostavnost nudi ogromnu slobodu testerima.
Na primjer, ako testiraju komponentu i ne mogu prepoznati nikakve pogreške, tim može jednostavno prijeći na sljedeći test bez da to zabilježi u dokumentu.
2. Nadopunjuje druge vrste testiranja
Nijedna strategija testiranja nije savršena, a 100% pokrivenost obično je nemoguće postići – čak i uz opsežan raspored. Uvijek će postojati praznine u konvencionalnom testiranju pa je važno da tvrtke integriraju višestruke pristupe.
Ad-hoc testiranje posebno ima za cilj pronaći probleme koje formalno testiranje ne može pokriti – jamči širu ukupnu pokrivenost testom.
3. Fleksibilna izvedba
Ad-hoc testiranje može se dogoditi u bilo kojem trenutku u procesu osiguranja kvalitete prije beta testiranja, dopuštajući tvrtkama i timovima da odluče kada je najbolje izvršiti ove provjere. Oni mogu odlučiti provesti ad-hoc testove u tandemu s konvencionalnim testiranjem ili mogu pričekati do kasnije – bez obzira na sve, tim ima koristi od izbora koji im stoje na raspolaganju.
4. Veća suradnja
Programeri su više uključeni u ovaj proces nego u mnoge druge oblike testiranja – posebno ako tvrtka koristi testiranje prijatelja i parova.
Kao rezultat toga, razvojni programeri dobivaju bolji uvid u vlastite aplikacije i možda bi mogli riješiti greške prema višim standardima. To još više pomaže u poboljšanju ukupne kvalitete softvera.
5. Različite perspektive
Ad-hoc testiranje može prikazati aplikaciju iz novih kutova, pomažući testerima da se uključe u ove značajke na nove načine. Dodatne perspektive su kritične tijekom testiranja jer formalne provjere često imaju barem manje nedostatke.
Ako ad-hoc testeri koriste softver s posebnom namjerom da ga razbiju, moći će lakše odrediti ograničenja programa.
Izazovi ad-hoc testiranja
Proces ad hoc testiranja također ima nekoliko izazova, kao što su:
1. Poteškoće s izvješćivanjem
Nedostatak dokumentacije čini ad-hoc testiranje mnogo bržim, ali također može otežati prijavu bilo čega osim velikog problema.
Na primjer, jedna prethodno provedena provjera mogla bi kasnije postati relevantnija iako u početku nije dovela do značajnih rezultata. Bez sveobuhvatne dokumentacije, tim možda neće moći objasniti ove testove.
2. Manje ponovljiv
Na sličan način, ispitivači možda nisu u potpunosti svjesni točnog stanja potrebnog za izazivanje reakcija koje promatraju. Na primjer, ad hoc provjera koja vraća pogrešku možda neće imati dovoljno informacija da bi tim mogao poduzeti radnju. Možda nisu svjesni kako ponoviti ovaj test i dobiti isti rezultat.
3. Zahtijeva iskustvo u radu sa softverom
Budući da je brzina ključna tijekom ad-hoc testiranja i obično uključuje pokušaje razbijanja aplikacije, važno je da ovi testeri dobro razumiju ovaj program.
Poznavanje načina na koji radi omogućuje testerima da razbiju i manipuliraju softverom na više načina, ali to bi moglo značajno povećati zahtjeve za vještinama za ad-hoc testiranje.
4. Ograničena odgovornost
Nedostatak dokumentacije može uzrokovati više problema nego samo loše izvješćivanje; također može nenamjerno produžiti proces testiranja, utječući na korisnost brzih pojedinačnih ad-hoc testova.
Testeri mogu imati problema s praćenjem svog napretka bez dostatne dokumentacije tijekom svake faze. To čak može dovesti do toga da ponove provjeru koju su drugi ispitivači već izvršili.
5. Možda ne odražava korisničko iskustvo
Cilj gotovo svake vrste testiranja je uzeti u obzir pogreške koje na neki način utječu na krajnje korisnike. Ad-hoc testiranje prvenstveno se oslanja na iskusnog testera koji pokušava oponašati neiskusnog korisnika i to bi trebalo biti dosljedno tijekom svake provjere do i uključujući njihove pokušaje razbijanja aplikacije.
Karakteristike ad-hoc testova
Glavne karakteristike uspješnih ad hoc testova uključuju:
1. Istražni
Glavni prioritet ad-hoc testiranja je identificirati pogreške u aplikaciji korištenjem tehnika koje konvencionalne provjere ne uzimaju u obzir. Ad-hoc ispitivanja pretražuju ovaj softver s izričitom svrhom pronalaženja rupa u postupku testiranja tima, uključujući pokrivenost njihovih testnih slučajeva.
2. Nestrukturiran
Ad hoc provjere obično nemaju postavljeni plan osim provođenja što je moguće više testova izvan tipičnih granica formalnog osiguranja kvalitete. Ispitivači će obično grupirati provjere po komponentama radi praktičnosti, ali čak ni to nije potrebno – čak bi mogli osmisliti provjere dok ih izvode.
3. Potaknuti iskustvom
Ad-hoc testeri koriste svoje prethodno iskustvo u softveru kako bi procijenili koji bi testovi dali najviše koristi i riješili uobičajene mrtve točke u formalnom testiranju.
Iako je proces testiranja još uvijek potpuno nestrukturiran, testeri primjenjuju svoje znanje prethodnih ad-hoc provjera među ostalima dok odlučuju o svojoj strategiji.
4. Širokog raspona
Ne postoje točni vodiči koje bi provjere tim trebao pokrenuti tijekom ad-hoc testiranja, ali obično pokrivaju niz komponenti – moguće s većim fokusom na osjetljivije aspekte aplikacije. To pomaže ispitivačima jamčiti da njihovi ispiti mogu u potpunosti nadopuniti formalno testiranje.
Što testiramo u ad-hoc testovima?
Timovi za osiguranje kvalitete obično testiraju sljedeće tijekom ad hoc testiranja:
1. Kvaliteta softvera
Ove provjere imaju za cilj identificirati pogreške u aplikaciji koje konvencionalno testiranje ne može otkriti; to znači da proces uglavnom testira opće zdravlje aplikacije.
Što više grešaka može locirati ad-hoc testiranje, to više poboljšanja programeri mogu implementirati prije roka.
2. Test slučajevi
Ad-hoc testiranje općenito ne provodi testne slučajeve – a to je posebno zato da tim može istražiti koliko su učinkoviti u pružanju široke pokrivenosti. Testni slučajevi vjerojatno su neadekvatni ako se ad-hoc provjerama mogu pronaći pogreške koje konvencionalni procesi testiranja ne mogu.
3. Osoblje za testiranje
Cilj također može biti provjera vještina i znanja tima za testiranje, čak i ako su testni slučajevi odgovarajući. Na primjer, njihova metodologija provedbe slučajeva može biti nedovoljna, a ad hoc testiranje može biti kritično za rješavanje rezultirajućih nedostataka u pokrivenosti testom.
4. Softverska ograničenja
Ad-hoc testiranje također nastoji razumjeti ograničenja aplikacije – poput toga kako reagira na neočekivane unose ili velika opterećenja sustava. Testeri bi mogli posebno istraživati poruke o pogreškama programa i koliko dobro ova aplikacija radi pod značajnim pritiskom.
Razjašnjavanje zabune:
Ad-hoc testiranje i eksploratorno testiranje
Neki ljudi ad-hoc i istraživačko testiranje smatraju sinonimom, iako je istina kompliciranija od ovoga.
1. Što je eksploratorno testiranje?
Eksploratorno testiranje odnosi se na postupke osiguranja kvalitete koji istražuju softver s holističkog gledišta i posebno kombiniraju procese otkrivanja i testiranja u jednu metodu. To je obično sredina između potpuno strukturiranog testiranja i potpuno slobodnih ad hoc provjera.
Eksploratorno testiranje najbolje funkcionira u određenim scenarijima, primjerice kada su potrebne brze povratne informacije ili ako se tim mora pozabaviti rubnim slučajevima. Ova vrsta testiranja obično doseže svoj puni potencijal kada tim uz nju koristi skriptirano testiranje.
2. Razlike između eksploratornog testiranja
i ad-hoc testiranje
Najveća razlika između ad-hoc i istraživačkog testiranja jest korištenje dokumentacije za snimanje i olakšavanje provjera, dok ad-hoc testiranje to u potpunosti izbjegava. Eksploratorno testiranje stavlja veći naglasak na slobodu testiranja, ali nikad na istu razinu kao ad-hoc pristup koji je potpuno nestrukturiran.
Istraživačko testiranje također uključuje učenje o aplikaciji i njenom unutarnjem radu tijekom ovih provjera – ad-hoc testeri umjesto toga često imaju sveobuhvatno znanje o funkcionalnosti softvera prije nego počnu.
Vrste ad-hoc testova
Postoje tri glavna oblika ad-hoc testiranja u testiranju softvera, uključujući:
1. Testiranje majmuna
Možda najpopularnija vrsta ad-hoc testiranja, majmunski testovi su oni koji uključuju tim koji nasumično gleda različite komponente.
To se obično događa tijekom procesa testiranja jedinice i provodi niz provjera bez ikakvih testnih slučajeva. Testeri neovisno istražuju podatke na potpuno nestrukturirane načine, dopuštajući im da ispitaju širi sustav i njegovu sposobnost da se odupre intenzivnom naprezanju korisničkih unosa.
Promatranje rezultata ovih neskriptiranih tehnika pomaže timu za testiranje identificirati pogreške koje su drugi jedinični testovi propustili zbog nedostataka u konvencionalnim metodama testiranja.
2. Buddy testiranje
U ad-hoc kontekstu, prijateljski testovi koriste najmanje dva člana osoblja – obično testera i programera – i prvenstveno se odvijaju nakon faze jediničnog testiranja . ‘Prijatelji’ rade zajedno na istom modulu kako bi odredili pogreške. Njihovi raznoliki skupovi vještina i opsežno iskustvo čine ih učinkovitijim timom, što pomaže u ublažavanju mnogih problema koji nastaju zbog nedostatka dokumentacije.
Razvojni programer može čak sam predložiti nekoliko testova, dopuštajući im da identificiraju komponente kojima bi možda trebalo posvetiti više pažnje.
3. Testiranje u paru
Testiranje u paru slično je po tome što uključuje dva člana osoblja, ali to su obično dva odvojena ispitivača, od kojih jedan provodi stvarne testove, dok drugi vodi bilješke.
Čak i bez formalne dokumentacije, vođenje bilješki može omogućiti timu da neformalno prati pojedinačne ad hoc provjere. Uloge ispitivača i pisara mogu se mijenjati ovisno o testu ili par može zadržati svoje dodijeljene uloge tijekom cijelog procesa.
Ispitivač koji ima više iskustva obično je onaj koji obavlja stvarne provjere – iako uvijek dijele posao jedan s drugim.
Ručni ili automatski ad-hoc testovi?
Automatizirano testiranje može pomoći timovima da uštede još više vremena tijekom faze osiguranja kvalitete; što testerima omogućuje da uklope više provjera u svoj raspored. Čak i bez određene strukture, bitno je da testeri rade na maksimalnom povećanju pokrivenosti, a automatizacija potiče dublje provjere ovog softvera.
Automatizirane ad-hoc provjere općenito su točnije od ručnih testova zbog njihove sposobnosti da izbjegnu ljudsku pogrešku tijekom zadataka napamet – to je posebno korisno kada se isti testovi izvode u različitim iteracijama. Uspjeh ovog postupka obično ovisi o alatu za automatsko testiranje koji tim odabere i njegovoj funkcionalnosti.
Međutim, automatizirano testiranje ima određena ograničenja. Na primjer, glavna snaga ad-hoc testiranja je njegova sposobnost oponašanja korisničkog unosa i provođenja nasumičnih provjera kako ih ispitivač smisli. Ovi bi testovi mogli izgubiti svoju slučajnost ako se program testiranja organizacije bori sa složenim provjerama.
Vrijeme potrebno za automatizaciju ovih vrlo specifičnih zadataka također može ograničiti tipičnu uštedu vremena ovog procesa. Važno je da timovi temeljito istraže dostupne alate za automatizaciju kako bi pronašli onaj koji odgovara projektu njihove tvrtke.
Što vam je potrebno za početak ad-hoc testiranja?
Ovo su glavni preduvjeti za ad-hoc testiranje:
1. Kvalificirano osoblje
Budući da su ad-hoc testovi brzi, nasumični pregledi unutarnjeg rada softvera, obično pomaže imati testere koji imaju iskustva sa softverom. Također bi trebali imati radno znanje o ključnim načelima testiranja – to im omogućuje da lako identificiraju najučinkovitije provjere.
2. Nestrukturirani pristup
Testeri moraju biti spremni napustiti svoje uobičajene strategije za ad-hoc testiranje; ovaj način razmišljanja jednako je kritičan kao i same provjere kvalitete. Ova metoda može uspjeti samo bez strukture ili dokumentacije i od ključne je važnosti da se ispitivači toga sjećaju u svakoj fazi.
3. Softver za automatizaciju
Iako se ad-hoc testiranje više oslanja na testiranje nasumičnih unosa i uvjeta, automatizacija je još uvijek vrlo učinkovita tehnika u bilo kojem kontekstu.
Zbog toga bi ad hoc provjere i dalje trebale implementirati automatizirane alate za testiranje gdje je to moguće, budući da prava aplikacija može značajno pojednostaviti proces.
4. Ostali oblici testiranja
Ad-hoc testovi najbolje funkcioniraju zajedno s drugim provjerama koje imaju formalniji pristup – pomažući timu da jamči značajnu pokrivenost u cijelom softveru. Od ključne je važnosti da ispitivači miješaju različite tehnike, iako to može biti prije, tijekom ili nakon završetka ad hoc testiranja.
Ad-Hoc proces testiranja
Uobičajeni koraci koje testeri trebaju slijediti kada provode ad-hoc testiranje u testiranju softvera su:
1. Definiranje ad-hoc ciljeva testa
Ova je faza ograničena zbog nedostatka dokumentacije i strukture, no ipak je najvažnije da tim ima jasan fokus. Testeri bi mogli početi dijeliti nejasne ideje o tome koje nadolazeće testove pokrenuti i kojim komponentama dati prioritet.
2. Odabir ad-hoc test tima
Dok tim razmišlja o brojnim potencijalnim ad-hoc provjerama, oni također otkrivaju koji bi testeri bili najbolji za ovu vrstu testiranja. Obično odabiru testere koji dobro razumiju aplikaciju i mogu ih upariti s programerom.
3. Izvršavanje ad-hoc testova
Nakon što odluče koji su testeri pravi za ovu fazu, ti članovi tima započinju svoje provjere u dogovorenoj točki testiranja. Njihov je cilj izvršiti što je više moguće ad-hoc provjera – koje ispitivači možda neće osmisliti do ove faze.
4. Ocjenjivanje rezultata testa
Po završetku testova (ili čak između pojedinačnih provjera) ispitivači će ocijeniti rezultate, ali bez formalnog dokumentiranja u testnom slučaju. Ako otkriju probleme s aplikacijom, neformalno ih zabilježe i razgovaraju o sljedećim koracima tima.
5. Prijava svih otkrivenih grešaka
Nakon što procijene rezultate, testeri moraju obavijestiti programere o greškama prisutnim u softveru kako bi imali dovoljno vremena da ih poprave prije izdavanja.
Tim za testiranje također koristi informacije kako bi odredio kako poboljšati svoje formalne procese testiranja.
6. Po potrebi ponovno testiranje
Tim za testiranje vjerojatno će ponoviti ad-hoc proces za nove iteracije aplikacije kako bi provjerio koliko dobro podnosi ažuriranja. Budući da će testeri popraviti mnoge prethodno identificirane nedostatke u svojim testnim slučajevima, buduće ad hoc provjere mogu zahtijevati drugačiji pristup.
Najbolji primjeri iz prakse za ad-hoc testiranje
Postoje određene prakse koje timovi za testiranje trebaju primijeniti tijekom ad hoc testiranja, uključujući:
1. Usmjerite potencijalne nedostatke u testiranju
Iako ad-hoc testiranje uključuje puno manje planiranja nego druge vrste, tim još uvijek ima za cilj riješiti nedostatke u osiguranju kvalitete. Ako ad-hoc testeri posumnjaju na bilo kakve specifične probleme s testnim slučajevima tima, trebali bi tome dati prioritet tijekom provođenja svojih provjera.
2. Razmotrite softver za automatizaciju
Strategije automatizacije kao što je hiperautomatizacija mogu ponuditi mnoge prednosti tvrtkama koje žele provoditi ad hoc testove.
Uspjeh toga ovisi o nekoliko ključnih čimbenika, uključujući alat koji tvrtka odabere, kao i opću složenost njihovih ad hoc testova.
3. Vodite iscrpne bilješke
Nedostatak dokumentacije u ad hoc testiranju uglavnom služi za dodatno usmjeravanje ovog procesa – tim bi mogao imati koristi od pravljenja neformalnih bilješki u nastavku. To ispitivačima daje jasnu evidenciju tih provjera i njihovih rezultata, povećavajući njihovu ukupnu ponovljivost.
4. Nastavite usavršavati testove
Ad-hoc testeri kontinuirano usavršavaju svoj pristup kako bi uzeli u obzir promjene u strategiji testiranja tima. Kada, na primjer, gledaju novije verzije softvera tvrtke, oni bi mogli prilagoditi ove provjere kao odgovor na novije i inkluzivnije formalne slučajeve testiranja.
7 pogrešaka i zamki u implementaciji
Ad-Hoc testovi
Kao i kod svakog drugog procesa testiranja, postoji širok raspon mogućih pogrešaka koje bi tim trebao izbjegavati, kao što su:
1. Neiskusni ispitivači
Kako bi se održao očekivani tempo ad-hoc testiranja, voditelj tima mora odrediti testere na temelju znanja i vještina koje posjeduju. Iako se mnogi oblici testiranja mogu prilagoditi početnom osoblju za osiguranje kvalitete, ad-hoc provjere zahtijevaju članove tima koji u potpunosti razumiju softver; po mogućnosti s iskustvom u izvođenju ovih testova.
2. Nefokusirane provjere
Ad-hoc testiranje može značajno poboljšati pokrivenost testom zbog bržeg tempa – tim ne mora ispunjavati opsežnu dokumentaciju prije i nakon svake provjere.
Međutim, ad-hoc testeri i dalje moraju zadržati snažan fokus; na primjer, mogli bi odlučiti dati prioritet određenim komponentama s većim rizikom kvara.
3. Nema planiranja
Izbjegavanje bilo kakvog plana moglo bi ograničiti učinkovitost ad hoc testiranja. Unatoč nestrukturiranoj prirodi ovog pristupa, važno je da tim ima grubu predodžbu o tome koje testove pokrenuti prije nego što počnu.
Vrijeme je ograničeno tijekom ovog procesa i znanje o tome kako postupiti može ponuditi mnoge prednosti.
4. Pretjerano strukturiran
Na suprotnom kraju spektra, ovaj se pristup obično oslanja na nedostatak planiranja jer to pomaže testerima da aktivno podrivaju testne slučajeve i pronađu skrivene pogreške.
Ad hoc testiranje također je poznato kao nasumično testiranje i nametanje strukture može spriječiti ove provjere u lociranju grešaka.
5. Nema dugoročnih promjena
Svrha ad-hoc testiranja je identificirati sve slabosti u testnim slučajevima tima; ovo ispituje njihovu cjelokupnu strategiju jednako kao i sam softver.
Međutim, to znači da su ad-hoc testovi općenito učinkoviti samo ako tim koristi te informacije za usavršavanje svojih formalnih provjera tijekom vremena.
6. Nekompatibilni skupovi podataka
Gotovo svaki oblik testiranja zahtijeva oblik simuliranih podataka kako bi se procijenilo kako aplikacija reagira; neki alati omogućuju testerima da automatski popune program lažnim podacima .
Međutim, to možda ne odražava način na koji bi korisnik koristio softver – ad hoc provjere zahtijevaju skupove podataka s kojima će se softver vjerojatno susresti.
7. Informacijski silosi
Bitno je da su testeri i programeri u stalnoj međusobnoj komunikaciji, čak i ako potonji nije dio ad-hoc procesa testiranja.
To pomaže svima da razumiju koji su testovi provedeni – pokazujući sljedeće radnje koje treba poduzeti, a također sprječava testere da bespotrebno ponavljaju određene provjere.
Vrste izlaza iz ad-hoc testova
Ad-hoc provjere proizvode nekoliko različitih rezultata, uključujući:
1. Rezultati ispitivanja
Pojedinačni testovi daju različite rezultate specifične za točnu komponentu i uključeni pristup – to može imati različite oblike.
Obično je odgovornost ispitivača utvrditi predstavljaju li rezultati pogrešku, iako nedostatak dokumentacije otežava usporedbu toga s njihovim očekivanjima. Tim prosljeđuje ove rezultate programerima ako primijete probleme.
2. Dnevnici ispitivanja
Sam softver koristi komplicirani sustav internih dnevnika za praćenje korisničkih unosa i isticanje brojnih problema s datotekama ili bazama podataka koji bi se mogli pojaviti.
To bi moglo ukazivati na internu pogrešku, uključujući određeni dio softvera koji uzrokuje problem. Uz ove informacije, ad-hoc testeri i programeri mogu puno lakše riješiti probleme koje otkriju.
3. Poruke o pogreškama
Mnoge ad-hoc provjere posebno imaju za cilj probiti softver i razotkriti njegove granice, što znači da su poruke o pogrešci aplikacije jedan od najčešćih rezultata ovih testova.
Namjernim izazivanjem poruka o pogreškama, tim može prikazati ono što prosječni krajnji korisnik vidi kad god neočekivane akcije koje poduzmu imaju negativan učinak na rad programa.
Primjeri ad-hoc testiranja
Evo tri ad hoc scenarija testiranja koji pokazuju kako bi tim to mogao implementirati za različite aplikacije:
1. Web aplikacija za e-trgovinu
Ako tvrtka želi testirati web-aplikaciju temeljenu na e-trgovini, može upotrijebiti ad-hoc testiranje – konkretno testiranje majmuna – da vidi koliko dobro platforma podnosi neočekivane interakcije korisnika.
Ispitivači mogu imati za cilj pogurati svaku značajku do svojih granica, primjerice dodavanjem artikala u svoju košaricu u nerealnim količinama ili pokušajem kupnje proizvoda kojih nema na zalihama. Nisu ograničeni testnim slučajevima tima i postoji nekoliko ograničenja koje provjere mogu izvesti; testeri bi čak mogli pokušati dovršiti kupnju koristeći zastarjele URL-ove.
2. Desktop aplikacija
Ad-hoc testeri također mogu primijeniti ove tehnike za desktop aplikacije s mogućim fokusom na različite strojeve i koliko dobro se svaki od njih prilagođava programu.
Članovi tima mogu ponavljati ove provjere kako bi vidjeli kako promjena postavki hardvera ili softvera utječe na ukupnu izvedbu aplikacije. Na primjer, određena grafička kartica može imati problema s prikazom sučelja.
Alternativno, ti bi testeri mogli jednostavno dati svom programu nemoguće unose i vidjeti kako on reagira, primjerice može li ispravno prikazati poruke o pogrešci koje krajnjem korisniku adekvatno objašnjavaju problem.
3. Mobilna aplikacija
Jedan od načina na koji bi ad-hoc testeri mogli ispitati mobilnu aplikaciju je testiranje njezinih sigurnosnih protokola – mogli bi pokušati izravno pristupiti razvojnim alatima aplikacije, na primjer.
Tim može pokušati vidjeti mogu li izvesti neovlaštene radnje pronalaženjem uobičajenih rupa u zakonu i iskorištavanja; mogli bi posebno zamoliti članove osoblja s iskustvom u sigurnosti aplikacija da to olakšaju.
To također može uključivati testiranje u paru s programerima zbog njihovog uvida u dizajn aplikacije, dopuštajući testeru da razbije softver i pokaže gdje točno nedostaje njegova sigurnost.
Vrste grešaka i otkrivenih grešaka
kroz ad-hoc testiranje
Ad-hoc provjere mogu otkriti mnoge probleme s programom, kao što su:
1. Pogreške u funkcionalnosti
Korištenje ad-hoc testiranja za ispitivanje osnovnih značajki aplikacije može otkriti ozbiljne greške koje utječu na način na koji krajnji korisnici mogu raditi s njom.
Na primjer, majmun koji testira opcije plaćanja na web-mjestu e-trgovine ilustrirat će uvjete koji sprječavaju transakciju.
2. Problemi s izvedbom
Ispitivači mogu posebno raditi na stvaranju problema s performansama u programu – kao što je punjenje baze podataka različitim neželjenim unosima.
To bi se moglo manifestirati kao značajno vrijeme kašnjenja ili čak opća nestabilnost softvera, što će vjerojatno dovesti do (potencijalno cijelog sustava) pada.
3. Problemi s upotrebljivošću
Ove provjere također mogu istaknuti greške u sučelju i općem korisničkom iskustvu. UI mobilne aplikacije , na primjer, može se prikazati drugačije na drugom operativnom sustavu ili razlučivosti zaslona. Loše sučelje može dovesti do toga da korisnici imaju problema s radom ove aplikacije.
4. Sigurnosni nedostaci
Nasumična priroda ad-hoc testiranja omogućuje pokrivanje niza uobičajenih i rijetkih sigurnosnih problema; tester bi mogao upotrijebiti ove provjere kako bi pronašao administrativna stražnja vrata programa.
Alternativno, njihov pregled može pokazati da softver nema enkripciju podataka.
Uobičajene metrike ad-hoc testiranja
Ad-hoc testiranje koristi različite metrike za olakšavanje rezultata, uključujući:
1. Učinkovitost otkrivanja kvarova
Ova metrika provjerava koliko je učinkovit proces testiranja u pronalaženju nedostataka u svakom obliku testiranja, uključujući ad hoc testiranje. Učinkovitost otkrivanja nedostataka postotak je otkrivenih nedostataka podijeljen s ukupnim brojem problema – što pokazuje koliko su testovi učinkoviti.
2. Stopa pokrivenosti testa
Pomoćna funkcija ad-hoc testiranja je povećanje pokrivenosti provjerom komponenti na način na koji testni slučajevi ne uzimaju u obzir. To znači da će testeri također težiti radikalnom povećanju pokrivenosti testom kroz svaku provjeru koliko god mogu.
3. Ukupno trajanje testa
Ad-hoc testiranje puno je brže od drugih procesa osiguranja kvalitete – i bitno je da ispitivači rade na održavanju te prednosti. Mjerni podaci o trajanju testa pokazuju članovima tima kako mogu uštedjeti vrijeme i još više ujediniti prednosti ad-hoc strategija.
4. Stopa pada
Ovi testovi često imaju za cilj pokvariti softver i uzrokovati pad ili ozbiljnu pogrešku – dopuštajući im da odu dalje od uobičajenih strategija testiranja i pronađu neočekivane probleme. U tu svrhu može pomoći znati koliko se često softver ruši i što uzrokuje te probleme.
5 najboljih ad-hoc alata za testiranje
Postoji mnogo besplatnih i plaćenih alata za testiranje dostupnih za ad-hoc testiranje u testiranju softvera – najboljih pet su sljedeći:
1. ZAPTEST besplatno i poslovno izdanje
ZAPTEST je sveobuhvatan program za testiranje softvera koji pruža visoku razinu test + RPA funkcionalnosti u besplatnoj i poslovnoj verziji.
Ova kompletna automatizacija softvera + RPA Suite omogućuje potpuno testiranje na različitim stolnim i mobilnim platformama; softverska 1SCRIPT tehnologija također omogućuje korisnicima da s lakoćom opetovano izvršavaju iste provjere. Povrh toga, alat koristi najsuvremeniji računalni vid , što ZAPTEST-u omogućuje izvođenje ad-hoc testova iz ljudske perspektive.
2. BrowserStack
BrowserStack je platforma u oblaku koja može olakšati testiranje na više od 3000 različitih strojeva, uz dodatnu značajku automatizacije Selenium skripti. Iako pruža jaku pokrivenost za softverske projekte, najbolje radi s preglednicima i mobilnim aplikacijama .
BrowserStack rješenja za testiranje također uključuju besplatnu probnu verziju sa 100 minuta automatiziranog testiranja – iako to može imati ograničenu upotrebu.
Iako pristup temeljen na oblaku može biti od pomoći, on također negativno utječe na vrijeme odziva platforme.
3. LambdaTest
LambdaTest na sličan način koristi tehnologiju temeljenu na oblaku i stavlja snažan naglasak na testiranje preglednika što može ograničiti njegovu učinkovitost za druge aplikacije – iako se i dalje dobro uklapa s iOS i Android programima. Ovo je korisna platforma kada je skalabilnost zabrinjavajuća i integrira se s mnogim drugim testnim uslugama hostinga.
Međutim, neki korisnici imaju mješovite reakcije na cijene aplikacije za različite dostupne opcije bez probnog razdoblja, što potencijalno ograničava dostupnost za manje organizacije.
4. TestRail
TestRail je općenito prilično prilagodljiv jer se u potpunosti izvodi u pregledniku i, unatoč snažnom fokusu na učinkovite slučajeve testiranja, također se može pohvaliti izravnom ad-hoc funkcionalnošću. Analitika koju pruža nakon svakog testa također može pomoći timovima koji aktivno izbjegavaju izradu vlastite neovisne dokumentacije, dok im još uvijek omogućuje provjeru valjanosti procesa testiranja.
Međutim, veći paketi bi se mogli boriti s formatom koji se temelji na pregledniku, što može znatno ograničiti uštedu vremena ad-hoc testiranja.
5. Zefir
Zephyr je platforma za upravljanje testiranjem tvrtke SmartBear koja pomaže timovima za osiguranje kvalitete poboljšati svoju vidljivost testiranja, a istovremeno se dobro integrira s drugim softverom za praćenje bugova.
Međutim, ova je značajka ograničena na određene aplikacije, a Confluence i Jira one koje imaju najviše koristi od Zephyra – to možda nisu najučinkovitija rješenja za svako poslovanje. Postoji nekoliko skalabilnih programa dostupnih pod markom Zephyr po različitim cijenama.
Kontrolni popis za ad-hoc testiranje, savjeti i trikovi
Evo dodatnih savjeta za timove koje treba uzeti u obzir prilikom provođenja ad hoc testiranja:
1. Dajte prioritet osjetljivim komponentama
Neke značajke ili komponente prirodno su izloženije većem riziku od pogreške od drugih, osobito ako su važne za cjelokupnu funkciju programa.
Svaki pristup testiranju trebao bi identificirati dijelove aplikacije koji bi mogli imati koristi od temeljitije pažnje. Ovo je posebno korisno kada je ukupno vrijeme za testiranje ograničeno.
2. Istražite različite alate za testiranje
Alat koji organizacija primjenjuje kako bi olakšala svoje testove može utjecati na pokrivenost i pouzdanost ovih provjera.
Uz ad-hoc testiranje, vrijedi pogledati što je moguće više programa kako biste pronašli one koji odgovaraju njegovom aspektu usmjerenom na korisnika. Softver koji koristi tehnologiju računalnog vida, poput ZAPTEST-a, može pristupiti ad-hoc testovima korištenjem ljudske strategije.
3. Usvojite ad-hoc način razmišljanja
Ad-hoc testiranje nudi ogromnu slobodu tijekom faze osiguranja kvalitete, ali tim se tome mora posvetiti kako bi dobio ključne prednosti strategije.
Na primjer, ad-hoc testeri trebali bi izbjegavati sve svoje uobičajene dokumente osim osnovnog vođenja bilješki i moraju pregledati softver iz potpuno nove perspektive.
4. Vjerujte testiranju instinkta
Iskustvo s ad-hoc testiranjem ili općim provjerama softvera može pomoći u isticanju uobičajenih točaka neuspjeha, a to pomaže testerima da utvrde kako uočiti pogreške svih vrsta.
Od ključne je važnosti da testeri vjeruju svojim instinktima i uvijek koriste to znanje u svoju korist – mogu intuitirati koje bi ad hoc provjere bile od najveće pomoći.
5. Potpuno zabilježite otkrivene greške
Iako ad-hoc testiranje nema formalnu dokumentaciju i uglavnom se oslanja na neformalne bilješke, ipak je bitno da tim može identificirati i priopćiti uzrok softverske pogreške.
Moraju zabilježiti sve informacije koje test pruža a koje su relevantne za programere, kao što su svi potencijalni uzroci ovih problema.
6. Uvijek vodite računa za korisnika
Svaki oblik testiranja nastoji do određenog stupnja prilagoditi cjelokupno iskustvo korisnika – a ad hoc testiranje nije iznimka. Iako često dublje proučava unutarnji rad aplikacije, pa čak i njezin interni kod, ad hoc testeri trebali bi pokušati razbiti ovaj softver na načine na koje bi korisnici teoretski mogli.
7. Kontinuirano poboljšavajte proces
Timovi za testiranje trebali bi poboljšati svoj pristup ad-hoc testiranju između više iteracija istog softvera i od jednog projekta do drugog.
Oni mogu prikupiti povratne informacije od programera kako bi vidjeli koliko su njihovi ad-hoc testovi pomogli u fazi osiguranja kvalitete i jesu li uspjeli značajno povećati pokrivenost testom.
Zaključak
Ad-hoc testiranje može pomoći organizacijama svih vrsta da provjere autentičnost svoje strategije testiranja softvera, ali način na koji implementiraju ovu tehniku može biti značajan faktor u njezinoj učinkovitosti.
Balansiranje različitih vrsta testiranja ključno je za dobivanje najviše koristi od ad-hoc provjera – pogotovo zato što ovaj oblik testiranja namjerava nadopuniti ostale popunjavanjem strateške praznine.
Uz aplikaciju kao što je ZAPTEST, moguće je timovima provoditi ad-hoc testove s većim povjerenjem ili fleksibilnošću, osobito ako implementiraju automatizaciju. Bez obzira na specifičan pristup tima, njihova predanost ad-hoc testiranju mogla bi revolucionirati cijeli program ili projekt.
