Ad-hoc testimine on tarkvara testimise liik, mida arendajad ja tarkvaraettevõtted rakendavad tarkvara jooksva iteratsiooni kontrollimisel. Selline testimise vorm annab parema ülevaate programmist, leides probleemid, mida tavapärane testimine ei pruugi välja tuua.
On ülimalt oluline, et testimismeeskonnad mõistaksid ad hoc testimise protsessi täielikult, et nad teaksid, kuidas selle väljakutsetest mööda hiilida ja tagada, et meeskond saaks seda tehnikat edukalt rakendada.
Teadmine, kuidas ad hoc testimine täpselt toimib ja millised vahendid võivad selle rakendamist hõlbustada, võimaldab ettevõttel pidevalt täiustada oma kvaliteedi tagamise menetlusi. Ametlik testimisprotsess järgib väga konkreetseid reegleid, mille tulemusel võib meeskond jätta teatud vead tähelepanuta – ad-hoc kontrollid võimaldavad neid pimedaid kohti vältida ja testida kiiresti kõiki tarkvara funktsioone.
Selles artiklis uurime lähemalt ad-hoc testimist ja seda, kuidas saate seda tarkvara tootearenduses enda kasuks kasutada.
Ad-Hoc testimine Tähendus: Mis on Ad-Hoc testimine?
Ad-hoc testimine on kvaliteedi tagamise protsess, mis väldib formaalseid reegleid ja dokumentatsiooni – see aitab testijatel leida rakenduses vigu, mida tavapärased lähenemisviisid ei suuda tuvastada. See eeldab tavaliselt põhjalikke teadmisi tarkvarast enne testimise alustamist, sealhulgas programmi sisemise toimimise mõistmist. Nende ad hoc kontrollide eesmärk on rikkuda rakendust viisil, mis kajastab kasutaja sisestatud andmeid, võttes arvesse erinevaid võimalikke olukordi, et arendajad saaksid parandada olemasolevaid probleeme.
Dokumentatsiooni puudumine on selle tehnika keskne osa, mis ei sisalda kontrollnimekirja ega testjuhtumeid, mis juhiksid testijaid rakenduse funktsioonide üle. Ad-hoc testimine seisneb täielikult selles, et tarkvara testitakse nii, nagu meeskond otsustab, et see on sel konkreetsel hetkel tõhus. See võib võtta arvesse juba olemasolevaid formaalseid teste, kuid võib ka lihtsalt hõlmata võimalikult paljude testide läbiviimist (tõenäoliselt piiratud) aja jooksul, mis on selleks tehnikaks ette nähtud.
1. Millal ja miks on tarkvara testimisel vaja teha ad-hoc testimist?
Peamine põhjus, miks ettevõtted viivad läbi ad hoc testimist, on selle võime avastada vigu, mida traditsioonilised lähenemisviisid ei suuda leida. Selle põhjuseks võib olla mitu põhjust, näiteks tavapärased testjuhtumid, mis järgivad eriti standardiseeritud protsessi, mis ei suuda arvestada rakenduse eripärasid.
Iga testimise tüüp võib pakkuda uusi vaatenurki ja huvitavaid lähenemisviise kvaliteedi tagamisele – see näitab ka tavapärase testimisstrateegia probleeme. Näiteks kui ad-hoc testimine tuvastab probleemi, mida meeskonna testjuhtumid ei käsitle, tähendab see, et nad võiksid oma testimismetoodikat ümber kalibreerida.
Testijad võivad testimise käigus igal hetkel teha ad-hoc kontrolle. See on tavaliselt traditsioonilise (ja formaalsema) kvaliteedi tagamise täienduseks ning seda silmas pidades võivad testijad teostada ad hoc kontrolle, samal ajal kui nende kolleegid viivad läbi formaalsemaid kontrolle. Selle asemel võivad nad siiski eelistada jätta ad-hoc kontrollid alles pärast ametlikku testimisprotsessi, mis on spetsiaalselt suunatud võimalikele pimedatele kohtadele.
Ad-hoc testimine võib olla kasulik ka siis, kui aeg on dokumentatsiooni puudumise tõttu eriti piiratud – õige aeg sõltub ettevõttest ja tema eelistatud lähenemisviisist.
2. Kui teil ei ole vaja teha ad-hoc testimist.
Kui ei ole piisavalt aega nii ad-hoc- kui ka formaalse testimise läbiviimiseks, on oluline, et meeskond seaks esikohale viimase, sest see tagab olulise testimise ulatuse – isegi kui mõned lüngad on veel olemas.
Kui meeskonna formaalsed testid leiavad parandamist vajavaid vigu, on üldiselt parem oodata, kuni arendajad on vajalikud muudatused lõpule viinud, et viia sisse ad-hoc kontrollid. Vastasel juhul võivad nende tulemused varsti vananeda, eriti kui testid on seotud komponendiga, milles juba esineb vigu.
Lisaks sellele peab enne beetatestimise etappi toimuma ad-hoc testimine.
3. Kes on kaasatud ad hoc testimisse?
Ad-Hoc-testimise protsessis on mitu võtmerolli, sealhulgas:
– Tarkvara testijad on peamised meeskonnaliikmed, kes viivad läbi ad hoc kontrolle. Kui rakendatakse sõbra- või paaristesti, siis töötavad mitu testijat koos samade komponentide kallal.
– Arendajad võivad iseseisvalt kasutada neid kontrolle enne ametlikku kvaliteedi tagamise etappi oma tarkvara kiireks kontrollimiseks, kuigi see on vähem põhjalik kui spetsiaalne ad hoc testimine.
– Meeskonna- või osakonnajuhid annavad loa üldiseks testimisstrateegiaks – nad aitavad testijatel määrata, millal alustada ad hoc testimist ja kuidas seda teha, ilma et see häiriks teisi kontrolle.
Ad-Hoc testimise eelised
Ad-hoc testimise eelised tarkvara testimisel on järgmised:
1. Kiired resolutsioonid
Kuna need testid ei hõlma sagedast dokumenteerimist enne kontrollimist, selle ajal või pärast seda, on meeskondadel võimalik probleemid palju kiiremini tuvastada. Selline lihtsus pakub testijatele tohutut vabadust.
Näiteks kui nad testivad mingit komponenti ja ei suuda tuvastada ühtegi viga, võib meeskond lihtsalt minna edasi järgmise testiga, märkimata seda dokumendis.
2. Täiendab teisi testimisviise
Ükski testimisstrateegia ei ole täiuslik ja 100% katvust on tavaliselt võimatu saavutada – isegi põhjaliku ajakava puhul. Tavapärases testimises on alati lünki, seega on oluline, et ettevõtted integreeriksid mitmeid lähenemisviise.
Ad-hoc testimise eesmärk on leida probleemid, mida formaalne testimine ei suuda katta, tagades sellega laiema üldise testimise ulatuse.
3. Paindlik täitmine
Ad-hoc-testimine võib toimuda kvaliteedi tagamise protsessi mis tahes etapis enne beetatestimist, võimaldades ettevõtetel ja meeskondadel otsustada, millal on kõige parem neid kontrolle teostada. Nad võivad valida, kas teha ad-hoc teste samaaegselt tavapärase testimisega või oodata kuni hiljem – ükskõik, mis ka ei oleks, meeskond saab kasu nende käsutuses olevatest valikutest.
4. Suurem koostöö
Arendajad on sellesse protsessi rohkem kaasatud kui paljudesse teistesse testimisviisidesse – eriti kui ettevõte kasutab sõbra- ja paartestimist.
Selle tulemusel saavad arendajad parema ülevaate oma rakendustest ja võivad olla võimelised parandama vigade kõrvaldamist kõrgemal tasemel. See aitab veelgi parandada tarkvara üldist kvaliteeti.
5. Erinevad perspektiivid
Ad-hoc testimine võib näidata rakendust uute nurkade alt, aidates testijatel neid funktsioone uutmoodi kasutada. Täiendavad vaatenurgad on kogu testimise ajal kriitilise tähtsusega, sest ametlikes kontrollides on sageli vähemalt väiksemaid lünki.
Kui ad-hoc testijad kasutavad tarkvara konkreetselt eesmärgiga seda rikkuda, saavad nad programmi piirid kergemini välja selgitada.
Ad-Hoc-testimise väljakutsed
Ad-hoc testimise protsessiga kaasnevad ka mitmed probleemid, näiteks:
1. Raskused aruandluses
Dokumentatsiooni puudumine muudab ad-hoc testimise palju kiiremaks, kuid võib ka raskendada aruandlust, kui tegemist ei ole suurema probleemiga.
Näiteks võib üks varem läbi viidud kontroll muutuda hiljem asjakohasemaks, kuigi esialgu ei andnud olulisi tulemusi. Ilma põhjaliku dokumentatsioonita ei pruugi meeskond olla võimeline neid teste selgitama.
2. Vähem korratav
Samamoodi ei pruugi testijad olla täielikult teadlikud sellest, millised tingimused on vajalikud nende poolt täheldatud reaktsioonide tekkimiseks. Näiteks ei pruugi ad hoc kontroll, mis tagastab vea, sisaldada piisavalt teavet, et meeskond saaks meetmeid võtta. Nad ei pruugi olla teadlikud, kuidas seda testi korrata ja saada sama tulemus.
3. Nõuab tarkvarakogemust
Kuna kiirus on kogu ad-hoc testimise ajal võtmetähtsusega ja tavaliselt hõlmab see püüdlusi rakenduse rikkumiseks, on oluline, et need testijad tunneksid seda programmi väga hästi.
Teadmised selle toimimisest võimaldavad testijatel tarkvara rikkuda ja sellega rohkem manipuleerida, kuid see võib oluliselt suurendada ad-hoc testimise oskuste nõudmisi.
4. Piiratud vastutus
Dokumentatsiooni puudumine võib põhjustada rohkem probleeme kui lihtsalt kehv aruandlus; see võib ka tahtmatult pikendada testimisprotsessi, mõjutades üksikute kiirete ad-hoc testide kasulikkust.
Testijatel võib olla raske jälgida oma edusamme ilma piisava dokumentatsioonita igas etapis. See võib isegi viia selleni, et nad kordavad kontrolli, mille teised testijad on juba lõpetanud.
5. Ei pruugi kajastada kasutajakogemust
Praktiliselt iga testimise eesmärk on võtta arvesse vigu, mis mõjutavad lõppkasutajaid mingil viisil. Ad-hoc testimine tugineb peamiselt sellele, et kogenud testija üritab jäljendada kogenematuid kasutajaid ja see peaks olema järjepidev iga kontrolli puhul, sealhulgas nende katsete puhul rakenduse rikkumiseks.
Ad-Hoc testide omadused
Edukate ad-hoc testide peamised omadused on järgmised:
1. Uurimine
Ad-hoc-testimise peamine prioriteet on tuvastada rakendusega seotud vead, kasutades meetodeid, mida tavapärased kontrollid ei arvesta. Ad-hoc-uuringud uurivad seda tarkvara selgesõnaliselt selleks, et leida lüngad meeskonna testimismenetluses, sealhulgas nende testjuhtumite katvuses.
2. Struktureerimata
Ad hoc kontrollidel ei ole tavaliselt mingit kindlat plaani peale võimalikult paljude testide läbiviimise väljaspool formaalse kvaliteedi tagamise tüüpilisi piire. Testijad rühmitavad kontrollid tavaliselt komponentide kaupa, kuid isegi see ei ole vajalik – nad võivad kontrollide tegemise ajal neid isegi välja mõelda.
3. Kogemuspõhine
Ad-hoc testijad kasutavad oma eelnevat tarkvarakogemust, et hinnata, millised testid tooksid kõige rohkem kasu ja tegeleksid formaalse testimise tavaliste pimedate kohtadega.
Kuigi testimisprotsess on endiselt täiesti struktureerimata, rakendavad testijad oma strateegia üle otsustamisel muu hulgas oma teadmisi varasematest ad-hoc kontrollidest.
4. Laialdane
Ei ole täpseid juhiseid selle kohta, milliseid kontrolle meeskond peaks ad hoc testimise käigus läbi viima, kuid tavaliselt hõlmavad need erinevaid komponente – võimaluse korral keskendudes rohkem rakenduse tundlikumatele aspektidele. See aitab testijatel tagada, et nende eksamid suudavad täielikult täiendada formaalset testimist.
Mida me testime Ad-Hoc testides?
Kvaliteedi tagamise meeskonnad testivad ad hoc testimise käigus tavaliselt järgmist:
1. Tarkvara kvaliteet
Nende kontrollide eesmärk on tuvastada rakenduses vigu, mida tavapärane testimine ei suuda avastada; see tähendab, et protsessiga testitakse peamiselt rakenduse üldist tervislikku seisundit.
Mida rohkem vigu on võimalik ad-hoc-testimisega leida, seda rohkem parandusi saavad arendajad enne tähtaega rakendada.
2. Testjuhtumid
Ad-hoc testimine ei rakenda üldiselt testjuhtumeid – ja seda just selleks, et meeskond saaks uurida, kui tõhusalt nad katavad piisavalt. Testjuhtumid on tõenäoliselt ebapiisavad, kui ad-hoc kontrollid võivad leida vigu, mida tavapärased testimisprotsessid ei suuda leida.
3. Testimise personal
Eesmärk võiks olla ka testimismeeskonna oskuste ja teadmiste kontrollimine, isegi kui testjuhtumid on piisavad. Näiteks võib nende juhtumite rakendamise metoodika olla ebapiisav ja ad-hoc testimine võib olla kriitilise tähtsusega, et lahendada sellest tulenevaid lünki testide katvuses.
4. Tarkvara piirangud
Ad-hoc-testimisega püütakse mõista ka rakenduse piiranguid – näiteks kuidas see reageerib ootamatutele sisenditele või suurele süsteemikoormusele. Testijad võiksid konkreetselt uurida programmi veateateid ja seda, kui hästi see rakendus toimib märkimisväärse surve all.
Mõningate segaduste selgitamine:
Ad-Hoc testimine ja uurimuslik testimine
Mõned inimesed peavad ad-hoc- ja uurimuslikku testimist sünonüümideks, kuigi tõde on sellest keerulisem.
1. Mis on uurimuslik testimine?
Uurija testimine viitab kvaliteedi tagamise menetlustele, mis uurivad tarkvara terviklikust vaatenurgast ning ühendavad avastamis- ja testimisprotsessi üheks meetodiks. See on tavaliselt kesktee täielikult struktureeritud testimise ja täiesti vabas vormis ad-hoc kontrollide vahel.
Uurimuslik testimine toimib kõige paremini konkreetsete stsenaariumide puhul, näiteks kui on vaja kiiret tagasisidet või kui meeskond peab tegelema äärmuslikkusega. Seda tüüpi testimine saavutab tavaliselt oma täieliku potentsiaali, kui meeskond kasutab selle kõrval skriptidega testimist.
2. Erinevused uurimusliku testimise vahel
ja ad-hoc testimine
Suurim erinevus ad-hoc- ja uurimusliku testimise vahel on see, et esimene kasutab dokumentatsiooni kontrollide registreerimiseks ja hõlbustamiseks, samas kui ad-hoc-testimine väldib seda täielikult. Uurimuslik testimine paneb suuremat rõhku testimisvabadusele, kuid mitte kunagi samal tasemel kui ad-hoc lähenemine, mis on täiesti struktureerimata.
Uuriv testimine hõlmab ka rakenduse ja selle sisemise toimimise tundmaõppimist nende kontrollide käigus – ad-hoc testijatel on selle asemel sageli juba enne alustamist põhjalikud teadmised tarkvara funktsionaalsusest.
Ad-Hoc testide tüübid
Tarkvara testimisel on kolm peamist ad-hoc testimise vormi, sealhulgas:
1. Ahvide testimine
Võib-olla kõige populaarsem ad-hoc-testimise tüüp on ahvitestid, mille puhul meeskond vaatab juhuslikult erinevaid komponente.
See toimub tavaliselt ühiktestimise käigus ja rakendab rea kontrolle ilma testjuhtumiteta. Testijad uurivad iseseisvalt andmeid täiesti struktureerimata viisil, mis võimaldab neil uurida laiemat süsteemi ja selle võimet seista vastu kasutajate sisendite intensiivsele koormusele.
Nende skriptimata meetodite väljundite jälgimine aitab testimismeeskonnal tuvastada vigu, mis on jäänud teiste ühiktestide puhul tähelepanuta tavapäraste testimismeetodite puuduste tõttu.
2. Sõbralik testimine
Ad-hoc-kontekstis kasutatakse sõbertestide puhul vähemalt kahte töötajat – tavaliselt testijat ja arendajat – ning need toimuvad peamiselt pärast ühiktestimise etappi. Sõbrad töötavad koos ühe ja sama mooduliga, et tuvastada vigu. Nende mitmekülgsed oskused ja põhjalik kogemus muudavad nad tõhusamaks meeskonnaks, mis aitab leevendada paljusid probleeme, mis tekivad dokumentatsiooni puudumise tõttu.
Arendaja võib isegi ise soovitada mõningaid teste, võimaldades neil tuvastada komponendid, mis võivad vajada rohkem tähelepanu.
3. Paartestimine
Paartestimine on sarnane, sest selles osaleb kaks töötajat, kuid tavaliselt on tegemist kahe eraldi testijaga, kellest üks viib läbi tegelikke teste, samal ajal kui teine teeb märkmeid.
Isegi ilma ametliku dokumentatsioonita võib märkmete tegemine võimaldada meeskonnal mitteametlikult jälgida üksikuid ad hoc kontrolle. Testija ja kirjutaja rollid võivad sõltuvalt testist vahetuda või paar võib säilitada oma määratud rollid kogu protsessi jooksul.
Testija, kellel on rohkem kogemusi, on tavaliselt see, kes teostab tegelikku kontrolli – kuigi nad jagavad alati tööd omavahel.
Manuaalsed või automatiseeritud Ad-Hoc testid?
Automatiseeritud testimine aitab meeskondadel säästa veelgi rohkem aega kogu kvaliteedi tagamise etapis, mis võimaldab testijatel oma ajakavasse rohkem kontrolle mahutada. Isegi ilma kindla struktuurita on oluline, et testijad töötaksid katvuse maksimeerimiseks ja automatiseerimine soodustab selle tarkvara põhjalikumat kontrollimist.
Automatiseeritud ad-hoc kontrollid on üldiselt täpsemad kui käsitsi tehtavad testid, kuna nad suudavad vältida inimlikke vigu rutiinsete ülesannete täitmisel – see on eriti kasulik, kui samu teste tehakse eri iteratsioonidel. Selle menetluse edu sõltub tavaliselt sellest, millise automatiseeritud testimisvahendi meeskond valib ja milline on selle funktsionaalsus.
Automatiseeritud testimisel on siiski teatavad piirangud. Näiteks on ad-hoc-testimise peamine tugevus selle võime jäljendada kasutaja sisendit ja rakendada juhuslikke kontrolle, kui testija neid välja mõtleb. Need testid võivad kaotada oma juhuslikkuse, kui organisatsiooni testimisprogrammil on raskusi keeruliste kontrollide läbiviimisega.
Nende väga spetsiifiliste ülesannete automatiseerimiseks kuluv aeg võib samuti piirata selle protsessi tüüpilist aja kokkuhoidu. On oluline, et meeskonnad uuriksid põhjalikult olemasolevaid automatiseerimisvahendeid, et leida oma ettevõtte projektile sobiv vahend.
Mida on vaja Ad-Hoc-testimise alustamiseks?
Järgnevalt on esitatud ad hoc testimise peamised eeldused:
1. Kvalifitseeritud töötajad
Kuna ad-hoc testid on tarkvara sisemise toimimise kiire ja juhuslik kontroll, on tavaliselt kasulik, kui testijad on tarkvaraga kogenud. Samuti peaksid nad tundma peamisi testimispõhimõtteid – see võimaldab neil hõlpsasti kindlaks teha kõige tõhusamad kontrollid.
2. Struktureerimata lähenemisviis
Testijad peavad olema valmis loobuma oma tavapärastest ad hoc testimise strateegiatest; see mõtteviis on sama oluline kui kvaliteedikontroll ise. See meetod saab olla edukas ainult ilma struktuuri või dokumentatsioonita ning on väga oluline, et testijad seda igas etapis meeles peaksid.
3. Automaatika tarkvara
Kuigi ad-hoc testimine tugineb rohkem juhuslike sisendite ja tingimuste testimisele, on automatiseerimine siiski väga tõhus tehnika igas kontekstis.
Seetõttu tuleks ad-hoc-kontrollide puhul võimaluse korral siiski kasutada automatiseeritud testimisvahendeid, sest õige rakendus võib protsessi märkimisväärselt lihtsustada.
4. Muud testimise vormid
Ad-hoc testid toimivad kõige paremini koos teiste kontrollide kõrval, mis kasutavad formaalsemat lähenemist, aidates meeskonnal tagada märkimisväärse katvuse kogu tarkvaras. Oluline on, et testijad segaksid erinevaid tehnikaid, kuigi see võib toimuda enne, ajal või pärast ad hoc testimist.
Ad-Hoc testimise protsess
Tavalised sammud, mida testijad peaksid järgima, kui nad viivad läbi ad hoc testimist tarkvara testimisel, on järgmised:
1. Ad-hoc testi eesmärkide määratlemine
See etapp on piiratud dokumentatsiooni ja struktuuri puudumise tõttu, kuid on siiski ülioluline, et meeskonnal oleks selge fookus. Testijad võivad hakata jagama ebamääraseid ideid selle kohta, milliseid eelseisvaid teste tuleb käivitada ja milliseid komponente eelistada.
2. Ad-hoc testi meeskonna valimine
Kui meeskond mõtleb välja mitmeid võimalikke ad-hoc kontrolle, mõtlevad nad ka välja, millised testijad oleksid parimad seda tüüpi testimiseks. Nad valivad tavaliselt testijad, kes mõistavad rakendust põhjalikult, ja võivad neid ka arendajaga paaritada.
3. Ad-hoc testide teostamine
Pärast seda, kui on otsustatud, millised testijad on selleks etapiks sobivad, alustavad need meeskonnaliikmed oma kontrollimist kokkulepitud testimise punktis. Nende eesmärk on teostada võimalikult palju ad hoc kontrolle, mida testijad ei pruugi enne seda etappi välja töötada.
4. Katsetulemuste hindamine
Pärast testide lõpetamist (või isegi üksikute kontrollide vahel) hindavad testijad tulemusi, kuid ilma neid ametlikult testjuhtumina dokumenteerimata. Kui nad avastavad rakendusega seotud probleeme, registreerivad nad need mitteametlikult ja arutavad meeskonna järgmisi samme.
5. Avastatud vigadest teatamine
Pärast tulemuste hindamist peavad testijad teavitama arendajaid tarkvaras esinevatest vigadest, et neil oleks piisavalt aega neid enne väljalaskmist parandada.
Testimismeeskond kasutab teavet ka selleks, et määrata kindlaks, kuidas parandada oma ametlikke testimisprotsesse.
6. Vajaduse korral korduvkatsetused
Tõenäoliselt kordab testimismeeskond ad-hoc protsessi rakenduse uute iteratsioonide puhul, et kontrollida, kui hästi see uuendustega toime tuleb. Kuna testijad on parandanud paljud eelnevalt tuvastatud lüngad oma testjuhtumites, võivad tulevased ad hoc kontrollid nõuda teistsugust lähenemist.
Ad-Hoc testimise parimad tavad
On olemas teatavad tavad, mida testimismeeskonnad peaksid ad hoc testimise ajal rakendama, sealhulgas:
1. Võimalikud puudujäägid testimises
Kuigi ad hoc testimine hõlmab palju vähem planeerimist kui muud tüüpi testimine, on meeskonna eesmärk siiski tegeleda kvaliteedi tagamise puudustega. Kui ad-hoc testijad kahtlustavad meeskonna testjuhtumite puhul mingeid konkreetseid probleeme, peaksid nad seda kontrollide läbiviimisel prioriteediks seadma.
2. Kaaluge automatiseerimistarkvara
Automatiseerimisstrateegiad, nagu hüperautomaatika, võivad pakkuda ettevõtetele, kes soovivad teha ad hoc teste, palju eeliseid.
Selle edukus sõltub mitmest võtmetegurist, sealhulgas ettevõtte valitud tööriistast ja nende ad-hoc testide üldisest keerukusest.
3. Tehke põhjalikke märkmeid
Dokumentatsiooni puudumine ad hoc testimisel on peamiselt selleks, et seda protsessi veelgi lihtsustada – meeskonnale võiks olla kasulik teha mitteametlikke märkmeid, kui nad jätkavad tööd. See annab testijatele selge ülevaate nendest kontrollidest ja nende tulemustest, suurendades nende üldist korratavust.
4. Jätkake testide täiustamist
Ad-hoc testijad täiustavad pidevalt oma lähenemisviisi, et võtta arvesse muudatusi meeskonna testimisstrateegias. Näiteks ettevõtte tarkvara uuemaid versioone vaadates võivad nad neid kontrolle kohandada vastavalt uuematele ja kõikehõlmavamatele formaalsetele testjuhtumitele.
7 viga ja lõksu rakendamisel
Ad-Hoc testid
Nagu iga testimisprotsessi puhul, on olemas suur hulk võimalikke vigu, mida meeskond peaks püüdma vältida, näiteks:
1. Kogemusteta testijad
Selleks, et säilitada ad hoc testimise eeldatav tempo, peab meeskonna juht määrama testijad vastavalt nende teadmistele ja oskustele. Kuigi paljud testimise vormid sobivad algtasemel kvaliteedi tagamise töötajatele, nõuavad ad hoc kontrollid meeskonnaliikmeid, kes mõistavad tarkvara täielikult; eelistatavalt on neil kogemused nende testide läbiviimisel.
2. Ebaotstarbelised kontrollid
Ad-hoc testimine võib tänu kiiremale tempole oluliselt parandada testide katvust – meeskond ei pea enne ja pärast iga kontrolli täitma ulatuslikku dokumentatsiooni.
Siiski peavad ad-hoc testijad siiski säilitama tugeva fookuse; näiteks võivad nad otsustada, et seavad prioriteediks teatud komponendid, mille puhul on suurem risk, et need ebaõnnestuvad.
3. Planeerimine puudub
Igasuguse plaani vältimine võib piirata ad hoc testimise tõhusust. Hoolimata selle lähenemisviisi struktureerimata olemusest on oluline, et meeskonnal oleks enne alustamist ligikaudne ettekujutus sellest, milliseid teste tuleb läbi viia.
Aeg on selle protsessi ajal piiratud ja teadmine, kuidas toimida, võib pakkuda palju kasu.
4. Liiga struktureeritud
Spektri teises otsas tugineb selline lähenemine tavaliselt planeerimise puudumisele, kuna see aitab testijatel aktiivselt testjuhtumeid õõnestada ja varjatud vigu leida.
Ad hoc testimine on tuntud ka kui juhuslik testimine ja struktuuri peale sundimine võib takistada nende kontrollide abil vigade leidmist.
5. Pikaajalised muutused puuduvad
Ad-hoc testimise eesmärk on tuvastada meeskonna testjuhtumite võimalikud nõrgad kohad; see uurib nende üldist strateegiat sama palju kui tarkvara ennast.
See tähendab aga, et ad hoc testid on üldiselt tõhusad ainult siis, kui meeskond kasutab seda teavet, et aja jooksul täiustada oma ametlikke kontrolle.
6. Ühildumatud andmekogumid
Praktiliselt iga testimise vorm nõuab mingisugust simuleeritud andmete vormi, et hinnata, kuidas rakendus reageerib; mõned tööriistad võimaldavad testijatel automaatselt täita programmi mock-andmetega.
See ei pruugi siiski kajastada seda, kuidas kasutaja tarkvaraga tegeleks – ad hoc kontrollid nõuavad andmekogumeid, millega tarkvara tõenäoliselt kokku puutub.
7. Teabesilod
Oluline on, et testijad ja arendajad suhtleksid pidevalt omavahel, isegi kui viimane ei osale ad hoc testimisprotsessis.
See aitab kõigil aru saada, millised testid on tehtud – see näitab, millised on järgmised tegevused, vältides samal ajal, et testijad ei kordaks tarbetult teatud kontrolle.
Ad-Hoc testide väljundite tüübid
Ad-hoc-kontrollid annavad mitu erinevat väljundit, sealhulgas:
1. Katsetulemused
Üksikud testid annavad erinevaid tulemusi, mis sõltuvad konkreetsest komponendist ja lähenemisviisist – see võib toimuda mitmes vormis.
Tavaliselt on testija ülesanne kindlaks teha, kas tulemused kujutavad endast viga, kuigi dokumentatsiooni puudumise tõttu on seda raske võrrelda nende ootustega. Meeskond edastab need tulemused arendajatele, kui nad märkavad mingeid probleeme.
2. Katseprotokollid
Tarkvara ise kasutab keerukat sisemiste logide süsteemi, et jälgida kasutaja sisestusi ja tuua esile mitmeid võimalikke faili- või andmebaasiprobleeme.
See võib viidata sisemisele veale, sealhulgas probleemi põhjustavale tarkvara konkreetsele osale. Selle teabe abil saavad ad-hoc testijad ja arendajad avastatud probleeme palju lihtsamalt lahendada.
3. Veateated
Paljude ad-hoc-kontrollide eesmärk on spetsiaalselt rikkuda tarkvara ja paljastada selle piirid, mis tähendab, et rakenduse veateated on üks nende testide kõige tavalisemaid väljundeid.
Tahtlikult veateateid tekitades saab meeskond näidata, mida keskmine lõppkasutaja näeb alati, kui tema ootamatu tegevus mõjutab programmi tööd negatiivselt.
Ad-Hoc testimise näited
Siin on kolm ad hoc testimisstsenaariumi, mis näitavad, kuidas meeskond võiks seda erinevate rakenduste puhul rakendada:
1. E-kaubanduse veebirakendus
Kui ettevõte soovib testida e-kaubandusel põhinevat veebirakendust, võib ta kasutada ad-hoc testimist – täpsemalt ahvitestimist -, et näha, kui hästi platvorm käitub ootamatute kasutajate interaktsioonidega.
Testijad võivad püüda iga funktsiooni piirini viia, näiteks lisades oma ostukorvi ebareaalses koguses kaupu või püüdes osta tooteid, mis on laos otsas. Neid ei piira meeskonna testjuhtumid ja neil on vähe piiranguid, milliseid kontrolle nad võiksid teostada; testijad võivad isegi proovida ostude lõpuleviimist, kasutades vananenud URL-aadressi.
2. Töölaua rakendus
Ad-hoc testijad saavad neid meetodeid rakendada ka lauaarvutirakenduste puhul, keskendudes võimaluse korral erinevatele masinatele ja sellele, kui hästi need kõik programmi vastu võtavad.
Meeskonnaliikmed võivad neid kontrolle teha korduvalt, et näha, kuidas muutuvad riist- või tarkvaraseaded mõjutavad rakenduse üldist jõudlust. Näiteks võib teatud graafikakaardil olla raskusi liidese esitamisega.
Alternatiivina võiksid need testijad lihtsalt anda oma programmile võimatuid sisendeid ja vaadata, kuidas see reageerib, näiteks kas see suudab korrektselt kuvada veateateid, mis selgitavad probleemi lõppkasutajale piisavalt.
3. Mobiilirakendus
Üks võimalus, kuidas ad-hoc testijad võiksid uurida mobiilirakendust, on selle turvaprotokollide testimine – nad võiksid näiteks proovida pääseda otse ligi rakenduse arendusvahenditele.
Meeskond võib proovida, kas nad on võimelised sooritama volitamata tegevusi, leides tavalisi lünki ja ärakasutamisvõimalusi; nad võiksid konkreetselt paluda rakenduse turvalisuse alal kogenud töötajaid, et nad seda hõlbustaksid.
See võib hõlmata ka paaristesteerimist koos arendajatega, kuna nad saavad rakenduse disaini paremini tundma õppida, võimaldades testijal tarkvara rikkuda ja näidata täpselt, kus selle turvalisus on puudulik.
Tuvastatud vigade ja vigade tüübid
Ad-Hoc testimise kaudu
Ad-hoc kontrollid võivad paljastada palju probleeme programmis, näiteks:
1. Funktsionaalsuse vead
Ad-hoc testimise kasutamine rakenduse põhifunktsioonide uurimiseks võib paljastada tõsiseid vigu, mis mõjutavad seda, kuidas lõppkasutajad võivad seda kasutada.
Näiteks illustreerib e-kaubanduse saidi maksevõimaluste ahvtestimine tingimusi, mis takistavad tehingu sooritamist.
2. Tulemuslikkuse probleemid
Testijad võivad spetsiaalselt töötada selle nimel, et tekitada programmis jõudlusprobleeme – näiteks täita andmebaasi erinevate rämpsposti sisenditega.
See võib avalduda märkimisväärse viivituse või isegi üldise tarkvara ebastabiilsuse kujul, mis tõenäoliselt viib (potentsiaalselt kogu süsteemi hõlmava) krahhi tekkimiseni.
3. Kasutatavuse probleemid
Need kontrollid võivad esile tuua ka kasutajaliidese ja üldise kasutajakogemuse vead. Näiteks võib mobiilirakenduse kasutajaliides olla teises operatsioonisüsteemis või ekraani resolutsioonis erinev. Halb kasutajaliides võib põhjustada kasutajatele raskusi selle rakenduse kasutamisel.
4. Turvalisuse puudused
Ad-hoc-testimise juhuslik iseloom võimaldab katta mitmesuguseid tavalisi ja haruldasi turvaprobleeme; testija võib neid kontrolle kasutada programmi haldusalaste tagauste leidmiseks.
Teise võimalusena võib nende kontrollimine näidata, et tarkvara ei ole andmete krüpteeritud.
Üldised ad-hoc testimise näitajad
Ad-hoc testimine kasutab tulemuste saavutamise hõlbustamiseks erinevaid mõõdikuid, sealhulgas:
1. Defektide tuvastamise tõhusus
See mõõdik näitab, kui tõhus on testimisprotsess defektide leidmisel igas testimisviisis, sealhulgas ad-hoc testimisel. Defektide tuvastamise tõhusus on avastatud defektide protsent, mis jagatakse probleemide koguarvuga – see näitab, kui tõhusad on testid.
2. Testide katvuse määr
Ad-hoc testimise abifunktsioon on katvuse suurendamine, kontrollides komponente viisil, mida testjuhtumid ei arvesta. See tähendab, et testijad püüavad ka radikaalselt suurendada testide katvust iga kontrolli puhul nii palju kui võimalik.
3. Katse kogukestus
Ad-hoc testimine on palju kiirem kui muud kvaliteedi tagamise protsessid – ja on oluline, et testijad töötaksid selle eelise säilitamiseks. Testide kestuse näitajad näitavad meeskonnaliikmetele, kuidas nad saavad aega säästa ja ad-hoc strateegiate eeliseid veelgi suurendada.
4. Õnnetusjuhtumite arv
Nende testide eesmärk on tihtipeale rikkuda tarkvara ja põhjustada krahhi või tõsine viga, mis võimaldab neil minna kaugemale tavapärastest testimisstrateegiatest ja leida ootamatuid probleeme. Selleks võib aidata teada, kui sageli tarkvara jookseb kokku ja mis neid probleeme põhjustab.
5 parimat Ad-Hoc testimise tööriista
Tarkvara testimiseks on saadaval palju tasuta ja tasulisi testimisvahendeid – viis parimat on järgmised:
1. ZAPTEST Free & Enterprise Edition
ZAPTEST on terviklik tarkvara testimise programm, mis pakub tugevat testimise + RPA funktsionaalsust nii tasuta kui ka ettevõtte versioonis.
See täisfunktsionaalne tarkvaraautomaatika + RPA Suite võimaldab täielikku testimist erinevatel töölaua- ja mobiiliplatvormidel; tarkvara 1SCRIPT-tehnoloogia võimaldab kasutajatel hõlpsasti samu kontrolle korduvalt läbi viia. Lisaks sellele kasutab tööriist tipptasemel arvutinägemist, mis võimaldab ZAPTESTil teha ad-hoc teste inimese vaatenurgast.
2. BrowserStack
BrowserStack on pilveplatvorm, mis hõlbustab testimist üle 3000 erineva masina, mille lisafunktsiooniks on Seleniumi skriptide automatiseerimine. Kuigi see pakub tugevat katvust tarkvaraprojektidele, töötab see kõige paremini brauserite ja mobiilirakenduste puhul.
BrowserStacki testimislahendused sisaldavad ka tasuta prooviversiooni, mis sisaldab 100 minutit automaatset testimist – kuigi selle kasutusala võib olla piiratud.
Kuigi pilvepõhine lähenemisviis võib olla kasulik, mõjutab see ka negatiivselt platvormi reageerimisaega.
3. LambdaTest
LambdaTest kasutab sarnaselt pilvepõhist tehnoloogiat ja paneb suurt rõhku brauseritestimisele, mis võib piirata selle tõhusust teiste rakenduste puhul – kuigi see sobib siiski hästi iOS-i ja Android-programmidega. See on kasulik platvorm, kui mureks on skaleeritavus, ja see on integreeritud paljude teiste testimisteenustega.
Mõned kasutajad on siiski mitmeti reageerinud rakenduse hinnakujundusele erinevate saadaval olevate mitte-testimisvõimaluste puhul, mis võib piirata väiksemate organisatsioonide juurdepääsu.
4. TestRail
TestRail on üldiselt üsna kohanemisvõimeline, kuna töötab täielikult brauseris, ja hoolimata tugevast keskendumisest tõhusatele testjuhtumitele on tal ka otsene ad-hoc-funktsionaalsus. Analüütika, mida see pakub pärast iga testi, võib aidata ka meeskondi, kes aktiivselt väldivad oma iseseisva dokumentatsiooni koostamist, võimaldades neil siiski oma testimisprotsessi valideerida.
Suuremad komplektid võivad aga hädas olla selle brauseripõhise formaadiga, mis võib ad-hoc-testimise aja kokkuhoidu oluliselt piirata.
5. Zephyr
Zephyr on SmartBeari testide haldamise platvorm, mis aitab kvaliteedi tagamise meeskondadel parandada oma testimise nähtavust, integreerudes samal ajal hästi ka muu vea jälgimise tarkvaraga.
See funktsioon on siiski piiratud teatud rakendustega, millest kõige rohkem kasu saavad Zephyrist Confluence ja Jira – need ei pruugi olla kõige tõhusamad lahendused iga ettevõtte jaoks. Zephyri kaubamärgi all on saadaval mitu erineva hinnaga skaleeritavat programmi.
Ad-Hoc testimise kontrollnimekiri, näpunäited ja nipid
Siin on täiendavaid nõuandeid, mida meeskonnad peaksid ad hoc testimise läbiviimisel arvesse võtma:
1. Tundlike komponentide prioriseerimine
Mõned funktsioonid või komponendid on loomulikult suurema veaohuga kui teised, eriti kui need on programmi üldise toimimise seisukohalt olulised.
Iga testimise lähenemisviis peaks tuvastama rakenduse need osad, millele võib olla kasulikum pöörata põhjalikumat tähelepanu. See on eriti kasulik siis, kui testimiseks kuluv aeg on piiratud.
2. Uurige erinevaid testimisvahendeid
Tööriist, mida organisatsioon rakendab oma testide hõlbustamiseks, võib mõjutada nende kontrollide ulatust ja usaldusväärsust.
Ad-hoc-testimise puhul tasub vaadata võimalikult palju programme, et leida need, mis sobivad selle kasutajakeskse aspektiga. Tarkvara, mis kasutab arvutinägemistehnoloogiat, nagu ZAPTEST, võib läheneda ad-hoc testidele, kasutades inimlikule strateegiale sarnast strateegiat.
3. Võtke vastu ad hoc mõtteviis
Ad-hoc testimine pakub tohutut vabadust kogu kvaliteedi tagamise etapis, kuid meeskond peab pühenduma sellele, et saada strateegia peamisi eeliseid.
Näiteks peaksid ad-hoc testijad loobuma kõigist oma tavapärastest dokumentidest, mis lähevad kaugemale põhilistest märkmetest, ja nad peavad kontrollima tarkvara täiesti uuest vaatenurgast.
4. Usalda testimisinstinkte
Kogemused ad-hoc-testimise või üldise tarkvara kontrollimisega võivad aidata välja tuua ühised veapunktid ja see aitab testijatel kindlaks teha, kuidas tuvastada igat liiki vigu.
Oluline on, et testijad usaldaksid oma instinkte ja kasutaksid neid teadmisi alati enda kasuks – nad oskavad aimata, millised ad-hoc kontrollid oleksid kõige kasulikumad.
5. Avastatud vigade täielik registreerimine
Kuigi ad hoc testimisel puudub ametlik dokumentatsioon ja see tugineb enamasti mitteametlikele märkmetele, on siiski oluline, et meeskond suudaks tuvastada ja edastada tarkvara vea põhjuse.
Nad peavad logima kõik testiga saadud andmed, mis on arendajatele olulised, näiteks nende probleemide võimalikud põhjused.
6. Arvestage alati kasutajaga
Iga testimise vormiga püütakse mingil määral kohandada kasutaja üldist kogemust – ja ad-hoc testimine ei ole erandiks. Kuigi see vaatab sageli sügavamalt rakenduse sisemusse ja isegi selle sisekoodi, peaksid ad-hoc testijad püüdma seda tarkvara rikkuda nii, et kasutajad teoreetiliselt saaksid seda teha.
7. Protsessi pidev täiustamine
Testimismeeskonnad peaksid täiustama oma lähenemist ad hoc testimisele sama tarkvara mitme iteratsiooni vahel ja ühest projektist teise.
Nad saavad koguda arendajatelt tagasisidet, et näha, kui hästi nende ad-hoc testid aitasid kvaliteedi tagamise etapis ja kas nad suutsid testide katvust märkimisväärselt suurendada.
Kokkuvõte
Ad-hoc testimine võib aidata igasugustel organisatsioonidel oma tarkvara testimise strateegiat autentida, kuid selle tehnika rakendamise viis võib olla selle tõhususe oluline tegur.
Erinevate testimisviiside tasakaalustamine on võti, et saada ad-hoc kontrollidest kõige rohkem kasu – eriti kuna see testimisviis on mõeldud täiendama teisi, täites strateegilist lünka.
Sellise rakendusega nagu ZAPTEST on meeskondadel võimalik teha ad hoc teste suurema kindluse või paindlikkusega, eriti kui nad rakendavad automatiseerimist. Olenemata meeskonna konkreetsest lähenemisviisist, võib nende pühendumine ad hoc testimisele muuta kogu programmi või projekti.
