Testimi ad-hoc është një lloj testimi i softuerit që zhvilluesit dhe kompanitë e softuerit zbatojnë kur kontrollojnë përsëritjen aktuale të softuerit. Kjo formë e testimit jep një nivel më të madh njohurish mbi programin, duke gjetur çështje që testimi konvencional mund të mos jetë në gjendje t’i nxjerrë në pah.
Është thelbësore që ekipet e testimit të kenë një kuptim të plotë të procesit të testimit ad hoc, në mënyrë që të dinë se si t’i anashkalojnë sfidat e tij dhe të sigurohen që ekipi mund ta zbatojë me sukses këtë teknikë.
Njohja saktësisht se si funksionon testimi ad-hoc dhe cilat mjete mund të lehtësojnë zbatimin e tij, i lejon një biznesi të përmirësojë vazhdimisht procedurat e tij të sigurimit të cilësisë. Procesi zyrtar i testimit ndjek rregulla shumë specifike, të cilat mund të rezultojnë në mungesën e gabimeve të caktuara nga ekipi – kontrollet ad-hoc mund t’i anashkalojnë këto pika të verbëra dhe të testojnë shpejt çdo veçori të softuerit.
Në këtë artikull, ne shqyrtojmë nga afër testimin ad-hoc dhe si mund ta përdorni atë në avantazhin tuaj kur zhvilloni një produkt softuerësh.
Kuptimi i testimit ad-hoc: Çfarë është testimi ad-hoc?
Testimi ad-hoc është një proces i sigurimit të cilësisë që shmang rregullat dhe dokumentacionin formal – duke i ndihmuar testuesit të gjejnë gabime në aplikimin e tyre që qasjet konvencionale nuk mund t’i identifikojnë. Kjo zakonisht kërkon njohuri gjithëpërfshirëse të softuerit përpara fillimit të testimit – duke përfshirë një kuptim të funksionimit të brendshëm të programit. Këto kontrolle ad-hoc synojnë të prishin aplikacionin në mënyra që pasqyrojnë të dhënat e përdoruesit, duke llogaritur situata të ndryshme të mundshme në mënyrë që zhvilluesit të mund të rregullojnë çdo problem ekzistues.
Mungesa e dokumentacionit është thelbësore për këtë teknikë, e cila nuk përfshin asnjë listë kontrolli ose raste testimi për të udhëhequr testuesit në veçoritë e një aplikacioni. Testimi ad-hoc ka të bëjë tërësisht me testimin e softuerit në çdo mënyrë që një ekip vendos se është efektiv në atë moment specifik. Kjo mund të marrë parasysh testet formale para-ekzistuese, por gjithashtu mund të përfshijë thjesht kryerjen e sa më shumë testeve të jetë e mundur në kohën (me gjasë të kufizuar) që është caktuar për këtë teknikë.
1. Kur dhe pse duhet të bëni Testim Ad-Hoc në testimin e softuerit?
Arsyeja kryesore që kompanitë kryejnë testime ad-hoc është për shkak të aftësisë së saj për të zbuluar gabime që qasjet tradicionale nuk mund t’i gjejnë. Kjo mund të jetë për çdo numër arsyesh, të tilla si rastet konvencionale të testimit pas një procesi veçanërisht të standardizuar që nuk mund të llogarisë veçoritë e një aplikacioni.
Çdo lloj testimi mund të ofrojë perspektiva të reja dhe qasje interesante për sigurimin e cilësisë – kjo tregon gjithashtu probleme me strategjinë e zakonshme të testimit. Për shembull, nëse testimi ad-hoc mund të identifikojë një shqetësim që rastet e testimit të ekipit nuk e adresojnë, kjo sugjeron që ata mund të përfitojnë nga rikalibrimi i metodologjisë së tyre të testimit.
Testuesit mund të kryejnë kontrolle ad-hoc në çdo moment të procesit të testimit. Kjo zakonisht shërben si një plotësues për sigurimin tradicional (dhe më formal) të cilësisë dhe, duke pasur parasysh këtë, testuesit mund të kryejnë inspektime ad-hoc ndërsa kolegët e tyre kryejnë ekzaminime më formale. Megjithatë, në vend të kësaj, ata mund të preferojnë të ruajnë kontrollet ad-hoc deri pas procesit të testimit formal si një vazhdim që synon në mënyrë specifike pikat e verbëra të mundshme.
Testimi ad-hoc mund të jetë gjithashtu i dobishëm kur koha është veçanërisht e kufizuar për shkak të mungesës së dokumentacionit – koha e duhur varet nga kompania dhe qasja e saj e preferuar.
2. Kur nuk keni nevojë të bëni Testim Ad-Hoc
Nëse nuk ka kohë të mjaftueshme për të kryer testime ad-hoc dhe formale, është e rëndësishme që ekipi t’i japë përparësi këtij të fundit pasi kjo siguron mbulim të konsiderueshëm të testit – edhe nëse ekzistojnë ende disa boshllëqe.
Nëse testet formale të ekipit zbulojnë gabime që kërkojnë rregullim, në përgjithësi është më mirë të prisni derisa zhvilluesit të përfundojnë ndryshimet e nevojshme për të vendosur kontrolle ad-hoc. Përndryshe, rezultatet që ata japin së shpejti mund të bëhen të vjetruara, veçanërisht nëse testet lidhen me komponentin që tashmë po përjeton defekte.
Përveç kësaj, testimi ad-hoc duhet të ndodhë përpara fazës së testimit beta.
3. Kush është i përfshirë në Testimin Ad-Hoc?
Ekzistojnë disa role kyçe të përfshira në procesin e testimit Ad-Hoc, duke përfshirë:
• Testuesit e softuerit janë anëtarët kryesorë të ekipit që kryejnë kontrolle ad hoc. Nëse miratoni testimin e miqve ose çifteve, atëherë disa nga këta testues do të punojnë së bashku në të njëjtët komponentë.
• Zhvilluesit mund t’i përdorin në mënyrë të pavarur këto kontrolle përpara fazës formale të sigurimit të cilësisë për të inspektuar shpejt softuerin e tyre, megjithëse kjo është më pak e thelluar se testimi i dedikuar ad-hoc.
• Drejtuesit e ekipit ose departamentit autorizojnë strategjinë e përgjithshme të testimit – duke i ndihmuar testuesit të përcaktojnë se kur të fillojnë testimin ad-hoc dhe si ta kryejnë atë pa ndërprerë kontrollet e tjera.
Përfitimet e testimit ad-hoc
Përparësitë e testimit ad-hoc në testimin e softuerit përfshijnë:
1. Rezolucione të shpejta
Meqenëse këto teste nuk përfshijnë dokumentacion të shpeshtë para, gjatë ose pas kontrolleve, është e mundur që ekipet të identifikojnë çështjet shumë më shpejt. Kjo thjeshtësi ofron liri të jashtëzakonshme për testuesit.
Për shembull, nëse ata testojnë një komponent dhe nuk mund të identifikojnë ndonjë gabim, ekipi thjesht mund të kalojë në testin tjetër pa e shënuar këtë në një dokument.
2. Plotëson lloje të tjera testimi
Asnjë strategji testimi nuk është e përsosur dhe mbulimi 100% zakonisht është i pamundur të arrihet – edhe me një orar gjithëpërfshirës. Gjithmonë do të ketë boshllëqe në testimin konvencional, kështu që është e rëndësishme që kompanitë të integrojnë qasje të shumta.
Testimi ad-hoc synon në mënyrë specifike të gjejë çështjet që testimi formal nuk mund të mbulojë – duke garantuar një mbulim më të gjerë të përgjithshëm të testit.
3. Ekzekutim fleksibël
Testimi ad-hoc mund të ndodhë në çdo moment të procesit të sigurimit të cilësisë përpara testimit beta, duke i lënë kompanitë dhe ekipet të vendosin se kur është më e mira për të kryer këto kontrolle. Ata mund të zgjedhin të kryejnë teste ad-hoc së bashku me testimin konvencional ose mund të presin deri më pas – pavarësisht se çfarë, ekipi përfiton nga zgjedhjet që kanë në dispozicion.
4. Bashkëpunim më i madh
Zhvilluesit janë më të përfshirë në këtë proces sesa shumë forma të tjera testimi – veçanërisht nëse kompania po përdor testimin e miqve dhe çifteve.
Si rezultat, zhvilluesit marrin një pasqyrë më të mirë në aplikacionet e tyre dhe mund të jenë në gjendje t’i adresojnë gabimet në një standard më të lartë. Kjo ndihmon në përmirësimin e cilësisë së përgjithshme të softuerit edhe më tej.
5. Perspektiva të ndryshme
Testimi ad-hoc mund ta shfaqë aplikacionin nga këndvështrime të reja, duke i ndihmuar testuesit të përfshihen me këto veçori në mënyra të reja. Perspektivat shtesë janë kritike gjatë testimit pasi kontrollet formale shpesh kanë të paktën boshllëqe të vogla.
Nëse testuesit ad-hoc përdorin softuerin me qëllimin specifik për ta thyer atë, ata do të jenë në gjendje të përcaktojnë më lehtë kufijtë e programit.
Sfidat e Testimit Ad-Hoc
Procesi i testimit ad-hoc ka gjithashtu disa sfida, si:
1. Vështirësi me raportim
Mungesa e dokumentacionit e bën testimin ad-hoc shumë më të shpejtë, por gjithashtu mund ta bëjë të vështirë raportimin për çdo gjë tjetër përveç një problemi madhor.
Për shembull, një kontroll i kryer më parë mund të bëhet më i rëndësishëm në një datë të mëvonshme, pavarësisht se fillimisht nuk çoi në rezultate të rëndësishme. Pa dokumentacion gjithëpërfshirës, ekipi mund të mos jetë në gjendje t’i shpjegojë këto teste.
2. Më pak e përsëritshme
Në vija të ngjashme, testuesit mund të mos jenë plotësisht të vetëdijshëm për gjendjen e saktë të nevojshme për të shkaktuar reagimet që ata vëzhgojnë. Për shembull, një kontroll ad-hoc që kthen një gabim mund të mos ketë informacion të mjaftueshëm që ekipi të ndërmarrë veprime. Ata mund të mos jenë në dijeni se si ta përsërisin këtë test dhe të marrin të njëjtin rezultat.
3. Kërkon përvojë në softuer
Meqenëse shpejtësia është thelbësore gjatë testimit ad-hoc dhe zakonisht përfshin përpjekjen për të prishur aplikacionin, është e rëndësishme që këta testues të kenë një kuptim intim të këtij programi.
Njohja se si funksionon i lejon testuesit të thyejnë dhe manipulojnë softuerin në më shumë mënyra, por kjo mund të rrisë ndjeshëm kërkesat e aftësive për testimin ad-hoc.
4. Përgjegjshmëri e kufizuar
Mungesa e dokumentacionit mund të shkaktojë më shumë probleme sesa thjesht raportim i dobët; ai gjithashtu mund të zgjasë pa dashje procesin e testimit, duke ndikuar në dobinë e testeve të shpejta individuale ad-hoc.
Testuesit mund të luftojnë për të mbajtur gjurmët e përparimit të tyre pa dokumentacion të mjaftueshëm përgjatë çdo faze. Kjo madje mund të bëjë që ata të përsërisin një kontroll që testuesit e tjerë kanë përfunduar tashmë.
5. Mund të mos pasqyrojë përvojën e përdoruesit
Qëllimi i pothuajse çdo lloj testimi është që të llogarisë gabimet që prekin përdoruesit përfundimtarë në një farë mënyre. Testimi ad-hoc mbështetet kryesisht në një testues me përvojë që përpiqet të imitojë një përdorues të papërvojë dhe kjo duhet të jetë e qëndrueshme gjatë çdo kontrolli deri dhe duke përfshirë përpjekjet e tyre për të thyer aplikacionin.
Karakteristikat e Testeve Ad-Hoc
Karakteristikat kryesore të testeve ad-hoc të suksesshme përfshijnë:
1. Hetuese
Prioriteti kryesor i testimit ad-hoc është identifikimi i gabimeve me aplikacionin duke përdorur teknika që kontrollet konvencionale nuk i marrin parasysh. Ekzaminimet ad-hoc pastrojnë këtë softuer me qëllim të qartë për të gjetur vrima në procedurën e testimit të ekipit, duke përfshirë mbulimin e rasteve të tyre të testimit.
2. I pastrukturuar
Kontrollet ad hoc zakonisht nuk kanë një plan të caktuar përtej kryerjes së sa më shumë testeve të jetë e mundur jashtë kufijve tipikë të sigurimit formal të cilësisë. Testuesit zakonisht do t’i grupojnë kontrollet sipas komponentëve për lehtësi, por edhe kjo nuk është e nevojshme – ata madje mund t’i krijojnë kontrollet gjatë kryerjes së tyre.
3. E drejtuar nga përvoja
Testuesit ad-hoc përdorin përvojën e tyre para-ekzistuese të softuerit për të vlerësuar se cilat teste do të jepnin më shumë përfitime dhe për të adresuar pikat e verbëra të zakonshme në testimin zyrtar.
Megjithëse procesi i testimit është ende plotësisht i pastrukturuar, testuesit zbatojnë njohuritë e tyre për kontrollet e mëparshme ad-hoc ndër të tjera ndërsa vendosin strategjinë e tyre.
4. Me shtrirje të gjerë
Nuk ka udhëzues të saktë se cilat kontrolle duhet të kryejë ekipi gjatë testimit ad-hoc, por ato zakonisht mbulojnë një sërë komponentësh – ndoshta me më shumë fokus në aspektet më të ndjeshme të aplikacionit. Kjo i ndihmon testuesit të garantojnë se ekzaminimet e tyre janë në gjendje të plotësojnë plotësisht testimin formal.
Çfarë testojmë në Testet Ad-Hoc?
Ekipet e sigurimit të cilësisë zakonisht testojnë sa vijon gjatë testimit ad-hoc:
1. Cilësia e softuerit
Këto kontrolle synojnë të identifikojnë gabimet në aplikacion që testimi konvencional nuk mund t’i zbulojë; kjo do të thotë se procesi teston kryesisht shëndetin e përgjithshëm të aplikacionit.
Sa më shumë gabime që mund të gjejë testimi ad-hoc, aq më shumë përmirësime mund të zbatojnë zhvilluesit përpara afatit të tyre.
2. Rastet e testimit
Testimi ad-hoc në përgjithësi nuk zbaton rastet e testimit – dhe kjo është veçanërisht në mënyrë që ekipi të mund të hetojë se sa efektivë janë ata në ofrimin e mbulimit të bollshëm. Rastet e testimit ka të ngjarë të jenë të pamjaftueshme nëse kontrollet ad-hoc mund të gjejnë gabime që proceset konvencionale të testimit nuk munden.
3. Stafi testues
Qëllimi mund të jetë gjithashtu kontrollimi i aftësive dhe njohurive të ekipit testues, edhe nëse rastet e testimit janë adekuate. Për shembull, metodologjia e tyre për zbatimin e rasteve mund të jetë e pamjaftueshme dhe testimi ad-hoc mund të jetë kritik për adresimin e boshllëqeve që rezultojnë në mbulimin e testeve.
4. Kufijtë e softuerit
Testimi ad-hoc kërkon gjithashtu të kuptojë kufijtë e aplikacionit – si p.sh. se si ai reagon ndaj hyrjeve të papritura ose ngarkesave të larta të sistemit. Testuesit mund të hetojnë në mënyrë specifike mesazhet e gabimit të programit dhe sa mirë funksionon ky aplikacion kur është nën presion të konsiderueshëm.
Pastrimi i një konfuzioni:
Testimi Ad-Hoc dhe Testimi Eksplorues
Disa njerëz e konsiderojnë testimin ad-hoc dhe eksplorues si sinonime, megjithëse e vërteta është më e ndërlikuar se kjo.
1. Çfarë është Testimi Hulumtues?
Testimi eksplorues i referohet procedurave të sigurimit të cilësisë që hetojnë softuerin nga një këndvështrim holistik dhe kombinojnë në mënyrë specifike proceset e zbulimit dhe testimit në një metodë të vetme. Ky është zakonisht një terren i mesëm midis testimit plotësisht të strukturuar dhe kontrolleve ad-hoc krejtësisht të lira.
Testimi eksplorues funksionon më mirë në skenarë specifikë, si p.sh. kur është i nevojshëm reagimi i shpejtë ose nëse ekipi duhet të trajtojë rastet e skajshme. Ky lloj testimi zakonisht arrin potencialin e tij të plotë kur ekipi përdor testimin e skriptuar krahas tij.
2. Dallimet midis Testimit Eksplorator
dhe Testimi Ad-Hoc
Dallimi më i madh midis testimit ad-hoc dhe atij eksplorues është përdorimi i dokumentacionit nga i pari për të regjistruar dhe lehtësuar kontrollet e tij, ndërsa testimi ad-hoc e shmang plotësisht këtë. Testimi eksplorues e vë më shumë theksin në lirinë e testit, por kurrë në të njëjtin nivel me një qasje ad-hoc e cila është tërësisht e pastrukturuar.
Testimi eksplorues përfshin gjithashtu të mësuarit rreth aplikacionit dhe funksionimit të tij të brendshëm gjatë këtyre kontrolleve – testuesit ad-hoc shpesh kanë një njohuri të plotë të funksionalitetit të softuerit përpara se të fillojnë.
Llojet e testeve ad-hoc
Ekzistojnë tre forma kryesore të testimit ad-hoc në testimin e softuerit, duke përfshirë:
1. Testimi i majmunit
Ndoshta lloji më i popullarizuar i testimit ad-hoc, testet e majmunëve janë ato që përfshijnë një ekip që shikon rastësisht komponentë të ndryshëm.
Kjo zakonisht ndodh gjatë procesit të testimit të njësisë dhe zbaton një sërë kontrollesh pa asnjë rast testimi. Testuesit i hetojnë në mënyrë të pavarur të dhënat në mënyra krejtësisht të pastrukturuara, duke i lejuar ata të ekzaminojnë sistemin më të gjerë dhe aftësinë e tij për t’i rezistuar tendosjes intensive nga inputet e përdoruesit.
Vëzhgimi i rezultateve të këtyre teknikave të pakapshme ndihmon ekipin e testimit të identifikojë gabimet që testet e njësive të tjera kanë humbur për shkak të mangësive në metodat konvencionale të testimit.
2. Testimi i shokut
Në një kontekst ad-hoc, testet e miqve përdorin të paktën dy anëtarë të stafit – zakonisht një testues dhe një zhvillues – dhe kryesisht zhvillohen pas fazës së testimit të njësisë . “Shokët” punojnë së bashku në të njëjtin modul për të identifikuar gabimet. Grupet e tyre të ndryshme të aftësive dhe përvoja gjithëpërfshirëse i bëjnë ata një ekip më efektiv, i cili ndihmon në zbutjen e shumë problemeve që lindin për shkak të mungesës së dokumentacionit.
Zhvilluesi madje mund të sugjerojë një numër testesh vetë, duke i lejuar ata të identifikojnë komponentët që mund të kenë nevojë për më shumë vëmendje.
3. Testimi në çift
Testimi në çift është i ngjashëm në atë që përfshin dy anëtarë të stafit, por zakonisht janë dy testues të veçantë, njëri prej të cilëve ekzekuton testet aktuale ndërsa tjetri mban shënime.
Edhe pa dokumentacion formal, marrja e shënimeve mund ta lejojë ekipin të mbajë në mënyrë joformale kontrollet individuale ad-hoc. Rolet e testuesit dhe shkruesit mund të ndryshojnë në varësi të testit ose çifti mund të ruajë rolet e tyre të caktuara gjatë gjithë procesit.
Testuesi që ka më shumë përvojë është zakonisht ai që kryen kontrollet aktuale – megjithëse ata gjithmonë e ndajnë punën me njëri-tjetrin.
Teste Ad-Hoc manuale apo të automatizuara?
Testimi i automatizuar mund të ndihmojë ekipet të kursejnë edhe më shumë kohë gjatë gjithë fazës së sigurimit të cilësisë; gjë që lejon testuesit të vendosin më shumë kontrolle në orarin e tyre. Edhe pa një strukturë të caktuar, është thelbësore që testuesit të punojnë për të maksimizuar mbulimin dhe automatizimi inkurajon inspektime më të thella të këtij softueri.
Kontrollet e automatizuara ad-hoc janë përgjithësisht më të sakta se testet manuale për shkak të aftësisë së tyre për të shmangur gabimet njerëzore gjatë detyrave përmendësh – kjo është veçanërisht e dobishme kur zbatohen të njëjtat teste në përsëritje të ndryshme. Suksesi i kësaj procedure zakonisht varet nga mjeti i automatizuar i testimit që zgjedh ekipi dhe funksionaliteti i tij.
Sidoqoftë, testimi i automatizuar ka kufizime të caktuara. Për shembull, forca kryesore e testimit ad-hoc është aftësia e tij për të imituar të dhënat e përdoruesit dhe për të kryer kontrolle të rastësishme ndërsa testuesi i del me to. Këto teste mund të humbasin rastësinë e tyre nëse programi i testimit të organizatës lufton me kontrolle komplekse.
Koha që duhet për të automatizuar këto detyra shumë specifike mund të kufizojë gjithashtu kursimet tipike të kohës së këtij procesi. Është e rëndësishme që ekipet të hetojnë tërësisht mjetet e disponueshme të automatizimit për të gjetur një që përputhet me projektin e kompanisë së tyre.
Çfarë ju nevojitet për të filluar Testimin Ad-Hoc?
Këtu janë parakushtet kryesore të testimit ad-hoc:
1. Staf i kualifikuar
Duke qenë se testet ad-hoc janë inspektime të shpejta dhe të rastësishme të funksionimit të brendshëm të softuerit, zakonisht ndihmon të kesh testues që kanë përvojë me softuerin. Ata gjithashtu duhet të kenë njohuri pune për parimet kryesore të testimit – kjo u lejon atyre të identifikojnë lehtësisht kontrollet më efektive.
2. Një qasje e pastrukturuar
Testuesit duhet të jenë të gatshëm të braktisin strategjitë e tyre të zakonshme për testimin ad-hoc; kjo mendësi është po aq kritike sa vetë kontrollet e cilësisë. Kjo metodë mund të ketë sukses vetëm pa strukturë ose dokumentacion dhe është jetike që testuesit ta mbajnë mend këtë në çdo fazë.
3. Software automatizimi
Megjithëse testimi ad-hoc mbështetet më shumë në testimin e inputeve dhe kushteve të rastësishme, automatizimi është ende një teknikë shumë efektive në çdo kontekst.
Për këtë arsye, kontrollet ad-hoc duhet të zbatojnë ende mjete testimi të automatizuara aty ku është e mundur, pasi aplikimi i duhur mund të thjeshtojë ndjeshëm procesin.
4. Forma të tjera testimi
Testet ad-hoc funksionojnë më mirë së bashku me kontrollet e tjera që marrin një qasje më formale – duke ndihmuar ekipin të garantojë mbulim të konsiderueshëm në të gjithë softuerin. Është jetike që testuesit të përziejnë teknika të ndryshme, megjithëse kjo mund të jetë para, gjatë ose pasi të kenë përfunduar testimin ad-hoc.
Procesi i testimit ad-hoc
Hapat e zakonshëm që testuesit duhet të ndjekin kur kryejnë testime ad-hoc në testimin e softuerit janë:
1. Përcaktimi i objektivave të testit ad-hoc
Kjo fazë është e kufizuar për shkak të mungesës së dokumentacionit dhe strukturës, por është ende e rëndësishme që ekipi të ketë një fokus të qartë. Testuesit mund të fillojnë të ndajnë ide të paqarta se cilat teste të ardhshme do të ekzekutohen dhe komponentët që duhet t’i japin përparësi.
2. Përzgjedhja e ekipit të testimit ad-hoc
Ndërsa ekipi merr një sërë kontrollesh të mundshme ad-hoc, ata gjithashtu kuptojnë se cilët testues do të ishin më të mirët për këtë lloj testimi. Ata zakonisht zgjedhin testues që e kuptojnë nga afër aplikacionin dhe gjithashtu mund t’i çiftojnë me një zhvillues.
3. Ekzekutimi i testeve ad-hoc
Pasi të vendosin se cilët testues janë të duhurit për këtë fazë, këta anëtarë të ekipit fillojnë kontrollet e tyre në një pikë të dakorduar në testim. Qëllimi i tyre është të kryejnë sa më shumë nga kontrollet ad-hoc të jetë e mundur – të cilat testuesit mund të mos i mendojnë deri në këtë fazë.
4. Vlerësimi i rezultateve të testit
Pas përfundimit të testeve (ose edhe ndërmjet kontrolleve individuale) testuesit do të vlerësojnë rezultatet, por pa i dokumentuar ato zyrtarisht në një rast testimi. Nëse zbulojnë ndonjë problem me aplikacionin, ata i regjistrojnë ato në mënyrë joformale dhe diskutojnë hapat e ardhshëm të ekipit.
5. Raportimi i ndonjë defekti të zbuluar
Pasi të vlerësojnë rezultatet, testuesit duhet të informojnë zhvilluesit për gabimet e pranishme në softuer, në mënyrë që ata të kenë kohë të mjaftueshme për t’i rregulluar ato përpara lëshimit.
Ekipi i testimit përdor gjithashtu informacionin për të përcaktuar se si të përmirësojnë proceset e tyre formale të testimit.
6. Ritestimi sipas nevojës
Ekipi i testimit ka të ngjarë të përsërisë procesin ad-hoc për përsëritjet e reja të aplikacionit për të kontrolluar se sa mirë i trajton përditësimet. Meqenëse testuesit do të kenë rregulluar shumë nga mangësitë e identifikuara më parë në rastet e tyre të testimit, kontrollet e ardhshme ad-hoc mund të kërkojnë një qasje të ndryshme.
Praktikat më të mira për testimin ad-hoc
Ekzistojnë disa praktika që ekipet e testimit duhet të zbatojnë gjatë testimit ad-hoc, duke përfshirë:
1. Synoni boshllëqet e mundshme të testimit
Ndërsa testimi ad-hoc përfshin shumë më pak planifikim sesa llojet e tjera, ekipi ende synon të adresojë mangësitë në sigurimin e cilësisë. Nëse testuesit ad-hoc dyshojnë për ndonjë problem specifik me rastet e testimit të ekipit, ata duhet t’i japin përparësi kësaj gjatë kryerjes së kontrolleve të tyre.
2. Merrni parasysh softuerin e automatizimit
Strategjitë e automatizimit si hiperautomatizimi mund të ofrojnë shumë përfitime për kompanitë që dëshirojnë të kryejnë teste ad-hoc.
Suksesi i kësaj varet nga disa faktorë kyç, duke përfshirë mjetin që zgjedh biznesi, si dhe kompleksitetin e përgjithshëm të testeve të tyre ad-hoc.
3. Merrni shënime gjithëpërfshirëse
Mungesa e dokumentacionit në testimin ad-hoc është kryesisht për të përmirësuar këtë proces edhe më tej – ekipi mund të përfitojë nga mbajtja e shënimeve joformale ndërsa vazhdojnë. Kjo u jep testuesve një rekord të qartë të këtyre kontrolleve dhe rezultateve të tyre, duke rritur përsëritshmërinë e tyre të përgjithshme.
4. Vazhdoni të rafinoni testet
Testuesit ad-hoc përmirësojnë vazhdimisht qasjen e tyre për të marrë parasysh ndryshimet në strategjinë e testimit të ekipit. Kur shikojnë versionet më të reja të softuerit të kompanisë, për shembull, ata mund t’i rregullojnë këto kontrolle në përgjigje të rasteve të testimit formal më të ri dhe më gjithëpërfshirës.
7 Gabimet dhe Grackat në Zbatim
Testet Ad-Hoc
Ashtu si me çdo proces testimi, ekziston një gamë e gjerë gabimesh të mundshme për të cilat ekipi duhet të punojë për t’i shmangur, si p.sh.
1. Testues të papërvojë
Për të ruajtur ritmin e pritur të testimit ad-hoc, drejtuesi i ekipit duhet të caktojë testues bazuar në njohuritë dhe aftësitë që ata kanë. Ndërsa shumë forma të testimit mund të strehojnë staf të nivelit fillestar të sigurimit të cilësisë, kontrollet ad-hoc kërkojnë anëtarë të ekipit që e kuptojnë plotësisht softuerin; mundësisht me përvojë në kryerjen e këtyre testeve.
2. Kontrolle të pa fokusuara
Testimi ad-hoc mund të përmirësojë ndjeshëm mbulimin e testit për shkak të ritmit të tij më të shpejtë – ekipi nuk ka nevojë të plotësojë dokumentacion të gjerë para dhe pas çdo kontrolli.
Megjithatë, testuesit ad-hoc duhet të mbajnë ende një fokus të fortë; për shembull, ata mund të vendosin t’i japin përparësi disa komponentëve me një rrezik më të madh dështimi.
3. Nuk ka planifikim
Shmangia e çfarëdo plani mund të kufizojë efektivitetin e testimit ad-hoc. Pavarësisht natyrës së pastrukturuar të kësaj qasjeje, është e rëndësishme që ekipi të ketë një ide të përafërt se cilat teste duhet të kryejnë përpara se të fillojnë.
Koha është e kufizuar gjatë këtij procesi dhe të dish se si të vazhdosh mund të ofrojë shumë përfitime.
4. Tepër e strukturuar
Në anën e kundërt të spektrit, kjo qasje zakonisht mbështetet në mungesën e planifikimit pasi kjo i ndihmon testuesit të përmbysin në mënyrë aktive rastet e testimit dhe të gjejnë gabime të fshehura.
Testimi ad hoc njihet gjithashtu si testim i rastësishëm dhe detyrimi i një strukture mbi të mund të parandalojë që këto kontrolle të gjejnë gabime.
5. Nuk ka ndryshime afatgjata
Qëllimi i testimit ad-hoc është të identifikojë çdo dobësi në rastet e testimit të ekipit; kjo shqyrton strategjinë e tyre të përgjithshme po aq sa vetë softueri.
Megjithatë, kjo do të thotë se testet ad-hoc janë përgjithësisht efektive vetëm nëse ekipi përdor këtë informacion për të përmirësuar kontrollet e tyre formale me kalimin e kohës.
6. Të dhëna të papajtueshme
Pothuajse çdo formë e testimit kërkon një formë të të dhënave të simuluara për të vlerësuar se si përgjigjet aplikacioni; disa mjete i lejojnë testuesit të plotësojnë automatikisht një program me të dhëna simuluese .
Megjithatë, kjo mund të mos pasqyrojë se si një përdorues do të angazhohej me softuerin – kontrollet ad hoc kërkojnë grupe të dhënash që softueri ka të ngjarë të hasë.
7. Silos informacioni
Është thelbësore që testuesit dhe zhvilluesit të jenë në komunikim të vazhdueshëm me njëri-tjetrin, edhe nëse ky i fundit nuk është pjesë e procesit të testimit ad-hoc.
Kjo i ndihmon të gjithë të kuptojnë se cilat teste janë kryer – duke treguar veprimet e radhës që duhen ndërmarrë, duke parandaluar gjithashtu testuesit që të përsërisin pa nevojë kontrolle të caktuara.
Llojet e rezultateve nga testet ad-hoc
Kontrollet ad-hoc prodhojnë disa rezultate të dallueshme, duke përfshirë:
1. Rezultatet e testit
Testet individuale prodhojnë rezultate të ndryshme specifike për komponentin dhe qasjen e saktë të përfshirë – kjo mund të marrë shumë forma.
Zakonisht është përgjegjësi e testuesit të përcaktojë nëse rezultatet përbëjnë një gabim, megjithëse mungesa e dokumentacionit e bën të vështirë krahasimin e kësaj me pritjet e tyre. Ekipi ua kalon këto rezultate zhvilluesve nëse vërejnë ndonjë problem.
2. Regjistrat e testimit
Vetë softueri përdor një sistem të komplikuar të regjistrave të brendshëm për të monitoruar hyrjet e përdoruesve dhe për të nxjerrë në pah një numër problemesh të skedarëve ose bazës së të dhënave që mund të shfaqen.
Kjo mund të tregojë drejt një gabimi të brendshëm, duke përfshirë pjesën specifike të softuerit që shkakton problemin. Me këtë informacion, testuesit dhe zhvilluesit ad-hoc mund të trajtojnë çështjet që zbulojnë shumë më lehtë.
3. Mesazhe gabimi
Shumë kontrolle ad-hoc synojnë në mënyrë specifike të thyejnë softuerin dhe të ekspozojnë kufijtë e tij, që do të thotë se mesazhet e gabimit të aplikacionit janë një nga rezultatet më të zakonshme nga këto teste.
Duke shkaktuar qëllimisht mesazhe gabimi, ekipi mund të shfaqë atë që shikon përdoruesi mesatar i fundit sa herë që veprimet e papritura që ata ndërmarrin kanë një efekt negativ në funksionimin e programit.
Shembuj të testimit ad-hoc
Këtu janë tre skenarë testimi ad-hoc që tregojnë se si një ekip mund ta zbatojë atë për aplikacione të ndryshme:
1. Aplikacioni ueb i tregtisë elektronike
Nëse një kompani dëshiron të testojë një aplikacion në internet të bazuar në tregtinë elektronike, ajo mund të përdorë testimin ad-hoc – veçanërisht testimin e majmunëve – për të parë se sa mirë platforma trajton ndërveprimet e papritura të përdoruesve.
Testuesit mund të synojnë të shtyjnë çdo veçori në kufijtë e tyre, si p.sh. duke shtuar artikuj në shportën e tyre në sasi joreale ose duke u përpjekur të blejnë produkte që nuk janë në gjendje. Ata nuk janë të kufizuar nga rastet e testimit të ekipit dhe ka pak kufizime në të cilat kontrollet mund të kryejnë; testuesit madje mund të përpiqen të kryejnë blerjet duke përdorur URL të vjetëruara.
2. Aplikacion për desktop
Testuesit ad-hoc gjithashtu mund t’i zbatojnë këto teknika për aplikacionet e desktopit me një fokus të mundshëm në makina të ndryshme dhe sa mirë e përshtatin secili programin.
Anëtarët e ekipit mund t’i kryejnë këto kontrolle në mënyrë të përsëritur për të parë se si ndryshimi i cilësimeve të harduerit ose softuerit ndikon në performancën e përgjithshme të një aplikacioni. Për shembull, një kartë grafike specifike mund të luftojë për të shfaqur ndërfaqen.
Përndryshe, këta testues thjesht mund t’i japin programit të tyre të dhëna të pamundura dhe të shohin se si ai përgjigjet, si p.sh. nëse mund të shfaqë saktë mesazhet e gabimit që shpjegojnë problemin në mënyrë adekuate për përdoruesin përfundimtar.
3. Aplikacion celular
Një mënyrë që testuesit ad-hoc mund të ekzaminojnë një aplikacion celular është të testojnë protokollet e tij të sigurisë – ata mund të përpiqen të hyjnë drejtpërdrejt te mjetet e zhvillimit të aplikacionit, për shembull.
Ekipi mund të përpiqet të shohë nëse ata janë në gjendje të kryejnë veprime të paautorizuara duke gjetur zbrazëtira dhe shfrytëzime të përbashkëta; ata mund të kërkojnë në mënyrë specifike anëtarët e stafit me përvojë në sigurinë e aplikacioneve për ta lehtësuar këtë.
Kjo mund të përfshijë gjithashtu testimin në çift me zhvilluesit për shkak të njohurive të tyre në dizajnin e aplikacionit, duke lejuar një testues të thyejë softuerin dhe të tregojë saktësisht se ku mungon siguria e tij.
Llojet e gabimeve dhe defekteve të zbuluara
përmes Testimit Ad-Hoc
Kontrollet ad-hoc mund të zbulojnë shumë probleme me një program, të tilla si:
1. Gabime funksionale
Përdorimi i testimit ad-hoc për të ekzaminuar veçoritë themelore të një aplikacioni mund të zbulojë gabime serioze që ndikojnë në mënyrën se si përdoruesit përfundimtarë mund të angazhohen me të.
Për shembull, testimi i opsioneve të pagesave të një sajti të tregtisë elektronike nga majmuni do të ilustrojë kushtet që parandalojnë transaksionin.
2. Çështjet e performancës
Testuesit mund të punojnë në mënyrë specifike për të krijuar probleme të performancës në program – si p.sh. duke mbushur bazën e të dhënave me hyrje të ndryshme të spam-it.
Kjo mund të shfaqet si kohë e konsiderueshme e vonesës ose edhe paqëndrueshmëri e përgjithshme e softuerit, e cila ka të ngjarë të çojë në një përplasje (potencialisht në të gjithë sistemin).
3. Probleme të përdorshmërisë
Këto kontrolle gjithashtu mund të nxjerrin në pah gabimet me ndërfaqen dhe përvojën e përgjithshme të përdoruesit. Ndërfaqja e përdoruesit e një aplikacioni celular , për shembull, mund të paraqitet ndryshe në një sistem tjetër operativ ose rezolucionin e ekranit. Një ndërfaqe e dobët mund të çojë në vështirësitë e përdoruesve për të përdorur këtë aplikacion.
4. Të metat e sigurisë
Natyra e rastësishme e testimit ad-hoc e lejon atë të mbulojë një sërë shqetësimesh të zakonshme dhe të rralla të sigurisë; një testues mund t’i përdorë këto kontrolle për të gjetur dyert e pasme administrative të një programi.
Përndryshe, inspektimi i tyre mund të tregojë se softueri nuk ka enkriptim të të dhënave.
Metrikat e zakonshme të testimit ad-hoc
Testimi ad-hoc përdor metrika të ndryshme për të lehtësuar rezultatet e tij, duke përfshirë:
1. Efikasiteti i zbulimit të defekteve
Kjo metrikë shikon se sa efektiv është procesi i testimit në gjetjen e defekteve në secilën formë të testimit, duke përfshirë testimin ad-hoc. Efikasiteti i zbulimit të defekteve është përqindja e defekteve të zbuluara pjesëtuar me numrin total të çështjeve – duke treguar se sa efektive janë testet.
2. Shkalla e mbulimit të testit
Një funksion ndihmës i testimit ad-hoc është rritja e mbulimit duke kontrolluar komponentët në një mënyrë që rastet e testimit të mos merren parasysh. Kjo do të thotë që testuesit do të synojnë gjithashtu të rrisin rrënjësisht mbulimin e testit në çdo kontroll sa më shumë që të munden.
3. Kohëzgjatja totale e testit
Testimi ad-hoc është shumë më i shpejtë se proceset e tjera të sigurimit të cilësisë – dhe është thelbësore që testuesit të punojnë për të ruajtur këtë avantazh. Metrikat e kohëzgjatjes së testit u tregojnë anëtarëve të ekipit se si mund të kursejnë kohë dhe t’i ndërlikojnë edhe më tej avantazhet e strategjive ad-hoc.
4. Shkalla e përplasjes
Këto teste shpesh synojnë të prishin softuerin dhe të shkaktojnë një përplasje ose gabim serioz – duke i lënë ata të shkojnë përtej strategjive tipike të testimit dhe të gjejnë probleme të papritura. Për këtë qëllim, mund të ndihmojë të dihet se sa shpesh rrëzohet softueri dhe çfarë i shkakton këto probleme.
5 Mjetet më të mira të testimit ad-hoc
Ka shumë mjete testimi falas dhe me pagesë në dispozicion për testimin ad-hoc në testimin e softuerit – pesë më të mirët janë si më poshtë:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST është një program gjithëpërfshirës i testimit të softuerit që ofron një nivel të fortë funksionaliteti test + RPA si në versionet e tij falas ashtu edhe në ato të ndërmarrjes.
Ky automatizim i plotë i softuerit + RPA Suite lejon testimin e plotë në platforma të ndryshme desktop dhe celular; Teknologjia 1SCRIPT e softuerit gjithashtu i lejon përdoruesit të kryejnë të njëjtat kontrolle në mënyrë të përsëritur me lehtësi. Për më tepër, mjeti përdor vizionin kompjuterik të teknologjisë së fundit , gjë që bën të mundur që ZAPTEST të kryejë teste ad-hoc nga një këndvështrim njerëzor.
2. BrowserStack
BrowserStack është një platformë cloud që mund të lehtësojë testimin në mbi 3000 makina të ndryshme, me veçorinë shtesë të automatizimit të skripteve Selenium. Megjithëse ofron mbulim të fortë për projektet softuerike, ai funksionon më së miri me shfletuesin dhe aplikacionet celulare .
Zgjidhjet e testimit të BrowserStack përfshijnë gjithashtu një provë falas me 100 minuta testim të automatizuar – megjithëse kjo mund të ketë përdorim të kufizuar.
Megjithëse qasja e bazuar në renë kompjuterike mund të jetë e dobishme, ajo gjithashtu ndikon negativisht në kohën e përgjigjes së platformës.
3. LambdaTest
LambdaTest përdor në mënyrë të ngjashme teknologjinë e bazuar në renë kompjuterike dhe vendos një theks të fortë në testimin e shfletuesit, i cili mund të kufizojë efektivitetin e tij për aplikacionet e tjera – megjithëse ai ende lidhet mirë me programet iOS dhe Android . Kjo është një platformë e dobishme kur shkallëzueshmëria është një shqetësim dhe integrohet me shumë shërbime të tjera të pritjes së testit.
Megjithatë, disa përdorues kanë reagime të përziera ndaj çmimit të aplikacionit në opsionet e ndryshme jo-provuese që janë të disponueshme, duke kufizuar potencialisht aksesin për organizatat më të vogla.
4. TestRail
TestRail në përgjithësi është mjaft i adaptueshëm për shkak të funksionimit tërësisht në shfletues dhe, megjithë një fokus të fortë në rastet e testimit efikas, gjithashtu krenohet me funksionalitetin e drejtpërdrejtë ad-hoc. Analitika që ofron pas çdo testi mund të ndihmojë gjithashtu ekipet që shmangin në mënyrë aktive krijimin e dokumentacionit të tyre të pavarur, duke i lënë ende të vërtetojnë procesin e tyre të testimit.
Sidoqoftë, paketat më të mëdha mund të luftojnë me formatin e tij të bazuar në shfletues, gjë që mund të kufizojë kursimet e kohës së testimit ad-hoc me një diferencë të konsiderueshme.
5. Zefir
Zephyr është një platformë e menaxhimit të testeve nga SmartBear që ndihmon ekipet e sigurimit të cilësisë të përmirësojnë dukshmërinë e tyre të testimit duke u integruar gjithashtu mirë me softuerët e tjerë të gjurmimit të gabimeve.
Megjithatë, kjo veçori është e kufizuar në disa aplikacione, ku Confluence dhe Jira janë ato që përfitojnë më shumë nga Zephyr – këto mund të mos jenë zgjidhjet më efektive për çdo biznes. Ka disa programe të shkallëzueshme të disponueshme nën markën Zephyr me çmime të ndryshme.
Lista kontrolluese e testimit ad-hoc, këshilla dhe truket
Këtu janë këshilla shtesë për ekipet që duhet të marrin parasysh kur kryejnë testime ad-hoc:
1. Jepini përparësi komponentëve të ndjeshëm
Disa veçori ose komponentë janë natyrisht më të rrezikuar nga gabimi se të tjerët, veçanërisht nëse janë të rëndësishëm për funksionin e përgjithshëm të programit.
Çdo qasje ndaj testimit duhet të identifikojë pjesët e një aplikacioni që mund të përfitojnë nga një vëmendje më e plotë. Kjo është veçanërisht e dobishme kur koha e përgjithshme për testim është e kufizuar.
2. Hetoni mjete të ndryshme testimi
Mjeti që një organizatë zbaton për të lehtësuar testet e saj mund të ndikojë në mbulimin dhe besueshmërinë e këtyre kontrolleve.
Me testimin ad-hoc, ia vlen të shikoni sa më shumë programe që të jetë e mundur për të gjetur ato që i përshtaten aspektit të tij në qendër të përdoruesit. Softueri që përdor teknologjinë e vizionit kompjuterik, si ZAPTEST, mund t’i qaset testeve ad-hoc duke përdorur një strategji të ngjashme me njeriun.
3. Mirato një mentalitet ad-hoc
Testimi ad-hoc ofron liri të jashtëzakonshme gjatë gjithë fazës së sigurimit të cilësisë, por ekipi duhet të angazhohet për të për të marrë përfitimet kryesore të strategjisë.
Për shembull, testuesit ad-hoc duhet të shmangin të gjitha dokumentet e tyre të zakonshme përtej mbajtjes së shënimeve bazë dhe ata duhet të inspektojnë softuerin nga një këndvështrim krejtësisht i ri.
4. Besoni instinktet e testimit
Përvoja me testimin ad-hoc ose kontrollet e përgjithshme të softuerit mund të ndihmojë në nënvizimin e pikave të zakonshme të dështimit dhe kjo i ndihmon testuesit të përcaktojnë se si të dallojnë gabimet e të gjitha llojeve.
Është jetike që testuesit t’i besojnë instinkteve të tyre dhe ta përdorin gjithmonë këtë njohuri në avantazhin e tyre – ata mund të kuptojnë se cilat kontrolle ad-hoc do të ishin më të dobishme.
5. Regjistroni plotësisht gabimet e zbuluara
Megjithëse testimi ad-hoc nuk ka dokumentacion formal dhe kryesisht mbështetet në shënime joformale, është ende thelbësore që ekipi të jetë në gjendje të identifikojë dhe të komunikojë shkakun e një gabimi softuerësh.
Ata duhet të regjistrojnë çdo informacion që ofron testi që është i rëndësishëm për zhvilluesit, si për shembull çdo shkak të mundshëm të këtyre problemeve.
6. Gjithmonë llogari për përdoruesin
Çdo formë e testimit synon të akomodojë përvojën e përgjithshme të përdoruesit në një farë mase – dhe testimi ad-hoc nuk bën përjashtim. Megjithëse shpesh shikon më thellë në funksionimin e brendshëm të aplikacionit dhe madje edhe kodin e tij të brendshëm, testuesit ad-hoc duhet të përpiqen ta thyejnë këtë softuer në mënyra që përdoruesit teorikisht munden.
7. Përmirësoni vazhdimisht procesin
Ekipet e testimit duhet të përsosin qasjen e tyre ndaj testimit ad-hoc ndërmjet përsëritjeve të shumta të të njëjtit softuer dhe nga një projekt në tjetrin.
Ata mund të mbledhin reagime nga zhvilluesit për të parë se sa mirë ndihmuan testet e tyre ad-hoc në fazën e sigurimit të cilësisë dhe nëse ishin në gjendje të rrisnin ndjeshëm mbulimin e testeve.
konkluzioni
Testimi ad-hoc mund të ndihmojë organizatat e të gjitha llojeve të vërtetojnë strategjinë e tyre të testimit të softuerit, por mënyra se si e zbatojnë këtë teknikë mund të jetë një faktor i rëndësishëm në efektivitetin e saj.
Balancimi i llojeve të ndryshme të testimit është çelësi për të përfituar sa më shumë nga kontrollet ad-hoc – veçanërisht pasi kjo formë testimi synon të plotësojë të tjerat duke mbushur një boshllëk strategjik.
Me një aplikacion të tillë si ZAPTEST, është e mundur që ekipet të kryejnë teste ad-hoc me besim ose fleksibilitet më të madh, veçanërisht nëse zbatojnë automatizimin. Pavarësisht qasjes specifike të ekipit, angazhimi i tyre ndaj testimit ad-hoc mund të revolucionarizojë të gjithë programin ose projektin.
