Get your 6-month No-Cost Opt-Out offer for Unlimited Software Automation?

 

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.

 

Sadržaj dokumenta

Značenje ad-hoc testiranja: Što je ad-hoc testiranje?

kontrolni popis uat, alati za testiranje web aplikacija, automatizacija i više

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?

Prednosti uspostavljanja Testing Center of Excellence. Razlikuje li se testiranje performansi od funkcionalnog testiranja?

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

Prednosti uspostavljanja Testing Center of Excellence. Razlikuje li se testiranje performansi od funkcionalnog testiranja?

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?

koji bi trebao biti uključen u alate za automatizaciju testiranja softvera i planiranje

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

Zaptest, najbolji alat za automatizaciju funkcionalnog 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

izaziva testiranje opterećenja

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

api testiranje i automatizacija

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?

End to end testiranje - Što je E2E testiranje, alati, vrste i više

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

Usporedba UAT testiranja s regresijskim testiranjem i drugim

Neki ljudi ad-hoc i istraživačko testiranje smatraju sinonimom, iako je istina kompliciranija od ovoga.

 

1. Što je eksploratorno testiranje?

Prednosti uspostavljanja Testing Center of Excellence. Razlikuje li se testiranje performansi od funkcionalnog testiranja?

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

Prednosti uspostavljanja Testing Center of Excellence. Razlikuje li se testiranje performansi od funkcionalnog testiranja?

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.

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

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

testiranje automatizacije web aplikacije

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?

računalni vid za testiranje softvera

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?

Automatsko ispitivanje opterećenja

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

Bak end testiranje, alati, što je to, vrste, pristupi

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

2-2.png

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

koristi testiranje korisničkog sučelja

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

automatizacija testiranja softvera post

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.

 

IS YOUR COMPANY IN NEED OF

ENTERPRISE LEVEL

TASK-AGNOSTIC SOFTWARE AUTOMATION?

Vrste grešaka i otkrivenih grešaka

kroz ad-hoc testiranje

zaptest-runtime-error.png

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

ispitivanje opterećenja

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

testiranje najboljeg besplatnog i poslovnog softvera + alati za automatizaciju RPA

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

Članak o testiranju sive kutije - alati, pristupi, usporedba testiranja u zatvoru u odnosu na bijelu i crnu kutiju, besplatni alati sive kutije i poslovni alati.

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

Kontrolni popis za testiranje softvera

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.

Download post as PDF

Alex Zap Chernyak

Alex Zap Chernyak

Founder and CEO of ZAPTEST, with 20 years of experience in Software Automation for Testing + RPA processes, and application development. Read Alex Zap Chernyak's full executive profile on Forbes.

Get PDF-file of this post