Ad-hoc testavimas – tai programinės įrangos testavimo rūšis, kurią kūrėjai ir programinės įrangos bendrovės taiko tikrindami dabartinę programinės įrangos iteraciją. Šis testavimo būdas leidžia geriau suprasti programą ir nustatyti problemas, kurių įprastinis testavimas gali nepastebėti.
Labai svarbu, kad testavimo komandos gerai išmanytų ad hoc testavimo procesą, kad žinotų, kaip apeiti jo iššūkius, ir įsitikintų, kad komanda gali sėkmingai įgyvendinti šį metodą.
Tiksliai žinodama, kaip veikia ad hoc testavimas ir kokios priemonės gali palengvinti jo įgyvendinimą, įmonė gali nuolat tobulinti savo kokybės užtikrinimo procedūras. Formalus testavimo procesas vyksta pagal labai konkrečias taisykles, todėl komanda gali nepastebėti tam tikrų klaidų – ad-hoc patikros gali padėti apeiti šias akląsias zonas ir greitai patikrinti kiekvieną programinės įrangos funkciją.
Šiame straipsnyje išsamiai nagrinėjame ad hoc testavimą ir kaip jį galima panaudoti kuriant programinės įrangos produktą.
Ad-Hoc testavimo reikšmė: Kas yra Ad-Hoc testavimas?
Ad-hoc testavimas – tai kokybės užtikrinimo procesas, kurio metu išvengiama formalių taisyklių ir dokumentacijos, nes padeda testuotojams surasti klaidas, kurių įprastiniais metodais nustatyti neįmanoma. Prieš pradedant testavimą paprastai reikia išsamiai išmanyti programinę įrangą, įskaitant programos vidinį veikimą. Šiais ad hoc patikrinimais siekiama pažeisti programą taip, kad ji atspindėtų naudotojo įvestį ir būtų atsižvelgta į įvairias galimas situacijas, kad kūrėjai galėtų ištaisyti visas esamas problemas.
Dokumentacijos trūkumas yra pagrindinis šio metodo bruožas, nes nėra kontrolinio sąrašo ar testavimo atvejų, kuriais testuotojai galėtų vadovautis naudodami programos funkcijas. Ad-hoc testavimas – tai tik programinės įrangos testavimas tokiu būdu, kokį komanda nusprendžia, kad jis tuo metu yra veiksmingas. Tai gali būti daroma atsižvelgiant į jau atliktus oficialius bandymus, tačiau taip pat gali būti tiesiog atliekama kuo daugiau bandymų per (greičiausiai ribotą) šiam metodui skirtą laiką.
1. Kada ir kodėl programinės įrangos testavime reikia atlikti ad hoc testavimą?
Pagrindinė priežastis, kodėl įmonės atlieka ad hoc testavimą, yra ta, kad juo galima aptikti klaidų, kurių tradiciniais metodais nepavyksta rasti. Taip gali būti dėl įvairių priežasčių, pavyzdžiui, dėl to, kad įprastiniai bandymų atvejai atliekami pagal ypač standartizuotą procesą, kuriame negalima atsižvelgti į taikomosios programos ypatumus.
Kiekvienas testavimo tipas gali pasiūlyti naujų perspektyvų ir įdomių požiūrių į kokybės užtikrinimą – tai taip pat parodo įprastos testavimo strategijos problemas. Pavyzdžiui, jei atliekant ad hoc testavimą galima nustatyti problemą, kurios komandos testavimo atvejai nenagrinėja, tai reiškia, kad jiems būtų naudinga iš naujo kalibruoti testavimo metodiką.
Testuotojai gali atlikti ad hoc patikras bet kuriuo testavimo proceso metu. Paprastai tai yra tradicinio (ir labiau formalaus) kokybės užtikrinimo papildymas, todėl testuotojai gali atlikti ad hoc patikrinimus, kol jų kolegos atlieka labiau formalius tyrimus. Tačiau vietoj to jie gali nuspręsti ad hoc patikrinimus atidėti iki oficialaus testavimo proceso pabaigos kaip tolesnius veiksmus, kuriais konkrečiai siekiama pašalinti galimas „akląsias” vietas.
Ad-hoc testavimas taip pat gali būti naudingas, kai dėl dokumentų trūkumo ypač trūksta laiko – tinkamas laikas priklauso nuo įmonės ir jos pasirinkto metodo.
2. Kai nereikia atlikti ad hoc testavimo
Jei nėra pakankamai laiko atlikti ir ad hoc, ir formalųjį testavimą, svarbu, kad komanda pirmenybę teiktų pastarajam, nes taip užtikrinama didelė testavimo aprėptis, net jei vis dar yra tam tikrų spragų.
Jei atlikus oficialius komandos testus randama klaidų, kurias reikia ištaisyti, paprastai geriau palaukti, kol kūrėjai atliks reikiamus pakeitimus ir atliks ad hoc patikrinimus. Priešingu atveju jų rezultatai gali greitai pasenti, ypač jei bandymai susiję su komponentu, kuriame jau yra klaidų.
Be to, prieš pradedant beta testavimo etapą turi būti atliekamas ad hoc testavimas.
3. Kas dalyvauja ad hoc testavime?
Ad-Hoc testavimo procese atliekami keli pagrindiniai vaidmenys, įskaitant:
– Programinės įrangos testuotojai yra pagrindiniai komandos nariai, atliekantys ad hoc patikrinimus. Jei atliekami bandymai su draugais arba poromis, keli iš šių bandytojų dirbs kartu su tais pačiais komponentais.
– Kūrėjai gali savarankiškai naudoti šias patikras prieš oficialų kokybės užtikrinimo etapą, kad greitai patikrintų savo programinę įrangą, nors tai yra mažiau nuodugnu nei specialus ad hoc testavimas.
– Grupės ar skyriaus vadovai patvirtina bendrą testavimo strategiją – padeda testuotojams nustatyti, kada pradėti ad-hoc testavimą ir kaip jį atlikti nesutrikdant kitų patikrinimų.
Ad-Hoc testavimo privalumai
Ad-hoc testavimo privalumai programinės įrangos testavime yra šie:
1. Greita rezoliucija
Kadangi atliekant šiuos bandymus nereikia dažnai rengti dokumentacijos prieš patikrinimus, jų metu ar po jų, komandos gali daug greičiau nustatyti problemas. Šis paprastumas suteikia didžiulę laisvę testuotojams.
Pavyzdžiui, jei komanda, išbandžiusi komponentą ir nenustačiusi jokių klaidų, gali paprasčiausiai pereiti prie kito bandymo, nepažymėdama to dokumente.
2. Papildo kitus testavimo tipus
Jokia testavimo strategija nėra tobula, o 100 proc. aprėpties paprastai neįmanoma pasiekti – net ir turint išsamų tvarkaraštį. Įprastiniuose bandymuose visada bus spragų, todėl svarbu, kad įmonės integruotų kelis metodus.
Ad-hoc testavimo tikslas – rasti problemas, kurių oficialus testavimas negali aprėpti, ir taip užtikrinti didesnę bendrą testavimo aprėptį.
3. Lankstus vykdymas
Ad hoc testavimas gali būti atliekamas bet kuriuo kokybės užtikrinimo proceso etapu prieš pradedant beta testavimą, todėl įmonės ir komandos gali nuspręsti, kada geriausia atlikti šiuos patikrinimus. Jie gali pasirinkti atlikti ad hoc testus kartu su įprastiniais testais arba gali palaukti, kol jie bus atlikti vėliau – nesvarbu, kokiu atveju, komandai naudingi turimi pasirinkimai.
4. Glaudesnis bendradarbiavimas
Kūrėjai yra labiau įtraukti į šį procesą nei į daugelį kitų testavimo formų, ypač jei įmonė naudoja draugų ir porų testavimą.
Dėl to kūrėjai geriau supranta savo programas ir gali sugebėti kokybiškiau šalinti klaidas. Tai padeda dar labiau pagerinti bendrą programinės įrangos kokybę.
5. Įvairios perspektyvos
Ad hoc testavimas gali parodyti programą iš naujų kampų ir padėti testuotojams naujai susipažinti su šiomis funkcijomis. Papildomos perspektyvos yra labai svarbios viso testavimo metu, nes oficialiose patikrose dažnai būna bent nedidelių spragų.
Jei ad hoc testuotojai naudoja programinę įrangą su konkrečiu tikslu ją pažeisti, jie galės lengviau nustatyti programos ribas.
Ad-Hoc testavimo iššūkiai
Ad-hoc testavimo procesas taip pat susiduria su keliais iššūkiais, pvz:
1. Sunkumai teikiant ataskaitas
Dėl dokumentų trūkumo ad-hoc bandymai atliekami daug greičiau, tačiau dėl jų gali būti sudėtinga teikti ataskaitas apie bet kokias kitas nei svarbias problemas.
Pavyzdžiui, vienas anksčiau atliktas patikrinimas vėliau gali tapti svarbesnis, nors iš pradžių ir nedavė reikšmingų rezultatų. Be išsamių dokumentų komanda gali nesugebėti paaiškinti šių bandymų.
2. Mažiau pakartojamas
Panašiai ir bandytojai gali nežinoti tikslių sąlygų, būtinų stebimoms reakcijoms sukelti. Pavyzdžiui, atlikus ad hoc patikrą, kai gaunama klaida, gali nepakakti informacijos, kad komanda galėtų imtis veiksmų. Jie gali nežinoti, kaip pakartoti šį testą ir gauti tą patį rezultatą.
3. Reikalinga programinės įrangos patirtis
Kadangi atliekant ad hoc bandymus svarbiausia yra greitis ir paprastai bandoma sugadinti programą, svarbu, kad šie bandytojai gerai išmanytų šią programą.
Žinodami, kaip ji veikia, testuotojai gali pažeisti programinę įrangą ir manipuliuoti ja įvairiais būdais, tačiau tai gali gerokai padidinti ad hoc testavimo įgūdžių poreikį.
4. Ribota atskaitomybė
Dokumentacijos trūkumas gali sukelti ne tik prastų ataskaitų, bet ir netyčia prailginti testavimo procesą, o tai gali turėti įtakos greitų atskirų ad hoc testų naudingumui.
Testuotojams gali būti sunku sekti savo pažangą, jei kiekviename etape nepateikiama pakankamai dokumentų. Dėl to jie netgi gali pakartoti patikrinimą, kurį jau atliko kiti testuotojai.
5. Gali neatspindėti naudotojo patirties
Beveik visų rūšių testavimo tikslas – nustatyti klaidas, kurios kokiu nors būdu daro poveikį galutiniams naudotojams. Ad-hoc testavimas visų pirma remiasi patyrusio testuotojo bandymais imituoti nepatyrusį naudotoją, ir tai turėtų būti nuoseklu kiekvieno patikrinimo metu, įskaitant bandymus sugadinti programą.
Ad-Hoc testų charakteristikos
Pagrindinės sėkmingų ad hoc testų savybės yra šios:
1. Tyrimas
Pagrindinis ad hoc testavimo prioritetas – nustatyti taikomosios programos klaidas naudojant metodus, į kuriuos įprastiniai patikrinimai neatsižvelgia. Atliekant ad-hoc tyrimus, ši programinė įranga tikrinama siekiant rasti spragų komandos testavimo procedūroje, įskaitant testavimo atvejų aprėptį.
2. Nestruktūrizuotas
Ad hoc patikros paprastai neturi jokio nustatyto plano, išskyrus tai, kad reikia atlikti kuo daugiau bandymų už įprastų formalaus kokybės užtikrinimo ribų. Kad būtų patogiau, bandytojai paprastai sugrupuoja patikras pagal komponentus, tačiau tai nėra būtina – jie netgi gali sugalvoti patikras jų atlikimo metu.
3. Į patirtį orientuotas
Ad-hoc testuotojai, naudodamiesi savo turima programinės įrangos naudojimo patirtimi, įvertina, kurie testai būtų naudingiausi, ir sprendžia dažniausiai pasitaikančias formalaus testavimo problemas.
Nors testavimo procesas vis dar yra visiškai nestruktūruotas, priimdami sprendimą dėl strategijos testuotojai, be kita ko, taiko savo žinias apie ankstesnius ad hoc patikrinimus.
4. Platus
Nėra tikslių nurodymų, kokius patikrinimus komanda turėtų atlikti ad hoc testavimo metu, tačiau paprastai jie apima įvairius komponentus, galbūt daugiau dėmesio skiriant jautresniems taikomosios programos aspektams. Tai padeda testuotojams užtikrinti, kad jų atliekami tyrimai galėtų visapusiškai papildyti formalųjį testavimą.
Ką tikriname atlikdami ad hoc testus?
Kokybės užtikrinimo komandos, atlikdamos ad hoc testavimą, paprastai tikrina šiuos dalykus:
1. Programinės įrangos kokybė
Šiais patikrinimais siekiama nustatyti programos klaidas, kurių įprastinis testavimas negali atskleisti; tai reiškia, kad šiuo procesu daugiausia tikrinama bendra programos būklė.
Kuo daugiau klaidų pavyksta aptikti atliekant ad hoc bandymus, tuo daugiau patobulinimų kūrėjai gali įgyvendinti iki nustatyto termino.
2. Testavimo atvejai
Atliekant ad hoc testavimą paprastai neįgyvendinami testavimo atvejai – būtent todėl, kad komanda galėtų ištirti, kaip efektyviai jie užtikrina pakankamą aprėptį. Tikėtina, kad testavimo atvejai yra netinkami, jei ad-hoc patikros gali aptikti klaidų, kurių įprastiniai testavimo procesai negali aptikti.
3. Testavimo personalas
Taip pat gali būti siekiama patikrinti testavimo grupės įgūdžius ir žinias, net jei testavimo atvejai yra tinkami. Pavyzdžiui, jų taikoma atvejų įgyvendinimo metodika gali būti nepakankama, o ad hoc testavimas gali būti labai svarbus siekiant pašalinti atsiradusias testavimo aprėpties spragas.
4. Programinės įrangos apribojimai
Atliekant ad hoc bandymus taip pat siekiama išsiaiškinti taikomosios programos ribas, pavyzdžiui, kaip ji reaguoja į netikėtus įvesties duomenis arba dideles sistemos apkrovas. Testuotojai galėtų specialiai tirti programos klaidų pranešimus ir tai, kaip ši programa veikia, kai patiria didelį spaudimą.
Išaiškinti tam tikrą painiavą:
Ad-Hoc testavimas ir tiriamasis testavimas
Kai kurie žmonės mano, kad ad hoc ir žvalgomasis testavimas yra sinonimai, tačiau tiesa yra sudėtingesnė.
1. Kas yra tiriamasis testavimas?
Tiriamasis testavimas – tai kokybės užtikrinimo procedūros, kuriomis programinė įranga tiriama holistiniu požiūriu ir kurios į vieną metodą sujungia atradimo ir testavimo procesus. Paprastai tai yra tarpinis variantas tarp visiškai struktūrizuoto testavimo ir visiškai laisvos formos ad hoc patikrinimų.
Tiriamasis testavimas geriausiai tinka tam tikrais atvejais, pavyzdžiui, kai reikia greitai gauti grįžtamąjį ryšį arba kai komanda turi spręsti kraštutinius atvejus. Šio tipo testavimas paprastai pasiekia visą savo potencialą, kai komanda kartu su juo naudoja scenarijų testavimą.
2. Tiriamojo testavimo skirtumai
ir „Ad-Hoc” bandymai
Didžiausias skirtumas tarp ad hoc ir tiriamojo testavimo yra tas, kad atliekant ad hoc testavimą naudojami dokumentai, kuriais registruojami ir palengvinami patikrinimai, o atliekant ad hoc testavimą to visiškai išvengiama. Žvalgomajame testavime daugiau dėmesio skiriama testavimo laisvei, tačiau ji niekada nebus tokia pat didelė kaip ad hoc testavimo, kuris yra visiškai nestruktūrizuotas.
Atliekant žvalgomąjį testavimą taip pat tenka mokytis apie programą ir jos vidinį veikimą – vietoj to ad hoc testuotojai dažnai prieš pradėdami testavimą turi išsamių žinių apie programinės įrangos funkcionalumą.
Ad-Hoc bandymų tipai
Programinės įrangos testavime yra trys pagrindinės ad hoc testavimo formos, įskaitant:
1. Bandymai su beždžionėmis
Bene populiariausias ad hoc testavimo tipas – „beždžionių” testai, kai komanda atsitiktine tvarka tikrina skirtingus komponentus.
Paprastai tai atliekama atliekant vieneto testavimą, kai atliekama eilė patikrinimų be jokių testavimo atvejų. Testuotojai savarankiškai tiria duomenis visiškai nestruktūruotais būdais, todėl gali ištirti platesnę sistemą ir jos gebėjimą atlaikyti didelę naudotojų įvesties apkrovą.
Stebint šių neaprašytų metodų išvestį, testavimo komanda gali nustatyti klaidas, kurių kiti vienetiniai testai nepastebėjo dėl įprastinių testavimo metodų trūkumų.
2. Bičiulių testavimas
Ad-hoc kontekste draugų testuose dalyvauja mažiausiai du darbuotojai – paprastai testuotojas ir kūrėjas – ir jie dažniausiai atliekami po vienetų testavimo etapo. „Bičiuliai” kartu dirba su tuo pačiu moduliu, kad nustatytų klaidas. Įvairių įgūdžių ir visapusiškos patirties turintys specialistai sudaro veiksmingesnę komandą ir padeda išspręsti daugelį problemų, kylančių dėl dokumentų trūkumo.
Kūrėjas gali net pats pasiūlyti keletą testų, kad galėtų nustatyti komponentus, kuriems reikia skirti daugiau dėmesio.
3. Porų testavimas
Testavimas poromis yra panašus, nes jame dalyvauja du darbuotojai, tačiau paprastai tai būna du atskiri testuotojai, iš kurių vienas atlieka tikruosius testus, o kitas užsirašinėja.
Net ir nesant oficialių dokumentų, užrašai gali leisti komandai neformaliai sekti atskirus ad hoc patikrinimus. Testuotojo ir raštininko vaidmenys gali keistis priklausomai nuo testo arba pora gali išlaikyti jiems priskirtus vaidmenis viso proceso metu.
Tikrinimus paprastai atlieka daugiau patirties turintis testuotojas, nors jie visada dalijasi darbais tarpusavyje.
Rankiniai ar automatiniai „Ad-Hoc” testai?
Automatizuotas testavimas gali padėti komandoms sutaupyti dar daugiau laiko kokybės užtikrinimo etape, todėl testuotojai į savo tvarkaraštį gali įtraukti daugiau patikrinimų. Net ir neturint konkrečios struktūros, labai svarbu, kad testuotojai dirbtų siekdami kuo didesnės aprėpties, o automatizavimas skatina nuodugnesnius šios programinės įrangos patikrinimus.
Automatinės ad hoc patikros paprastai yra tikslesnės nei rankiniai testai, nes leidžia išvengti žmogiškųjų klaidų atliekant įprastas užduotis – tai ypač naudinga, kai tie patys testai atliekami skirtingose iteracijose. Šios procedūros sėkmė paprastai priklauso nuo komandos pasirinktos automatinio testavimo priemonės ir jos funkcionalumo.
Tačiau automatinis testavimas turi tam tikrų apribojimų. Pavyzdžiui, pagrindinė ad hoc testavimo stiprybė – galimybė imituoti naudotojo įvestį ir atlikti atsitiktines patikras, kai jas sugalvoja testuotojas. Šie testai gali prarasti atsitiktinumą, jei organizacijos testavimo programai sunku atlikti sudėtingus patikrinimus.
Laikas, kurio reikia šioms labai specifinėms užduotims automatizuoti, taip pat gali apriboti tipinį šio proceso sutaupytą laiką. Svarbu, kad komandos nuodugniai išnagrinėtų turimus automatizavimo įrankius ir rastų tokį, kuris atitiktų jų įmonės projektą.
Ko reikia norint pradėti ad hoc testavimą?
Štai pagrindinės ad hoc testavimo sąlygos:
1. Kvalifikuoti darbuotojai
Kadangi ad hoc testai – tai greitas, atsitiktinis programinės įrangos vidaus veikimo patikrinimas, paprastai padeda testuotojai, kurie turi programinės įrangos naudojimo patirties. Jie taip pat turėtų išmanyti pagrindinius testavimo principus – taip jie galės lengvai nustatyti veiksmingiausius patikrinimus.
2. Nestruktūrizuotas metodas
Testuotojai turi būti pasirengę atsisakyti įprastų ad hoc testavimo strategijų; šis mąstymas yra toks pat svarbus, kaip ir patys kokybės patikrinimai. Šis metodas gali būti sėkmingas tik be struktūros ar dokumentacijos, todėl labai svarbu, kad bandytojai tai prisimintų kiekviename etape.
3. Automatikos programinė įranga
Nors ad hoc testavimas labiau pagrįstas atsitiktinių įvesties duomenų ir sąlygų testavimu, automatizavimas vis tiek yra labai veiksmingas metodas bet kokiame kontekste.
Dėl šios priežasties atliekant ad hoc patikras vis tiek reikėtų, jei įmanoma, naudoti automatinio testavimo priemones, nes tinkama programa gali gerokai supaprastinti procesą.
4. Kitos bandymų formos
Ad-hoc testai geriausiai tinka kartu su kitais patikrinimais, kuriems taikomas oficialesnis požiūris, nes padeda komandai užtikrinti didelę programinės įrangos aprėptį. Labai svarbu, kad testuotojai derintų įvairius metodus, nors tai gali būti daroma prieš atliekant ad hoc testavimą, jo metu arba po jo.
Ad-Hoc testavimo procesas
Įprastiniai veiksmai, kurių testuotojai turėtų laikytis atlikdami ad hoc testavimą programinės įrangos testavimo srityje, yra šie:
1. Ad-hoc bandymų tikslų apibrėžimas
Šis etapas yra ribotas, nes trūksta dokumentų ir struktūros, tačiau vis tiek labai svarbu, kad komanda turėtų aiškų tikslą. Testuotojai gali pradėti dalytis neaiškiomis idėjomis apie tai, kokius testus reikia atlikti ir kokiems komponentams teikti pirmenybę.
2. Ad-hoc bandymų grupės atranka
Komanda apgalvoja keletą galimų ad hoc patikrinimų, taip pat išsiaiškina, kurie testuotojai geriausiai tiktų tokiam testavimui. Paprastai jie pasirenka testuotojus, kurie gerai supranta taikomąją programą, ir gali juos suporuoti su kūrėju.
3. Ad-hoc testų vykdymas
Nusprendę, kurie testuotojai yra tinkami šiam etapui, šie komandos nariai pradeda patikrinimus sutartame testavimo etape. Jų tikslas – atlikti kuo daugiau ad hoc patikrinimų, kurių iki šio etapo testuotojai gali ir nesugalvoti.
4. Bandymų rezultatų vertinimas
Atlikę bandymus (arba net tarp atskirų patikrinimų) testuotojai įvertina rezultatus, tačiau jų oficialiai nedokumentuoja bandymų atveju. Jei jie aptinka kokių nors su paraiška susijusių problemų, jas neoficialiai užfiksuoja ir aptaria tolesnius komandos veiksmus.
5. Pranešimas apie aptiktas klaidas
Įvertinę rezultatus, testuotojai turi informuoti kūrėjus apie programinėje įrangoje esančias klaidas, kad jie turėtų pakankamai laiko jas ištaisyti iki išleidimo.
Testavimo komanda taip pat naudojasi šia informacija, kad nustatytų, kaip patobulinti oficialius testavimo procesus.
6. Jei reikia, pakartotinis testavimas
Testavimo komanda tikriausiai pakartos ad hoc procesą naujoms programos iteracijoms, kad patikrintų, kaip gerai ji tvarkosi su atnaujinimais. Kadangi bandytojai bus ištaisę daugelį anksčiau nustatytų testavimo atvejų spragų, ateityje atliekant ad hoc patikras gali prireikti kitokio požiūrio.
Geriausia ad hoc testavimo praktika
Atliekant ad hoc testavimą testavimo komandos turėtų taikyti tam tikrą praktiką, įskaitant:
1. Tikslinės galimos testavimo spragos
Nors ad hoc testavimas apima daug mažiau planavimo nei kiti tipai, komanda vis tiek siekia pašalinti kokybės užtikrinimo trūkumus. Jei ad hoc testuotojams kyla įtarimų dėl kokių nors konkrečių problemų, susijusių su komandos testavimo atvejais, atlikdami patikrinimus jie turėtų suteikti tam pirmenybę.
2. Apsvarstykite automatizavimo programinę įrangą
Automatizavimo strategijos, tokios kaip hiperautomatizavimas, gali suteikti daug privalumų įmonėms, norinčioms atlikti ad hoc bandymus.
Sėkmė priklauso nuo keleto pagrindinių veiksnių, įskaitant įmonės pasirinktą įrankį ir bendrą ad hoc testų sudėtingumą.
3. Išsamūs užrašai
Dokumentacijos trūkumas atliekant ad hoc bandymus daugiausia padeda dar labiau supaprastinti šį procesą – komandai būtų naudinga daryti neoficialius užrašus. Tai suteikia testuotojams galimybę aiškiai užfiksuoti šiuos patikrinimus ir jų rezultatus, todėl padidėja bendras jų pakartojamumas.
4. Nuolat tobulinkite testus
Ad-hoc testuotojai nuolat tobulina savo metodą, kad atsižvelgtų į komandos testavimo strategijos pokyčius. Pavyzdžiui, peržiūrėdami naujesnes įmonės programinės įrangos versijas, jie gali pakoreguoti šias patikras, atsižvelgdami į naujesnius ir išsamesnius oficialius bandymų atvejus.
7 klaidos ir spąstai įgyvendinant
Ad-Hoc bandymai
Kaip ir bet kuriame testavimo procese, yra daugybė galimų klaidų, kurių komanda turėtų stengtis išvengti, pvz:
1. Nepatyrę testuotojai
Norėdamas išlaikyti numatytą ad hoc testavimo tempą, grupės vadovas turi paskirti testuotojus pagal jų turimas žinias ir įgūdžius. Daugelį testavimo formų gali atlikti pradinio lygio kokybės užtikrinimo darbuotojai, tačiau ad hoc patikrinimams reikia komandos narių, kurie visiškai supranta programinę įrangą; pageidautina, kad jie turėtų tokių testų atlikimo patirties.
2. Nesukoncentruoti patikrinimai
Ad-hoc testavimas gali gerokai pagerinti testų aprėptį dėl greitesnio tempo – komandai nereikia pildyti didelės apimties dokumentacijos prieš kiekvieną patikrinimą ir po jo.
Tačiau ad-hoc testuotojai vis tiek turi išlaikyti tvirtą dėmesį; pavyzdžiui, jie gali nuspręsti teikti pirmenybę tam tikriems komponentams, kurių gedimo rizika yra didesnė.
3. Nėra planavimo
Jei vengsite bet kokio plano, tai gali apriboti ad hoc testavimo veiksmingumą. Nepaisant to, kad šis metodas yra nestruktūrizuotas, svarbu, kad komanda prieš pradėdama darbą turėtų apytikslę idėją, kokius bandymus reikia atlikti.
Laiko šiam procesui yra nedaug, todėl žinojimas, kaip elgtis, gali duoti daug naudos.
4. Pernelyg struktūrizuota
Priešingoje spektro pusėje šis metodas paprastai remiasi planavimo trūkumu, nes tai padeda testuotojams aktyviai iškraipyti testavimo atvejus ir rasti paslėptų klaidų.
Ad hoc testavimas taip pat vadinamas atsitiktiniu testavimu, o priverstinis struktūros nustatymas gali užkirsti kelią klaidų nustatymui.
5. Ilgalaikių pokyčių nėra
Ad-hoc testavimo tikslas – nustatyti silpnąsias komandos testavimo atvejų vietas; taip tikrinama bendra strategija, taip pat kaip ir pati programinė įranga.
Tačiau tai reiškia, kad ad hoc testai paprastai yra veiksmingi tik tuo atveju, jei komanda, naudodamasi šia informacija, laikui bėgant tobulina oficialias patikras.
6. Nesuderinami duomenų rinkiniai
Beveik kiekvienai testavimo formai reikia imituojamų duomenų, kad būtų galima įvertinti, kaip programa reaguoja; kai kurios priemonės leidžia testuotojams automatiškai užpildyti programą imitaciniais duomenimis.
Tačiau tai gali neatspindėti to, kaip naudotojas naudotųsi programine įranga – ad hoc patikroms reikalingi duomenų rinkiniai, su kuriais programinė įranga greičiausiai susidurs.
7. Informacinės silosinės sistemos
Labai svarbu, kad testuotojai ir kūrėjai nuolat bendrautų tarpusavyje, net jei pastarieji nedalyvauja ad hoc testavimo procese.
Tai padeda visiems suprasti, kokie testai buvo atlikti, parodo, kokių veiksmų reikia imtis toliau, ir neleidžia testuotojams be reikalo kartoti tam tikrų patikrinimų.
Ad-Hoc testų rezultatų tipai
Atliekant ad hoc patikras gaunami keli skirtingi rezultatai, įskaitant:
1. Bandymų rezultatai
Atskirų bandymų rezultatai skiriasi priklausomai nuo konkretaus komponento ir metodo, kuris gali būti įvairių formų.
Paprastai testuotojas privalo nustatyti, ar rezultatai yra klaida, nors dėl dokumentų trūkumo sunku palyginti rezultatus su jo lūkesčiais. Jei komanda pastebi kokių nors problemų, perduoda šiuos rezultatus kūrėjams.
2. Bandymų žurnalai
Pati programinė įranga naudoja sudėtingą vidinių žurnalų sistemą, kad stebėtų naudotojo įvestis ir atkreiptų dėmesį į įvairias galimas failų ar duomenų bazių problemas.
Tai gali reikšti vidinę klaidą, įskaitant konkrečią programinės įrangos dalį, su kuria susijusi problema. Turėdami šią informaciją, ad hoc testuotojai ir kūrėjai gali lengviau spręsti aptiktas problemas.
3. Klaidų pranešimai
Daugelio ad hoc patikrinimų tikslas – pažeisti programinę įrangą ir atskleisti jos ribas, todėl vienas iš dažniausių tokių testų rezultatų yra programos klaidų pranešimai.
Sąmoningai sukeldama klaidų pranešimus, komanda gali parodyti, ką mato vidutinis galutinis naudotojas, kai jo atliekami netikėti veiksmai daro neigiamą poveikį programos veikimui.
Ad-Hoc testavimo pavyzdžiai
Pateikiame tris ad hoc testavimo scenarijus, kurie parodo, kaip komanda galėtų jį įgyvendinti skirtingoms programoms:
1. Elektroninės prekybos žiniatinklio programa
Jei įmonė nori išbandyti elektronine prekyba grindžiamą žiniatinklio programėlę, ji gali naudoti ad hoc bandymus, ypač „beždžionių” bandymus, norėdama patikrinti, kaip gerai platforma susidoroja su netikėtomis naudotojų sąveikomis.
Bandytojai gali bandyti išnaudoti kiekvieną funkciją iki galo, pavyzdžiui, į krepšelį dėti nerealius prekių kiekius arba bandyti pirkti produktus, kurių nėra sandėlyje. Jų nevaržo komandos testavimo atvejai, o patikrinimų, kuriuos jie galėtų atlikti, skaičius yra ribotas; testuotojai netgi gali bandyti atlikti pirkimus naudodami pasenusius URL adresus.
2. Darbalaukio programa
Ad-hoc testuotojai taip pat gali taikyti šiuos metodus darbalaukio programoms, galimai sutelkdami dėmesį į skirtingus kompiuterius ir į tai, kaip gerai kiekviename iš jų veikia programa.
Šias patikras komandos nariai gali atlikti pakartotinai, kad pamatytų, kaip keičiami aparatinės ar programinės įrangos nustatymai veikia bendrą programos našumą. Pavyzdžiui, tam tikra vaizdo plokštė gali sunkiai atvaizduoti sąsają.
Taip pat šie bandytojai galėtų tiesiog pateikti savo programai neįmanomus įvesties duomenis ir stebėti, kaip ji reaguoja, pavyzdžiui, ar ji gali teisingai rodyti klaidų pranešimus, kuriuose galutiniam naudotojui būtų tinkamai paaiškinta problema.
3. Mobilioji programa
Vienas iš būdų, kaip ad hoc testeriai galėtų patikrinti mobiliąją programėlę, yra patikrinti jos saugumo protokolus – pavyzdžiui, jie galėtų bandyti tiesiogiai prisijungti prie programėlės kūrimo įrankių.
Komanda gali pabandyti patikrinti, ar jie gali atlikti neleistinus veiksmus, ieškodami bendrų spragų ir išnaudojimo būdų; jie gali specialiai paprašyti darbuotojų, turinčių patirties programėlių saugumo srityje, padėti tai padaryti.
Taip pat gali būti atliekami poriniai bandymai su kūrėjais, nes jie gali suprasti programėlės dizainą, leisti bandytojui sugadinti programinę įrangą ir parodyti, kur tiksliai trūksta saugumo.
Aptiktų klaidų ir klaidų tipai
atliekant ad hoc bandymus
Atliekant ad hoc patikrinimus galima nustatyti daugybę programos problemų, pvz:
1. Funkcionalumo klaidos
Atliekant ad hoc bandymus pagrindinėms taikomosios programos funkcijoms patikrinti gali būti aptikta rimtų klaidų, turinčių įtakos galutinių naudotojų darbui su programa.
Pavyzdžiui, beždžionės, išbandžiusios elektroninės prekybos svetainės mokėjimo galimybes, parodys sąlygas, trukdančias atlikti operaciją.
2. Veikimo problemos
Testuotojai gali specialiai dirbti siekdami sukurti programos našumo problemų, pavyzdžiui, užpildyti duomenų bazę įvairiais nepageidaujamais įvesties duomenimis.
Tai gali pasireikšti dideliu atsilikimu arba net bendru programinės įrangos nestabilumu, dėl kurio greičiausiai įvyks (galimas visos sistemos) gedimas.
3. Naudojamumo problemos
Atliekant šias patikras taip pat galima nustatyti sąsajos ir bendros naudotojo patirties trūkumų. Pavyzdžiui, mobiliosios programėlės vartotojo sąsaja gali skirtingai atrodyti kitoje operacinėje sistemoje ar ekrano skiriamojoje geboje. Dėl prastos sąsajos naudotojams gali būti sunku naudotis šia programa.
4. Saugumo trūkumai
Atsitiktinis ad hoc testavimo pobūdis leidžia aprėpti įvairias įprastas ir retas saugumo problemas; testuotojas gali naudoti šiuos patikrinimus, kad rastų programos administracines užkardas.
Atlikus patikrinimą gali paaiškėti, kad programinėje įrangoje nėra duomenų šifravimo.
Bendrieji ad hoc testavimo rodikliai
Ad-hoc testavimui palengvinti naudojami įvairūs rodikliai, įskaitant:
1. Defektų aptikimo efektyvumas
Pagal šį rodiklį vertinama, kaip efektyviai testavimo procese randama defektų atliekant kiekvieną testavimo formą, įskaitant ad hoc testavimą. Defektų aptikimo efektyvumas – tai aptiktų defektų procentinė dalis, padalyta iš bendro problemų skaičiaus, rodanti, kiek veiksmingi yra testai.
2. Bandymų aprėpties lygis
Pagalbinė ad hoc testavimo funkcija – padidinti aprėptį tikrinant komponentus tokiu būdu, į kurį testavimo atvejai neatsižvelgia. Tai reiškia, kad testuotojai taip pat sieks radikaliai padidinti kiekvieno patikrinimo aprėptį.
3. Bendra bandymo trukmė
Ad hoc testavimas yra daug greitesnis nei kiti kokybės užtikrinimo procesai, todėl labai svarbu, kad testuotojai dirbtų siekdami išlaikyti šį pranašumą. Bandymų trukmės rodikliai parodo komandos nariams, kaip jie gali sutaupyti laiko ir dar labiau padidinti ad hoc strategijų privalumus.
4. Avarijų skaičius
Šiais bandymais dažnai siekiama sugadinti programinę įrangą ir sukelti gedimą ar rimtą klaidą – tai leidžia jiems peržengti įprastų bandymų strategijų ribas ir rasti netikėtų problemų. Todėl gali būti naudinga žinoti, kaip dažnai programinė įranga sutrinka ir kas sukelia šias problemas.
5 geriausi ad hoc testavimo įrankiai
Yra daug nemokamų ir mokamų testavimo įrankių, skirtų ad-hoc testavimui programinės įrangos testavimo srityje – penki geriausi iš jų yra šie:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST yra išsami programinės įrangos testavimo programa, kuri tiek nemokamoje, tiek verslui skirtoje versijoje užtikrina aukšto lygio testavimo ir RPA funkcijas.
Šis pilnas programinės įrangos automatizavimo ir RPA paketas leidžia atlikti visus bandymus skirtingose darbalaukio ir mobiliosiose platformose; programinės įrangos 1SCRIPT technologija taip pat leidžia naudotojams lengvai pakartotinai atlikti tuos pačius patikrinimus. Be to, įrankis naudoja naujausius kompiuterinės vizijos pasiekimus, todėl ZAPTEST gali atlikti ad hoc testus iš žmogaus perspektyvos.
2. BrowserStack
„BrowserStack” yra debesų platforma, kuri gali palengvinti testavimą daugiau nei 3 000 įvairių mašinų, be to, ji gali automatizuoti „Selenium” scenarijus. Nors ji puikiai aprėpia programinės įrangos projektus, geriausiai tinka naršyklėms ir mobiliosioms programoms.
„BrowserStack” testavimo sprendimai taip pat apima nemokamą bandomąją versiją su 100 minučių automatinio testavimo, nors jos naudojimas gali būti ribotas.
Nors debesijos metodas gali būti naudingas, jis taip pat turi neigiamos įtakos platformos reagavimo laikui.
3. LambdaTest
„LambdaTest” taip pat naudoja debesų technologiją ir daug dėmesio skiria naršyklės bandymams, o tai gali apriboti jos veiksmingumą kitoms programoms, nors ji vis tiek puikiai tinka „iOS” ir „Android” programoms. Tai naudinga platforma, kai reikia užtikrinti mastelio keitimą, ir ji integruojama su daugeliu kitų bandymų prieglobos paslaugų.
Tačiau kai kurie naudotojai nevienareikšmiškai vertino taikomosios programos kainas įvairiose galimose ne bandomosiose parinktyse, o tai gali apriboti mažesnių organizacijų galimybes ja naudotis.
4. TestRail
TestRail apskritai yra gana lengvai pritaikoma, nes veikia tik naršyklėje, ir, nepaisant to, kad daug dėmesio skiriama veiksmingiems testavimo atvejams, taip pat gali pasigirti tiesioginėmis ad hoc funkcijomis. Po kiekvieno testo pateikiama analizė taip pat gali padėti komandoms, kurios aktyviai vengia rengti savo nepriklausomą dokumentaciją, ir kartu leisti joms patvirtinti savo testavimo procesą.
Tačiau didesniems rinkiniams gali būti sudėtinga naudoti naršyklės formatą, kuris gali gerokai apriboti ad hoc bandymų laiko sąnaudas.
5. Zefyras
„Zephyr” yra „SmartBear” sukurta bandymų valdymo platforma, padedanti kokybės užtikrinimo komandoms pagerinti bandymų matomumą ir gerai integruojama su kita klaidų stebėjimo programine įranga.
Tačiau ši funkcija taikoma tik tam tikroms programoms, iš kurių „Zephyr” labiausiai naudinga „Confluence” ir „Jira”, tačiau tai gali būti ne visiems verslams tinkamiausi sprendimai. Su „Zephyr” prekės ženklu galima įsigyti keletą keičiamo mastelio programų skirtingomis kainomis.
Ad-Hoc testavimo kontrolinis sąrašas, patarimai ir gudrybės
Pateikiame papildomų patarimų, į kuriuos komandos turėtų atsižvelgti atlikdamos ad hoc bandymus:
1. Pirmenybė jautrioms sudedamosioms dalims
Natūralu, kad kai kurioms funkcijoms ar komponentams gresia didesnė klaidų rizika nei kitiems, ypač jei jie svarbūs bendrai programos funkcijai.
Kiekvienas testavimo metodas turėtų padėti nustatyti tas programos dalis, kurioms gali būti naudinga skirti daugiau dėmesio. Tai ypač naudinga, kai bandymams skirtas laikas yra ribotas.
2. Ištirti įvairias testavimo priemones
Įrankis, kurį organizacija įdiegia testams palengvinti, gali turėti įtakos šių patikrinimų aprėpčiai ir patikimumui.
Atliekant ad hoc bandymus verta peržiūrėti kuo daugiau programų ir rasti tas, kurios atitinka į naudotoją orientuotą aspektą. Kompiuterinės regos technologiją naudojanti programinė įranga, pavyzdžiui, ZAPTEST, gali atlikti ad hoc testus naudodama strategiją, panašią į žmogaus.
3. Priimkite ad-hoc mąstyseną
Ad-hoc testavimas suteikia didžiulę laisvę visame kokybės užtikrinimo etape, tačiau komanda turi įsipareigoti jį atlikti, kad gautų pagrindinę strategijos naudą.
Pavyzdžiui, ad-hoc testuotojai turėtų atsisakyti visų įprastų dokumentų, išskyrus pagrindinius užrašus, ir jie turi tikrinti programinę įrangą iš visiškai naujos perspektyvos.
4. Pasitikėkite instinktais
Patirtis, įgyta atliekant ad hoc testavimą arba bendrą programinės įrangos patikrą, gali padėti išryškinti bendrus gedimų taškus, o tai padeda testuotojams nustatyti, kaip pastebėti visų tipų klaidas.
Labai svarbu, kad testuotojai pasitikėtų savo nuojauta ir visada naudotųsi šiomis žiniomis – jie gali intuityviai nuspėti, kurios ad hoc patikros būtų naudingiausios.
5. Išsamiai registruokite aptiktas klaidas
Nors ad hoc testavimas neturi oficialios dokumentacijos ir dažniausiai remiasi neoficialiais užrašais, vis tiek labai svarbu, kad komanda galėtų nustatyti ir pranešti apie programinės įrangos klaidos priežastį.
Jie turi užregistruoti bet kokią testo metu gautą informaciją, svarbią kūrėjams, pavyzdžiui, galimas šių problemų priežastis.
6. Visada atsižvelkite į naudotoją
Kiekviena testavimo forma siekiama tam tikru mastu pritaikyti bendrą naudotojo patirtį, ne išimtis ir ad hoc testavimas. Nors ad hoc testuotojai dažnai gilinasi į vidinį programos veikimą ir net jos vidinį kodą, jie turėtų bandyti pažeisti šią programinę įrangą taip, kaip vartotojai teoriškai galėtų.
7. Nuolatinis proceso tobulinimas
Testavimo grupės turėtų patobulinti savo požiūrį į ad hoc testavimą tarp kelių tos pačios programinės įrangos iteracijų ir nuo vieno projekto prie kito.
Jie gali rinkti kūrėjų atsiliepimus, kad sužinotų, kaip jų ad hoc testai padėjo kokybės užtikrinimo etape ir ar pavyko gerokai padidinti testų aprėptį.
Išvada
Ad-hoc testavimas gali padėti įvairaus pobūdžio organizacijoms patvirtinti savo programinės įrangos testavimo strategiją, tačiau šio metodo įgyvendinimo būdas gali būti svarbus jo veiksmingumo veiksnys.
Norint gauti didžiausią naudą iš ad-hoc patikrinimų, svarbiausia suderinti skirtingus testavimo tipus, ypač atsižvelgiant į tai, kad šia testavimo forma siekiama papildyti kitus testavimo tipus ir užpildyti strateginę spragą.
Naudodamos tokią programą kaip ZAPTEST, komandos gali patikimiau ir lanksčiau atlikti ad hoc testus, ypač jei įdiegia automatizavimą. Nepriklausomai nuo konkretaus komandos požiūrio, jos įsipareigojimas atlikti ad hoc bandymus gali iš esmės pakeisti visą programą ar projektą.
