Ad-hoc testēšana ir programmatūras testēšanas veids, ko izstrādātāji un programmatūras uzņēmumi īsteno, pārbaudot programmatūras pašreizējo iterāciju. Šāda veida testēšana sniedz plašāku ieskatu programmā, ļaujot atklāt problēmas, kuras parastā testēšana varētu nespēt izcelt.
Ir ļoti svarīgi, lai testēšanas komandām būtu pilnīga izpratne par ad hoc testēšanas procesu, lai tās zinātu, kā apiet tā problēmas, un pārliecinātos, ka komanda var veiksmīgi īstenot šo metodi.
Zinot, kā tieši darbojas ad-hoc testēšana un kādi rīki var atvieglot tās īstenošanu, uzņēmums var nepārtraukti uzlabot savas kvalitātes nodrošināšanas procedūras. Formālā testēšanas procesā tiek ievēroti ļoti konkrēti noteikumi, kuru dēļ komanda var nepamanīt dažas kļūdas – ad-hoc pārbaudes var apiet šīs “aklās zonas” un ātri pārbaudīt katru programmatūras funkciju.
Šajā rakstā sīkāk aplūkosim ad-hoc testēšanu un to, kā to izmantot savā labā, izstrādājot programmatūras produktu.
Ad-Hoc testēšanas nozīme: Kas ir Ad-Hoc testēšana?
Ad-hoc testēšana ir kvalitātes nodrošināšanas process, kas ļauj izvairīties no formāliem noteikumiem un dokumentācijas, palīdzot testētājiem atrast kļūdas lietojumprogrammā, kuras nevar identificēt ar parasto pieeju. Pirms testēšanas sākuma parasti ir nepieciešamas vispusīgas zināšanas par programmatūru, tostarp izpratne par programmas iekšējo darbību. Šo ad-hoc pārbaužu mērķis ir izjaukt lietojumprogrammu tādā veidā, kas atspoguļo lietotāja ievadi, ņemot vērā dažādas iespējamās situācijas, lai izstrādātāji varētu labot visas esošās problēmas.
Dokumentācijas trūkums ir galvenais šīs metodes aspekts, kas neietver kontrolsarakstus vai testēšanas gadījumus, lai vadītu testētājus pa lietojumprogrammas funkcijām. Ad-hoc testēšana ir saistīta ar programmatūras testēšanu tādā veidā, kādu komanda uzskata par efektīvu konkrētajā brīdī. Šajā procesā var ņemt vērā jau esošos oficiālos testus, bet var arī vienkārši veikt pēc iespējas vairāk testu (iespējams, ierobežotā) laikā, kas atvēlēts šai metodei.
1. Kad un kāpēc programmatūras testēšanā ir nepieciešams veikt Ad-Hoc testēšanu?
Galvenais iemesls, kāpēc uzņēmumi veic ad-hoc testēšanu, ir tās spēja atklāt kļūdas, ko tradicionālās pieejas nespēj atrast. Tas var notikt dažādu iemeslu dēļ, piemēram, ja parastie testēšanas gadījumi tiek veikti pēc īpaši standartizēta procesa, kurā nevar ņemt vērā lietojumprogrammas īpatnības.
Katrs testēšanas veids var piedāvāt jaunas perspektīvas un interesantas pieejas kvalitātes nodrošināšanai – tas parāda arī problēmas ar parasto testēšanas stratēģiju. Piemēram, ja ad-hoc testēšana var identificēt problēmu, ko komandas testēšanas gadījumi nerisina, tas liecina, ka komandai būtu lietderīgi pārkalibrēt testēšanas metodoloģiju.
Testētāji var veikt ad-hoc pārbaudes jebkurā testēšanas procesa posmā. Tas parasti kalpo kā papildinājums tradicionālajai (un formālākai) kvalitātes nodrošināšanai, un, ņemot to vērā, testētāji var veikt ad-hoc pārbaudes, kamēr viņu kolēģi veic formālākas pārbaudes. Tomēr tā vietā viņi var dot priekšroku ad-hoc pārbaudēm, kas tiek veiktas pēc oficiālā testēšanas procesa, lai veiktu turpmākus pasākumus, kas īpaši vērsti uz iespējamām “aklajām zonām”.
Ad-hoc testēšana var būt noderīga arī tad, ja dokumentācijas trūkuma dēļ laiks ir īpaši ierobežots – pareizais laiks ir atkarīgs no uzņēmuma un tā izvēlētās pieejas.
2. Kad nav jāveic Ad-Hoc testēšana
Ja nav pietiekami daudz laika, lai veiktu gan ad hoc, gan formālo testēšanu, ir svarīgi, lai komanda piešķirtu prioritāti pēdējai, jo tā nodrošina būtisku testēšanas pārklājumu, pat ja joprojām ir dažas nepilnības.
Ja komandas formālajos testos tiek atklātas kļūdas, kuras nepieciešams novērst, parasti ir labāk pagaidīt, līdz izstrādātāji pabeigs nepieciešamās izmaiņas, lai veiktu ad hoc pārbaudes. Pretējā gadījumā to sniegtie rezultāti drīz var kļūt neaktuāli, jo īpaši, ja testi attiecas uz komponentu, kurā jau ir konstatētas kļūdas.
Turklāt pirms beta testēšanas posma jāveic ad-hoc testēšana.
3. Kas ir iesaistīts Ad-Hoc testēšanā?
Ad-Hoc testēšanas procesā ir iesaistītas vairākas galvenās lomas, tostarp:
– Programmatūras testētāji ir galvenie komandas locekļi, kas veic ad hoc pārbaudes. Ja tiek veikta testēšana draugu vai pāru grupās, vairāki no šiem testētājiem strādā kopā pie vieniem un tiem pašiem komponentiem.
– Izstrādātāji var patstāvīgi izmantot šīs pārbaudes pirms oficiālā kvalitātes nodrošināšanas posma, lai ātri pārbaudītu savu programmatūru, lai gan tas ir mazāk padziļināti nekā speciālā ad hoc testēšana.
– Komandas vai nodaļas vadītāji apstiprina vispārējo testēšanas stratēģiju, palīdzot testētājiem noteikt, kad sākt ad hoc testēšanu un kā to veikt, netraucējot citām pārbaudēm.
Ad-Hoc testēšanas priekšrocības
Ad-hoc testēšanas priekšrocības programmatūras testēšanā ir šādas:
1. Ātras rezolūcijas
Tā kā šie testi neprasa biežu dokumentēšanu pirms, pārbaudes laikā vai pēc tās, komandām ir iespējams daudz ātrāk identificēt problēmas. Šī vienkāršība sniedz milzīgu brīvību testētājiem.
Piemēram, ja komanda testē kādu komponentu un nespēj identificēt kļūdas, tā var vienkārši pāriet pie nākamā testa, nefiksējot to dokumentā.
2. Papildina citus testēšanas veidus
Neviena testēšanas stratēģija nav perfekta, un 100% pārklājumu parasti nav iespējams sasniegt pat ar visaptverošu grafiku. Tradicionālajā testēšanā vienmēr būs nepilnības, tāpēc ir svarīgi, lai uzņēmumi integrētu vairākas pieejas.
Ad-hoc testēšanas mērķis ir atrast problēmas, kuras formālā testēšana nespēj aptvert, tādējādi garantējot plašāku kopējo testēšanas pārklājumu.
3. Elastīga izpilde
Ad-hoc testēšanu var veikt jebkurā kvalitātes nodrošināšanas procesa posmā pirms beta testēšanas, ļaujot uzņēmumiem un komandām izlemt, kad vislabāk veikt šīs pārbaudes. Viņi var izvēlēties veikt ad-hoc testus vienlaikus ar parasto testēšanu vai arī pagaidīt, kamēr tiks veikta testēšana – neatkarīgi no tā, kādas iespējas ir viņu rīcībā, komanda gūst labumu.
4. Plašāka sadarbība
Izstrādātāji ir vairāk iesaistīti šajā procesā nekā daudzos citos testēšanas veidos – īpaši, ja uzņēmums izmanto draugu un pāru testēšanu.
Rezultātā izstrādātāji gūst labāku ieskatu savās lietojumprogrammās un, iespējams, var labāk novērst kļūdas. Tas palīdz vēl vairāk uzlabot programmatūras kopējo kvalitāti.
5. Dažādas perspektīvas
Ad-hoc testēšana var parādīt lietojumprogrammu no jauniem skatupunktiem, palīdzot testētājiem izmantot šīs funkcijas jaunā veidā. Papildu perspektīvas ir ļoti svarīgas visā testēšanas laikā, jo formālajās pārbaudēs bieži vien ir vismaz nelielas nepilnības.
Ja ad-hoc testētāji izmantos programmatūru ar konkrētu nolūku to bojāt, viņiem būs vieglāk noteikt programmas ierobežojumus.
Ad-Hoc testēšanas problēmas
Ad-hoc testēšanas procesam ir arī vairāki izaicinājumi, piemēram:
1. Grūtības ar ziņošanu
Dokumentācijas trūkums padara ad-hoc testēšanu daudz ātrāku, bet var arī apgrūtināt ziņošanu par jebkuru citu problēmu, kas nav būtiska.
Piemēram, kāda iepriekš veikta pārbaude vēlāk var kļūt nozīmīgāka, lai gan sākotnēji tā nav devusi būtiskus rezultātus. Bez visaptverošas dokumentācijas komanda, iespējams, nespēs izskaidrot šos testus.
2. Mazāk atkārtojams
Līdzīgi, testētāji var pilnībā nezināt precīzus nosacījumus, kas nepieciešami, lai izraisītu novērotās reakcijas. Piemēram, ad-hoc pārbaudei, kas atgriež kļūdu, var nebūt pietiekamas informācijas, lai komanda varētu rīkoties. Iespējams, viņi nezina, kā atkārtot šo testu un iegūt tādu pašu rezultātu.
3. Nepieciešama programmatūras lietošanas pieredze
Tā kā ad-hoc testēšanā galvenais ir ātrums un tā parasti ietver mēģinājumus lauzt lietojumprogrammu, ir svarīgi, lai šie testētāji labi pārzina šo programmu.
Zinot, kā tā darbojas, testētājiem ir iespējams programmatūru lauzt un manipulēt ar to vairākos veidos, taču tas var ievērojami palielināt ad-hoc testēšanas prasmju prasības.
4. Ierobežota pārskatatbildība
Dokumentācijas trūkums var radīt ne tikai sliktus ziņojumus, bet arī netīši paildzināt testēšanas procesu, ietekmējot atsevišķu ātru ad hoc testu lietderību.
Testētājiem var būt grūti sekot līdzi savam progresam, ja katrā posmā nav pietiekamas dokumentācijas. Tas var pat novest pie tā, ka viņi atkārto pārbaudi, ko citi testētāji jau ir veikuši.
5. Var neatspoguļot lietotāja pieredzi
Praktiski visu veidu testēšanas mērķis ir noteikt kļūdas, kas kaut kādā veidā ietekmē galalietotājus. Ad-hoc testēšana galvenokārt balstās uz pieredzējuša testētāja mēģinājumiem imitēt nepieredzējušu lietotāju, un tam ir jābūt konsekventam katrā pārbaudē, ieskaitot mēģinājumus lauzt lietojumprogrammu.
Ad-Hoc testu raksturojums
Galvenās veiksmīgu ad-hoc testu pazīmes ir šādas:
1. Izmeklēšana
Ad-hoc testēšanas galvenā prioritāte ir identificēt kļūdas lietojumprogrammā, izmantojot paņēmienus, kurus parastās pārbaudes neņem vērā. Ad-hoc pārbaudes izskata šo programmatūru ar mērķi atrast nepilnības komandas testēšanas procedūrā, tostarp testēšanas gadījumu pārklājumu.
2. Nestrukturēts
Ad hoc pārbaudēm parasti nav noteikta plāna, izņemot pēc iespējas vairāk pārbaužu veikšanu ārpus tipiskajām formālās kvalitātes nodrošināšanas robežām. Testētāji parasti ērtības labad pārbaudes sagrupē pa komponentiem, taču tas nav obligāti – viņi var pat izdomāt pārbaudes to veikšanas laikā.
3. Uz pieredzi balstīta
Ad-hoc testētāji izmanto savu iepriekšējo pieredzi programmatūras jomā, lai novērtētu, kuri testi sniegs vislielāko labumu un novērsīs biežāk sastopamos trūkumus formālajā testēšanā.
Lai gan testēšanas process joprojām ir pilnībā nestrukturēts, lemjot par savu stratēģiju, testētāji cita starpā izmanto savas zināšanas par iepriekšējām ad hoc pārbaudēm.
4. Plaša darbības joma
Nav precīzu norādījumu par to, kādas pārbaudes komandai būtu jāveic ad-hoc testēšanas laikā, taču parasti tās aptver virkni komponentu, iespējams, lielāku uzmanību pievēršot jutīgākiem lietojumprogrammas aspektiem. Tas palīdz testētājiem garantēt, ka viņu pārbaudes var pilnībā papildināt formālo testēšanu.
Ko mēs testējam Ad-Hoc testos?
Kvalitātes nodrošināšanas komandas ad-hoc testēšanas laikā parasti testē:
1. Programmatūras kvalitāte
Šo pārbaužu mērķis ir identificēt kļūdas lietojumprogrammā, kuras parastā testēšana nespēj atklāt; tas nozīmē, ka šajā procesā galvenokārt tiek pārbaudīta lietojumprogrammas vispārējā darbība.
Jo vairāk kļūdu var atrast ad-hoc testēšanā, jo vairāk uzlabojumu izstrādātāji var ieviest pirms termiņa beigām.
2. Testēšanas gadījumi
Ad-hoc testēšanā parasti netiek ieviesti testēšanas gadījumi – un tas ir tieši tāpēc, lai komanda varētu izpētīt, cik efektīvi tie nodrošina plašu pārklājumu. Testēšanas gadījumi, visticamāk, nav atbilstoši, ja ad-hoc pārbaudēs var atrast kļūdas, ko parastie testēšanas procesi nevar atrast.
3. Testēšanas personāls
Mērķis varētu būt arī pārbaudīt testēšanas komandas prasmes un zināšanas, pat ja testa gadījumi ir atbilstoši. Piemēram, to gadījumu īstenošanas metodoloģija var būt nepietiekama, un ad hoc testēšana var būt kritiski svarīga, lai novērstu radušās nepilnības testu pārklājumā.
4. Programmatūras ierobežojumi
Ad-hoc testēšanas mērķis ir arī izprast lietojumprogrammas ierobežojumus, piemēram, kā tā reaģē uz negaidītiem ievades datiem vai lielu sistēmas slodzi. Testētāji varētu īpaši izpētīt programmas kļūdu ziņojumus un to, cik labi šī lietojumprogramma darbojas, kad tā ir pakļauta ievērojamam spiedienam.
Dažu neskaidrību noskaidrošana:
Ad-Hoc testēšana un izpētes testēšana
Daži cilvēki uzskata, ka ad-hoc un izpētes testēšana ir sinonīmi, tomēr patiesība ir sarežģītāka.
1. Kas ir izpētes testēšana?
Izpētes testēšana attiecas uz kvalitātes nodrošināšanas procedūrām, kas pēta programmatūru no holistiska viedokļa un apvieno atklāšanas un testēšanas procesus vienā metodē. Tas parasti ir vidusceļš starp pilnībā strukturētu testēšanu un pilnīgi brīvas formas ad-hoc pārbaudēm.
Izpētes testēšana vislabāk darbojas īpašos scenārijos, piemēram, ja nepieciešama ātra atgriezeniskā saite vai ja komandai jārisina galējie gadījumi. Šāda veida testēšana parasti sasniedz pilnu potenciālu, ja komanda līdztekus testēšanai izmanto skriptu testēšanu.
2. Atšķirības starp izpētes testēšanu
un Ad-Hoc testēšana
Lielākā atšķirība starp ad-hoc un izpētes testēšanu ir tā, ka ad-hoc testēšanā tiek izmantota dokumentācija, lai reģistrētu un atvieglotu pārbaudes, bet ad-hoc testēšanā tas tiek pilnībā novērsts. Izpētes testēšanā lielāks uzsvars tiek likts uz testēšanas brīvību, taču tā nekad nav tikpat liela kā ad-hoc pieeja, kas ir pilnībā nestrukturēta.
Izpētes testēšana ietver arī lietojumprogrammas un tās iekšējās darbības iepazīšanu šo pārbaužu laikā – tā vietā ad-hoc testētājiem bieži vien ir visaptverošas zināšanas par programmatūras funkcionalitāti, pirms viņi uzsāk pārbaudi.
Ad-Hoc testu veidi
Programmatūras testēšanā ir trīs galvenie ad-hoc testēšanas veidi, tostarp:
1. Testēšana ar pērtiķiem
Iespējams, vispopulārākais ad-hoc testēšanas veids ir “pērtiķa” testi, kuros komanda izlases veidā pārbauda dažādus komponentus.
Tas parasti notiek vienības testēšanas procesa laikā, un tiek veikta virkne pārbaužu bez testēšanas gadījumiem. Testētāji patstāvīgi pārbauda datus pilnīgi nestrukturētos veidos, ļaujot viņiem pārbaudīt plašāku sistēmu un tās spēju izturēt intensīvu lietotāja ievades slodzi.
Šo neskriptēto metožu rezultātu novērošana palīdz testēšanas komandai identificēt kļūdas, kuras citi vienības testi ir palaiduši garām parasto testēšanas metožu trūkumu dēļ.
2. Biedru testēšana
Ad-hoc kontekstā draugu testos izmanto vismaz divus darbiniekus – parasti testētāju un izstrādātāju – un tie galvenokārt tiek veikti pēc vienības testēšanas posma. “Draugi” strādā kopā ar vienu un to pašu moduli, lai precīzi noteiktu kļūdas. Viņu daudzveidīgās prasmes un plašā pieredze padara viņus par efektīvāku komandu, kas palīdz mazināt daudzas problēmas, kuras rodas dokumentācijas trūkuma dēļ.
Izstrādātājs var pat pats ieteikt vairākus testus, ļaujot noteikt komponentus, kuriem, iespējams, būtu jāpievērš lielāka uzmanība.
3. Pāru testēšana
Pāru testēšana ir līdzīga, jo tajā piedalās divi darbinieki, taču parasti tie ir divi atsevišķi testētāji, no kuriem viens veic faktiskos testus, bet otrs pieraksta piezīmes.
Pat bez oficiālas dokumentācijas, piezīmju pieraksti var ļaut komandai neformāli sekot līdzi atsevišķām ad hoc pārbaudēm. Testētāja un rakstveža lomas var mainīties atkarībā no testa, vai arī pāris var saglabāt piešķirtās lomas visa procesa laikā.
Faktiskās pārbaudes parasti veic tas testētājs, kuram ir lielāka pieredze, lai gan viņi vienmēr dalās darbā viens ar otru.
Manuāli vai automatizēti Ad-Hoc testi?
Automatizēta testēšana var palīdzēt komandām ietaupīt vēl vairāk laika visā kvalitātes nodrošināšanas posmā, kas ļauj testētājiem iekļaut vairāk pārbaužu savā grafikā. Pat bez noteiktas struktūras ir svarīgi, lai testētāji strādātu, lai maksimāli palielinātu pārklājumu, un automatizācija veicina padziļinātākas šīs programmatūras pārbaudes.
Automatizētas ad-hoc pārbaudes parasti ir precīzākas nekā manuāli veiktie testi, jo tās ļauj izvairīties no cilvēka kļūdām, veicot atkārtotus uzdevumus – tas ir īpaši noderīgi, ja vienus un tos pašus testus veic dažādās iterācijās. Šīs procedūras panākumi parasti ir atkarīgi no komandas izvēlētā automatizētās testēšanas rīka un tā funkcionalitātes.
Tomēr automatizētai testēšanai ir zināmi ierobežojumi. Piemēram, ad-hoc testēšanas galvenā priekšrocība ir tās spēja imitēt lietotāja ievadi un veikt izlases veida pārbaudes, kad testētājs tās izdomā. Šie testi var zaudēt savu nejaušību, ja organizācijas testēšanas programma saskaras ar sarežģītām pārbaudēm.
Laiks, kas nepieciešams, lai automatizētu šos ļoti specifiskos uzdevumus, var arī ierobežot šā procesa tipisko laika ietaupījumu. Ir svarīgi, lai komandas rūpīgi izpētītu pieejamos automatizācijas rīkus un atrastu to, kas atbilst uzņēmuma projektam.
Kas nepieciešams, lai sāktu Ad-Hoc testēšanu?
Šeit ir izklāstīti galvenie ad-hoc testēšanas priekšnoteikumi:
1. Kvalificēts personāls
Tā kā ad-hoc testi ir ātras, nejaušas programmatūras iekšējās darbības pārbaudes, parasti ir noderīgi, ja testētājiem ir pieredze ar programmatūru. Viņiem ir jābūt arī zināšanām par galvenajiem testēšanas principiem – tas ļauj viegli noteikt visefektīvākās pārbaudes.
2. Nestrukturēta pieeja
Testētājiem ir jābūt gataviem atteikties no savām ierastajām ad-hoc testēšanas stratēģijām; šāds domāšanas veids ir tikpat svarīgs kā pašas kvalitātes pārbaudes. Šī metode var būt veiksmīga tikai bez struktūras vai dokumentācijas, un ir ļoti svarīgi, lai testētāji to atcerētos katrā posmā.
3. Automatizācijas programmatūra
Lai gan ad-hoc testēšana vairāk balstās uz nejaušu ievades datu un nosacījumu testēšanu, automatizācija joprojām ir ļoti efektīva metode jebkurā kontekstā.
Šā iemesla dēļ ad-hoc pārbaudēs, ja iespējams, joprojām vajadzētu izmantot automatizētus testēšanas rīkus, jo pareizā lietojumprogramma var ievērojami racionalizēt procesu.
4. Citi testēšanas veidi
Ad-hoc testi vislabāk darbojas līdztekus citām pārbaudēm, kurās tiek izmantota formālāka pieeja, palīdzot komandai garantēt būtisku programmatūras pārklājumu. Ir ļoti svarīgi, lai testētāji apvienotu dažādas metodes, lai gan tas var notikt pirms, testēšanas laikā vai pēc tam, kad ir pabeigta ad-hoc testēšana.
Ad-Hoc testēšanas process
Veicot ad-hoc testēšanu programmatūras testēšanā, testētājiem parasti jāveic šādi pasākumi:
1. Ad-hoc testu mērķu definēšana
Šis posms ir ierobežots dokumentācijas un struktūras trūkuma dēļ, taču joprojām ir ļoti svarīgi, lai komandai būtu skaidrs mērķis. Testētāji var sākt dalīties neskaidros priekšstatos par to, kuri testi jāveic un kurām sastāvdaļām jāpiešķir prioritāte.
2. Ad-hoc testēšanas grupas atlase
Kad komanda izstrādā vairākas iespējamās ad-hoc pārbaudes, tā arī noskaidro, kuri testētāji būtu vispiemērotākie šāda veida testēšanai. Viņi parasti izvēlas testētājus, kas labi izprot lietojumprogrammu, un var arī savienot viņus ar izstrādātāju.
3. Ad-hoc testu veikšana
Pēc tam, kad ir nolemts, kuri testētāji ir piemēroti šim posmam, šie komandas locekļi sāk pārbaudes saskaņotā testēšanas posmā. Viņu mērķis ir veikt pēc iespējas vairāk ad hoc pārbaužu, kuras testētāji var neizdomāt līdz šim posmam.
4. Testa rezultātu novērtēšana
Pabeidzot testus (vai pat starp atsevišķām pārbaudēm), testētāji izvērtē rezultātus, bet formāli tos nedokumentē testa gadījumā. Ja viņi atklāj kādas problēmas saistībā ar pieteikumu, viņi tās neoficiāli reģistrē un apspriež komandas turpmākos soļus.
5. Ziņošana par atklātajām kļūdām
Pēc rezultātu izvērtēšanas testētājiem ir jāinformē izstrādātāji par programmatūrā esošajām kļūdām, lai viņiem būtu pietiekami daudz laika tās novērst pirms izlaišanas.
Testēšanas komanda šo informāciju izmanto arī, lai noteiktu, kā uzlabot formālos testēšanas procesus.
6. Vajadzības gadījumā atkārtota testēšana
Testēšanas komanda, visticamāk, atkārtos ad-hoc procesu jaunām lietojumprogrammas iterācijām, lai pārbaudītu, cik labi lietojumprogramma darbojas ar atjauninājumiem. Tā kā testētāji būs novērsuši daudzus iepriekš konstatētos trūkumus savos testēšanas gadījumos, turpmākajām ad-hoc pārbaudēm var būt nepieciešama cita pieeja.
Ad-Hoc testēšanas paraugprakse
Ad-hoc testēšanas laikā testēšanas komandām ir jāievieš noteikta prakse, tostarp:
1. Mērķtiecīga potenciālo testēšanas nepilnību novēršana
Lai gan ad-hoc testēšana ietver daudz mazāk plānošanas nekā citi testēšanas veidi, komanda joprojām cenšas novērst kvalitātes nodrošināšanas trūkumus. Ja ad-hoc testētājiem rodas aizdomas par kādām īpašām problēmām saistībā ar komandas testēšanas gadījumiem, veicot pārbaudes, viņiem tas jānosaka par prioritāti.
2. Apsveriet automatizācijas programmatūru
Automatizācijas stratēģijas, piemēram, hiperautomatizācija, var sniegt daudz priekšrocību uzņēmumiem, kas vēlas veikt ad-hoc testus.
Tas ir atkarīgs no vairākiem galvenajiem faktoriem, tostarp no uzņēmuma izvēlētā rīka, kā arī no tā, cik sarežģīti ir ad-hoc testi.
3. Veikt visaptverošas piezīmes
Dokumentācijas trūkums ad-hoc testēšanā galvenokārt ir paredzēts, lai vēl vairāk racionalizētu šo procesu – komanda varētu gūt labumu no neoficiālu piezīmju veikšanas procesa gaitā. Tādējādi testētāji var skaidri reģistrēt šīs pārbaudes un to rezultātus, tādējādi uzlabojot to vispārējo atkārtojamību.
4. Turpiniet pilnveidot testus
Ad-hoc testētāji nepārtraukti uzlabo savu pieeju, lai ņemtu vērā komandas testēšanas stratēģijas izmaiņas. Piemēram, aplūkojot jaunākas uzņēmuma programmatūras versijas, viņi var pielāgot šīs pārbaudes, reaģējot uz jaunākiem un visaptverošākiem formālajiem testu gadījumiem.
7 kļūdas un slazdi, ieviešot
Ad-Hoc testi
Tāpat kā jebkurā testēšanas procesā, arī šajā procesā pastāv virkne iespējamo kļūdu, no kurām komandai jācenšas izvairīties, piemēram:
1. Nepieredzējuši testētāji
Lai uzturētu gaidīto ad-hoc testēšanas tempu, komandas vadītājam jāpiešķir testētāji, pamatojoties uz viņu zināšanām un prasmēm. Lai gan daudzus testēšanas veidus var veikt iesācēju līmeņa kvalitātes nodrošināšanas darbinieki, ad-hoc pārbaudēm ir nepieciešami komandas locekļi, kas pilnībā izprot programmatūru; vēlams, ar pieredzi šo testu veikšanā.
2. Nefokusētas pārbaudes
Ad-hoc testēšana var ievērojami uzlabot testu pārklājumu, jo tā ir ātrāka – komandai nav jāaizpilda apjomīga dokumentācija pirms un pēc katras pārbaudes.
Tomēr ad-hoc testētājiem joprojām ir jāturpina mērķtiecīgi strādāt; piemēram, viņi var nolemt noteikt prioritāti konkrētām sastāvdaļām ar lielāku kļūmes risku.
3. Nav plānošanas
Izvairīšanās no jebkāda plāna var ierobežot ad-hoc testēšanas efektivitāti. Neraugoties uz šīs pieejas nestrukturēto raksturu, ir svarīgi, lai komandai būtu aptuvens priekšstats par veicamajiem testiem, pirms tie tiek uzsākti.
Laiks šajā procesā ir ierobežots, un zināšanas par to, kā rīkoties, var sniegt daudz priekšrocību.
4. Pārāk strukturēts
Pretējā gadījumā šī pieeja parasti balstās uz plānošanas trūkumu, jo tas palīdz testētājiem aktīvi apgāzt testēšanas gadījumus un atrast slēptās kļūdas.
Ad hoc testēšanu sauc arī par nejaušu testēšanu, un struktūras uzspiešana tai var novērst kļūdu atklāšanu šajās pārbaudēs.
5. Nav ilgtermiņa izmaiņu
Ad-hoc testēšanas mērķis ir identificēt komandas testēšanas gadījumu nepilnības; tādējādi tiek pārbaudīta gan vispārējā stratēģija, gan pati programmatūra.
Tomēr tas nozīmē, ka ad-hoc testi parasti ir efektīvi tikai tad, ja komanda izmanto šo informāciju, lai laika gaitā pilnveidotu formālās pārbaudes.
6. Nesaderīgas datu kopas
Praktiski visos testēšanas veidos ir nepieciešama simulētu datu forma, lai novērtētu, kā lietojumprogramma reaģē; daži rīki ļauj testētājiem automātiski aizpildīt programmu ar imitācijas datiem.
Tomēr tas var neatspoguļot to, kā lietotājs izmantos programmatūru – ad hoc pārbaudēm ir nepieciešamas datu kopas, ar kurām programmatūra, visticamāk, saskarsies.
7. Informācijas silosi
Ir svarīgi, lai testētāji un izstrādātāji pastāvīgi sazinātos savā starpā, pat ja izstrādātāji nav iesaistīti ad-hoc testēšanas procesā.
Tas palīdz ikvienam saprast, kuri testi ir veikti, norādot nākamās veicamās darbības, vienlaikus novēršot, ka testētāji nevajadzīgi atkārto noteiktas pārbaudes.
Ad-Hoc testu rezultātu veidi
Ad-hoc pārbaužu rezultātā tiek iegūti vairāki atšķirīgi rezultāti, tostarp:
1. Testa rezultāti
Atsevišķi testi sniedz dažādus rezultātus, kas ir atkarīgi no konkrētās sastāvdaļas un pieejas – tā var būt dažāda veida.
Parasti testētājs ir atbildīgs par to, lai noteiktu, vai rezultāti ir kļūdaini, lai gan dokumentācijas trūkuma dēļ ir grūti salīdzināt rezultātus ar viņu cerībām. Ja komanda pamana kādas problēmas, šos rezultātus nodod izstrādātājiem.
2. Testu žurnāli
Pati programmatūra izmanto sarežģītu iekšējo žurnālu sistēmu, lai uzraudzītu lietotāja ievadītos datus un norādītu uz vairākām iespējamām failu vai datubāzes problēmām.
Tas varētu norādīt uz iekšēju kļūdu, tostarp uz konkrētu programmatūras daļu, kas izraisa problēmu. Izmantojot šo informāciju, ad-hoc testētāji un izstrādātāji var daudz vieglāk risināt atklātās problēmas.
3. Kļūdu ziņojumi
Daudzu ad-hoc pārbaužu mērķis ir tieši izjaukt programmatūru un atklāt tās ierobežojumus, un tas nozīmē, ka viens no biežākajiem šo pārbaužu rezultātiem ir lietojumprogrammas kļūdu ziņojumi.
Mērķtiecīgi radot kļūdas ziņojumus, komanda var parādīt, ko redz vidusmēra galalietotājs, kad viņa veiktās neparedzētās darbības negatīvi ietekmē programmas darbību.
Ad-Hoc testēšanas piemēri
Šeit ir trīs ad-hoc testēšanas scenāriji, kas parāda, kā komanda varētu to īstenot dažādām lietojumprogrammām:
1. E-komercijas tīmekļa lietojumprogramma
Ja uzņēmums vēlas testēt uz e-komerciju balstītu tīmekļa lietojumprogrammu, tas var izmantot ad-hoc testēšanu, jo īpaši pērtiķu testēšanu, lai noskaidrotu, cik labi platforma tiek galā ar neparedzētām lietotāju mijiedarbībām.
Testētāji var censties izmantot katru funkciju līdz tās robežām, piemēram, pievienojot preces grozā nereālos daudzumos vai mēģinot iegādāties produktus, kuru nav noliktavā. Viņus neierobežo komandas testēšanas gadījumi, un ir tikai daži ierobežojumi attiecībā uz pārbaudēm, ko viņi varētu veikt; testētāji var pat mēģināt veikt pirkumus, izmantojot novecojušus URL.
2. Darbvirsmas lietojumprogramma
Ad-hoc testētāji var izmantot šīs metodes arī darbvirsmas lietojumprogrammām, iespējams, pievēršot uzmanību dažādiem datoriem un tam, cik labi tie spēj pielāgot programmu.
Komandas locekļi var veikt šīs pārbaudes atkārtoti, lai redzētu, kā aparatūras vai programmatūras iestatījumu maiņa ietekmē lietojumprogrammas vispārējo veiktspēju. Piemēram, konkrētajai grafiskajai kartei var būt grūti atveidot saskarni.
Alternatīvi šie testētāji varētu vienkārši dot programmai neiespējamus ievades datus un pārbaudīt, kā tā reaģē, piemēram, vai tā spēj pareizi parādīt kļūdas ziņojumus, kas pienācīgi izskaidro problēmu galalietotājam.
3. Mobilā lietojumprogramma
Viens no veidiem, kā ad-hoc testētāji varētu pārbaudīt mobilo lietojumprogrammu, ir pārbaudīt tās drošības protokolus – piemēram, viņi varētu mēģināt tieši piekļūt lietojumprogrammas izstrādes rīkiem.
Komanda var mēģināt noskaidrot, vai viņi spēj veikt nesankcionētas darbības, atrodot izplatītākās nepilnības un ekspluatantus; viņi var īpaši lūgt darbiniekus ar pieredzi lietotņu drošības jomā, lai viņi to atvieglotu.
Tas var ietvert arī testēšanu pāros ar izstrādātājiem, jo viņi var izprast lietotnes dizainu, ļaujot testētājam izjaukt programmatūru un parādīt, kur tieši trūkst drošības.
Atklāto kļūdu un kļūdu veidi
izmantojot Ad-Hoc testēšanu
Ad-hoc pārbaudes var atklāt daudzas programmas problēmas, piemēram:
1. Funkcionalitātes kļūdas
Izmantojot ad-hoc testēšanu, lai pārbaudītu lietojumprogrammas pamatfunkcijas, var atklāt nopietnas kļūdas, kas ietekmē to, kā lietotāji var izmantot lietojumprogrammu.
Piemēram, veicot e-komercijas vietnes maksājumu iespēju testēšanu ar pērtiķiem, tiks parādīti nosacījumi, kas kavē darījuma veikšanu.
2. Veiktspējas problēmas
Testētāji var īpaši strādāt, lai radītu programmas veiktspējas problēmas, piemēram, piepildot datubāzi ar dažādiem surogātpasta ievades datiem.
Tas var izpausties kā ievērojama kavēšanās vai pat vispārēja programmatūras nestabilitāte, kas, visticamāk, novedīs pie (iespējams, sistēmas mēroga) avārijas.
3. Lietojamības problēmas
Šajās pārbaudēs var arī atklāt saskarnes un vispārējās lietotāja pieredzes trūkumus. Piemēram, mobilās lietotnes lietotāja interfeiss citā operētājsistēmā vai ekrāna izšķirtspējā var būt atšķirīgs. Sakarā ar sliktu saskarni lietotāji var saskarties ar grūtībām lietot šo lietojumprogrammu.
4. Drošības trūkumi
Ad-hoc testēšanas nejaušības princips ļauj aptvert virkni izplatītu un reti sastopamu drošības problēmu; testētājs var izmantot šīs pārbaudes, lai atrastu programmas administratīvos aizmugurējos vārtus.
Alternatīvi, veicot pārbaudi, var konstatēt, ka programmatūrai nav datu šifrēšanas.
Bieži sastopamie ad-hoc testēšanas rādītāji
Ad-hoc testēšanā izmanto dažādus rādītājus, lai atvieglotu rezultātu iegūšanu, tostarp:
1. Defektu noteikšanas efektivitāte
Šis rādītājs parāda, cik efektīvi testēšanas procesā tiek atrasti defekti visos testēšanas veidos, tostarp ad hoc testēšanā. Defektu atklāšanas efektivitāte ir atklāto defektu procentuālais īpatsvars, kas dalīts ar kopējo problēmu skaitu – tas parāda, cik efektīvi ir testi.
2. Testa pārklājuma līmenis
Ad-hoc testēšanas palīgfunkcija ir palielināt pārklājumu, pārbaudot komponentus tādā veidā, kas nav ņemts vērā testa gadījumos. Tas nozīmē, ka testētāji arī centīsies radikāli palielināt testēšanas pārklājumu visās pārbaudēs, cik vien iespējams.
3. Kopējais testa ilgums
Ad-hoc testēšana ir daudz ātrāka nekā citi kvalitātes nodrošināšanas procesi, un ir svarīgi, lai testētāji strādātu, lai saglabātu šo priekšrocību. Testa ilguma rādītāji parāda komandas locekļiem, kā viņi var ietaupīt laiku un vēl vairāk palielināt ad-hoc stratēģiju priekšrocības.
4. Sadursmju biežums
Šo testu mērķis bieži vien ir sabojāt programmatūru un izraisīt avāriju vai nopietnu kļūdu – tas ļauj tiem pārsniegt tipiskās testēšanas stratēģijas un atklāt negaidītas problēmas. Šim nolūkam var palīdzēt informācija par to, cik bieži programmatūra sabojājas un kas izraisa šīs problēmas.
5 labākie Ad-Hoc testēšanas rīki
Programmatūras testēšanā ad-hoc testēšanai ir pieejami daudzi bezmaksas un maksas testēšanas rīki – pieci labākie ir šādi:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST ir visaptveroša programmatūras testēšanas programma, kas nodrošina augsta līmeņa testēšanas + RPA funkcionalitāti gan bezmaksas, gan uzņēmumu versijās.
Šis pilnais programmatūras automatizācijas komplekts + RPA Suite ļauj veikt pilnvērtīgu testēšanu dažādās datora un mobilajās platformās; programmatūras 1SCRIPT tehnoloģija arī ļauj lietotājiem viegli veikt vienas un tās pašas pārbaudes atkārtoti. Papildus tam rīks izmanto jaunāko datorredzes tehnoloģiju, kas ļauj ZAPTEST veikt ad hoc testus no cilvēka perspektīvas.
2. BrowserStack
BrowserStack ir mākoņplatforma, kas var atvieglot testēšanu vairāk nekā 3000 dažādās mašīnās, un tai ir papildu iespēja automatizēt Selenium skriptus. Lai gan tas nodrošina spēcīgu pārklājumu programmatūras projektiem, tas vislabāk darbojas ar pārlūkprogrammām un mobilajām lietojumprogrammām.
BrowserStack testēšanas risinājumi ietver arī bezmaksas izmēģinājuma versiju ar 100 minūšu ilgu automatizētu testēšanu, lai gan tās izmantošana var būt ierobežota.
Lai gan uz mākoņiem balstīta pieeja var būt noderīga, tā arī negatīvi ietekmē platformas reakcijas laiku.
3. LambdaTest
LambdaTest līdzīgi izmanto mākoņtehnoloģiju un liek lielu uzsvaru uz pārlūka testēšanu, kas var ierobežot tās efektivitāti citu lietojumprogrammu gadījumā, lai gan tā joprojām labi sader ar iOS un Android programmām. Šī ir noderīga platforma, ja ir nepieciešama mērogojamība, un tā ir integrējama ar daudziem citiem testēšanas hostinga pakalpojumiem.
Tomēr daži lietotāji dažādi reaģē uz lietojumprogrammas cenām, kas ir pieejamas dažādās neizmēģinājuma opcijās, un tas var ierobežot pieejamību mazākām organizācijām.
4. TestRail
TestRail kopumā ir diezgan pielāgojams, jo darbojas tikai pārlūkprogrammā, un, neraugoties uz to, ka tajā liela uzmanība pievērsta efektīviem testēšanas gadījumiem, tas var lepoties arī ar tiešu ad-hoc funkcionalitāti. Analītika, ko tā nodrošina pēc katra testa, var palīdzēt arī komandām, kuras aktīvi izvairās no neatkarīgas dokumentācijas veidošanas, vienlaikus ļaujot tām apstiprināt savu testēšanas procesu.
Tomēr lielākiem komplektiem var būt grūtības ar pārlūkprogrammas formātu, kas var ievērojami ierobežot ad-hoc testēšanas laika ietaupījumu.
5. Zefīrs
Zephyr ir SmartBear izstrādāta testēšanas pārvaldības platforma, kas palīdz kvalitātes nodrošināšanas komandām uzlabot testēšanas pārskatāmību, vienlaikus labi integrējoties ar citu kļūdu uzskaites programmatūru.
Tomēr šī funkcija ir pieejama tikai noteiktām lietojumprogrammām, no kurām Confluence un Jira gūst vislielāko labumu no Zephyr – tie var nebūt visefektīvākie risinājumi katram uzņēmumam. Ar Zephyr zīmolu ir pieejamas vairākas mērogojamas programmas par dažādām cenām.
Ad-Hoc testēšanas kontrolsaraksts, padomi un triki
Šeit ir sniegti papildu padomi, kas komandām jāņem vērā, veicot ad-hoc testēšanu:
1. Jutīgo komponentu prioritāšu noteikšana
Dažām funkcijām vai sastāvdaļām, protams, ir lielāks kļūdu risks nekā citām, jo īpaši, ja tās ir svarīgas programmas vispārējai darbībai.
Katrā testēšanas pieejā ir jāidentificē tās lietojumprogrammas daļas, kurām varētu būt nepieciešams pievērst lielāku uzmanību. Tas ir īpaši noderīgi, ja kopējais testēšanai atvēlētais laiks ir ierobežots.
2. Izpētīt dažādus testēšanas rīkus
Rīks, ko organizācija izmanto, lai atvieglotu testus, var ietekmēt šo pārbaužu aptvērumu un uzticamību.
Veicot ad-hoc testēšanu, ir vērts apskatīt pēc iespējas vairāk programmu, lai atrastu tās, kas atbilst uz lietotāju orientētam aspektam. Programmatūra, kas izmanto datorredzes tehnoloģiju, piemēram, ZAPTEST, var veikt ad hoc testus, izmantojot cilvēkam līdzīgu stratēģiju.
3. Pieņemt ad-hoc domāšanas veidu
Ad-hoc testēšana sniedz milzīgu brīvību visā kvalitātes nodrošināšanas posmā, taču, lai gūtu šīs stratēģijas galvenos ieguvumus, komandai ir jācenšas to veikt.
Piemēram, ad-hoc testētājiem ir jāatsakās no visiem ierastajiem dokumentiem, kas nav saistīti ar vienkāršu piezīmju pierakstīšanu, un viņiem ir jāpārbauda programmatūra no pilnīgi jaunas perspektīvas.
4. Uzticieties testēšanas instinktiem
Pieredze ar ad-hoc testēšanu vai vispārējām programmatūras pārbaudēm var palīdzēt izcelt biežāk sastopamos kļūdu punktus, un tas palīdz testētājiem noteikt, kā pamanīt visu veidu kļūdas.
Ir ļoti svarīgi, lai testētāji uzticētos saviem instinktiem un vienmēr izmantotu šīs zināšanas savā labā – viņi var intuitīvi noteikt, kuras ad-hoc pārbaudes būtu visnoderīgākās.
5. Pilnīga atklāto kļūdu reģistrēšana
Lai gan ad-hoc testēšanai nav formālas dokumentācijas un tā lielākoties balstās uz neoficiālām piezīmēm, tomēr ir svarīgi, lai komanda spētu identificēt un paziņot programmatūras kļūdas cēloni.
Tiem ir jāreģistrē visa testā iegūtā informācija, kas ir svarīga izstrādātājiem, piemēram, iespējamie šo problēmu cēloņi.
6. Vienmēr ņemiet vērā lietotāju
Katrs testēšanas veids ir paredzēts, lai zināmā mērā pielāgotos lietotāja vispārējai pieredzei, un ad-hoc testēšana nav izņēmums. Lai gan ad-hoc testētāji bieži vien dziļāk aplūko lietojumprogrammas iekšējo darbību un pat tās iekšējo kodu, viņiem ir jāmēģina šo programmatūru uzlauzt tā, kā lietotāji teorētiski to varētu izdarīt.
7. Nepārtraukti uzlabot procesu
Testēšanas komandām ir jāpilnveido sava pieeja ad-hoc testēšanai starp vienas un tās pašas programmatūras vairākām iterācijām un no viena projekta uz nākamo.
Viņi var apkopot atsauksmes no izstrādātājiem, lai noskaidrotu, cik labi viņu ad-hoc testi palīdzēja kvalitātes nodrošināšanas posmā un vai viņiem izdevās ievērojami palielināt testu pārklājumu.
Secinājums
Ad-hoc testēšana var palīdzēt dažāda veida organizācijām pārbaudīt savas programmatūras testēšanas stratēģijas autentiskumu, taču veids, kā tās īsteno šo metodi, var būt būtisks tās efektivitātes faktors.
Lai no ad-hoc pārbaudēm gūtu vislielāko labumu, ir svarīgi līdzsvarot dažādus testēšanas veidus, jo īpaši tāpēc, ka šis testēšanas veids ir paredzēts, lai papildinātu citus, aizpildot stratēģisku trūkumu.
Izmantojot tādu lietojumprogrammu kā ZAPTEST, komandām ir iespējams veikt ad-hoc testus ar lielāku pārliecību vai elastību, jo īpaši, ja tās īsteno automatizāciju. Neatkarīgi no komandas īpašās pieejas, tās apņemšanās veikt ad-hoc testēšanu var mainīt visu programmu vai projektu.
