Mis on Adhoc-testimine? Tüübid näitega

Mis on ad hoc testimine?

Ad hoc testimine on spontaanne ja paindlik viis tarkvara testimiseks ilma kindla plaani või dokumentatsioonita. Testjuhtumite ettevalamise asemel sukeldute otse sisse ja hakkate rakendust uurima. Termin „Ajutine” tähendab „kindlaks otstarbeks” või „planeerimata”, mis peegeldab seda testimisstiili tõeliselt.

Lubage mul lihtsalt öelda. Kujutage ette, et olen just oma seadmesse uue rakenduse installinud. Testimisetappide loendi täitmise asemel hakkan ma ringi klõpsama. Võin sisestada imelikke andmeid, kasutada rakendust ootamatutel viisidel või isegi proovida selle töövoogu meelega katkestada. Minu eesmärk on näha, kuidas rakendus hakkama saab. reaalses maailmas, ettearvamatu kasutamine– mitte ainult ideaalsed stsenaariumid.

Ad-hoc testimine paistab silma selle poolest, et see paljastab sageli probleeme, mida formaalsed testid võivad kahe silma vahele jätta. Loovalt mõeldes ja end teiste kasutajate olukorda pannes saan ma leida vead ja kasutusprobleemid mida teised võivad kahe silma vahele jätta. See meetod tugineb testija intuitsioon, kogemus, ja rakenduse põhjalik mõistmine. See on suurepärane viis vigade varajaseks märkamiseks, eriti kui aega on vähe või dokumentatsioon on piiratud.

Kuigi ad-hoc testimine võib tunduda mitteametlik, tuleneb selle tegelik väärtus testija asjatundlikkusest ja võimest mõelda väljaspool kastiSeda peetakse sageli teatud tüüpi musta kasti testimine kuna see keskendub sellele, kuidas tarkvara pinnal käitub, mitte sellele, kuidas see on sisse ehitatud. Struktureeritud testimise kõrval aitab ad hoc testimine tagada parema tulemuse. usaldusväärne ja kasutajasõbralik toode.

Järgmine video juhendab teid, kuidas adhoc-testi teha

Click siin kui video pole juurdepääsetav

Millal teha ad hoc testimist?

Ad hoc testimise parima aja teadmine võib teie tarkvara kvaliteeti oluliselt mõjutada. Aastate jooksul olen õppinud, et ajastus on selle paindliku ja spontaanse testimisviisi puhul võtmetähtsusega. Ad hoc testimine sobib ideaalselt siis, kui teil on vaja kiiresti kontrollida probleeme, mis struktureeritud testijuhtumitel võivad märkamata jääda. Uurime peamisi olukordi, kus ad hoc testimine on kõige väärtuslikum:

• Arengu algstaadium: See toimib hästi, kui ametlikud testid pole veel valmis. Saate uute funktsioonide vigu kiiresti märgata enne ametlike testiplaanide loomist.
• Enne ametliku testimise algust: Kasutage kiireks kontrolliks ad hoc testimist, et veenduda põhitõdede toimimises. See aitab vältida aja raiskamist vigaste versioonide peale ametlike testimistsüklite ajal.
• Pärast ametliku testi sooritamist: Isegi pärast kõigi testide läbimist võivad mõned vead siiski ilmneda. Ad hoc testimine võimaldab otsida defekte, mis struktureeritud testimisel võivad märkamata jääda, eriti neid, mis ei vasta dokumenteeritud nõuetele.
• Kui sul on vähe aega: Mõnikord pole lihtsalt piisavalt aega terve testimisvooru jaoks. Sellistel juhtudel saavad kogenud testijad kasutada ad hoc testimist, et leida kõige olulisemad probleemid kiiresti.
• Funktsiooni põhjalikuks uurimiseks: Kui soovite tarkvara konkreetse osa käitumist tõeliselt mõista, võimaldab ad hoc testimine teil seda vabalt uurida ilma skripti külge klammerdumata.
• Kasutatavuse kontrollimiseks: Saate astuda kasutaja kingadesse, et näha, kas tarkvaras on segadust tekitavaid või frustreerivaid osi. See aitab üldist kogemust parandada.
• Beetatestimise ajal: Paljud beetatestijad kasutavad tarkvara reaalsetes olukordades proovides loomulikult ad hoc testimist, paljastades probleeme, mis ilmnevad ainult reaalses kasutuses.

Ad hoc testimise tüübid

Ad hoc testimine ei pruugi järgida ametlikku plaani, kuid aja jooksul on tekkinud mitu kasulikku stiili. Need ei ole ranged kategooriad, kuid peegeldavad seda, kuidas testijad kohanevad reaalsete vajadustega. Minu kogemuse kohaselt võib nende meetodite kasutamine õiges olukorras paljastada peidetud vigu kiiremini ja tõhusamalt.

• Buddy Testimine: See meetod ühendab arendaja ja testija, et töötada kõrvuti. Arendaja selgitab, kuidas funktsioon loodi. Samal ajal uurib testija seda kasutaja vaatenurgast. See kodeerimisteadmiste ja testimisoskuste kombinatsioon aitab probleeme varakult märgata, sageli kohe pärast kodeerimise lõppu.
• Paari testimine: Kaks testijat töötavad koos samal seadmel. Üks uurib rakendust, samal ajal kui teine ​​pakub erinevaid sisendeid ja jälgib käitumist. Nad teevad kordamööda tööd ja jagavad märkmeid. See reaalajas koostöö suurendab loovust ja leiab sageli rohkem defekte kui üksi testides.
• Ahvi testimine: See on kõige ettearvamatum lähenemisviis. Testija või tööriist klõpsab, trükib või navigeerib rakenduses juhuslikult. Eesmärk on süsteemi seni survestada, kuni see kokku jookseb. Kuigi see võib tunduda kaootiline, on see suurepärane viis krahhide või nõrkade kohtade leidmiseks. Pidage lihtsalt meeles, et sel viisil leitud vigade taasesitamine võib olla keeruline.

Igal neist lähenemisviisidest on oma tugevus. Õige valimine sõltub teie projekti vajadustest, meeskonna dünaamikast ja sellest, kui kiiresti tagasisidet vaja on. Minu kogemuse põhjal võib nende meetodite kombineerimine tuua ad hoc testimisest parima tulemuse – paljastada probleeme, mis skriptitud testimisel võivad märkamata jääda.

Ad-hoc testimise eelised

Ad-Hoc testimine pakub ainulaadset väärtust, mis struktureeritud testimisel sageli kahe silma vahele jääb. See on paindlik, kiire ja tugineb testija sisetunnetusele, mitte fikseeritud protseduuridele. Minu kogemuse põhjal on seda tüüpi testimine võimas kaaslane formaalsetele meetoditele, eriti kiiresti muutuvates arenduskeskkondades.

• Paljastab peidetud vead: Ilma eelnevalt määratletud testide piiranguteta uurib see ootamatuid teid, kus vead sageli peidus on.
• Kiire ja lihtne seadistamine: Pole vaja detailseid testimisplaane ega dokumentatsiooni, mis säästab palju aega kiire tagasiside korral.
• Kulutõhus, kui aega napib: Ideaalne olukordades, kus ressursid on piiratud, kuid kriitilisi vigu tuleb siiski kiiresti leida.
• Reaalsete kasutajate arusaamad: Kuna testijad käituvad nagu lõppkasutajad, võib testimisprotsess esile tuua kasutatavusvigu, mida formaalsed testid võivad kahe silma vahele jätta.
• Kasutab testija intuitsiooni: Oskuslikud testijad saavad oma kogemustele toetuda, et avastada peeneid defekte, mida tööriistad või skriptid võivad kahe silma vahele jätta.
• Täiustab formaalset testimist: See ei asenda ametlikku testimist. Selle asemel lisab see testi ulatuse laiendamise kaudu veel ühe enesekindluse kihi.
• Kiirtagasiside: Eriti kasulik agiilsetes seadistustes, kus vead tuleb kiiresti leida ja parandada, et asjad edasi liiguksid.

Ad-hoc testimise puudused

Ad hoc testimisel on mitmeid piiranguid, mis võivad mõjutada nii testimise kvaliteeti kui ka toote tulemust. Lubage mul neid oma testimiskogemuse põhjal selgelt selgitada.

• Raskesti paljundatavad vead: Kuna puudub struktureeritud lähenemisviis või samm-sammult juhised, võib probleemi replikeerimine olla keeruline. See raskendab probleemi lahendamist arendajate jaoks.
• Tugineb testija kogemusele: Selle meetodi edu sõltub suuresti testija oskustest või tuttavusest tootega. Algajal võivad märkamata jääda olulised vead, mida kogenud testija märkaks.
• Täielikku testi ei kaeta: Ad hoc testimine ei toimu planeeritud rada pidi. See tähendab, et mõned olulised valdkonnad võivad jääda märkamatult testimata, kuni on juba liiga hilja.
• Puudub jälgimine ja mõõdikud: Ilma testijuhtumite või logideta on keeruline mõõta edusamme, tuvastada mustreid või mõista, mida on testitud. See vähendab meeskondade ja sidusrühmade jaoks nähtavust.
• Ei sobi kõrge riskiga rakenduste jaoks: Tervishoiu-, pangandus- või ohutuskriitiliste süsteemide projektid vajavad põhjalikku dokumenteerimist ja valideerimist. Ainult ad hoc testimine ei vasta neile rangetele standarditele.
• Kas keskendumata võib aega raisata: Kui testijal pole vähemalt mitteametlikke eesmärke, võib ta lõpuks kulutada liiga palju aega madala prioriteediga funktsioonide uurimisele. See aeglustab üldist testimistsüklit.

Parimad tavad tõhusaks ad hoc testimiseks

Ad hoc testimise eeliste maksimeerimiseks vaatamata selle mitteametlikule olemusele kaaluge järgmisi tavasid:

1) Head äriteadmised

Testijatel peaksid olema head äriteadmised ja selge arusaam nõuetest. Üksikasjalikud teadmised äriprotsessist lõpuni aitavad defekte hõlpsalt leida. Kogenud testijad leiavad rohkem defekte, kuna oskavad vigu paremini ära arvata.

2) Testivõtme moodulid

Peamised ärimoodulid tuleks tuvastada ja sihtotstarbeliselt testida. Ärikriitilisi mooduleid tuleks esmalt testida, et saada kindlustunne süsteemi kvaliteedis.

3) Salvesta defektid

Kõik vead tuleb üles märkida või märkmikusse kirjutada. Defektid tuleb määrata arendajatele parandamiseks. Iga kehtiva defekti kohta tuleb kirjutada vastavad testjuhtumid ja lisada need planeeritud testjuhtumitele.

Need Defekt järeldused tuleks teha õppetundidena ja need peaksid kajastuma meie järgmises süsteemis, kui kavandame testjuhtumeid.

4) Paaritumine

Nagu näha Buddy Või paaristestimine, koostöö võib tuua kaasa mitmekesiseid vaatenurki ja parandada defektide tuvastamist.

Näited ad-hoc testidest

Ad-hoc testimine seisneb rakenduse uurimises ilma kindla plaanita. Skriptide järgimise asemel toetume intuitsioonile ja varasematele kogemustele. Olen sageli leidnud, et see lähenemisviis on kasulik ebatavaliste või ootamatute vigade avastamisel, mida skriptitud testid võivad kahe silma vahele jätta.

• Sisselogimise funktsiooni stressitest: Testija logib korduvalt sisse ja välja erinevate, mõnede valede sisselogimisandmetega, et näha, kas süsteem jookseb kokku või reageerib kummaliselt.
• Ebatavaline kasutaja sisend: Sümbolite, äärmiselt pikkade stringide või ootamatute failivormingute sisestamine süsteemi reageeringu kontrollimiseks. See aitab kontrollida sisendi valideerimise toimimist.
• Juhuslikud klõpsud ja navigeerimine: Testija klõpsab rakenduses juhuslikult – hüpates lehtede vahel, käivitades nuppe vales järjekorras –, et märgata ootamatut käitumist.
• Failide üleslaadimise kaos: Toetamata failitüüpide või rikutud failide üleslaadimine üleslaadimisfunktsiooni töökindluse testimiseks.
• Katkestatud testimine: Protsessi katkestamine (näiteks vahelehe sulgemine salvestamise ajal või internetiühenduse katkestamine), et näha, kuidas süsteem taastub.

Võrdlev analüüs koos uurimusliku testimisega

Kuigi neid sageli segatakse, on ad hoc ja uurimuslikul testimisel erinevad tööparameetrid:

Iseloomulik	Ad hoc testimine	Uurimuslik testimine
dokumentatsioon	Ainult pärast täitmist	Pidev salvestamine
Planeerimine	mitte ükski	Kerge tšarterpõhine
Seansi struktuur	Täiesti struktureerimata	Ajapiiranguga iteratsioonid
Defektide paljunemine	33% reprodutseeritavus	78% reprodutseeritavus
Automatiseerimise integreerimine	Piiratud kohaldatavus	42% tööriistade kaasamine

Järeldus

Ad hoc testimine on endiselt võimas viis peidetud vigade leidmiseks, mida teised testimismeetodid võivad kahe silma vahele jätta. See tugineb testija kogemustele, instinktidele ja loovusele. Oma aastakümnete pikkuse testimiskogemuse jooksul olen näinud, kuidas see lähenemisviis paljastab sageli reaalse maailma probleeme, mida struktureeritud testid kahe silma vahele jätavad.

Siiski on oluline ad hoc testimist kasutada ettevaatlikult. Ilma planeerimise või dokumenteerimiseta võib tulemuste kordamine või jagamine olla keeruline. Seetõttu soovitan alati kombineerida seda korralike märkmetega ja kasutada tööriistu, mis jälgivad testitud infot. See loob tasakaalu vabaduse ja kontrolli vahel.

Usun, et tehisintellekti edasise arenguga näeme masinõppe toetatud nutikamat ad hoc testimist. Need tööriistad aitavad testijatel suunata oma instinkte sinna, kus neid kõige rohkem vaja on. Kuigi ad hoc testimine sai alguse paindliku, inimkeskse praktikana, muutub see tänapäeva kvaliteeditagamise töövoogudes kiiresti mõõdetavamaks ja väärtuslikumaks.