Ad hoc testēšana
Ad hoc testēšana ir neformāls vai nestrukturēts programmatūras testēšanas veids, kura mērķis ir pārtraukt testēšanas procesu, lai iespējami agrīnā stadijā atrastu iespējamos defektus vai kļūdas. Ad hoc testēšana tiek veikta nejauši, un tā parasti ir neplānota darbība, kas, lai izveidotu testa gadījumus, neievēro nekādu dokumentāciju un testēšanas metodes.
Ad hoc testēšana neievēro strukturētu testēšanas veidu, un to nejauši veic jebkurā lietojumprogrammas daļā. Šīs pārbaudes galvenais mērķis ir atrast defektus, nejauši pārbaudot. Adhoc testēšanu var panākt ar programmatūras testēšanas tehniku, ko sauc par kļūdu uzminēšanu. Kļūdu uzminēšanu var izdarīt cilvēki, kuriem ir pietiekami daudz pieredzes sistēmā, lai "uzminētu" visticamāko kļūdu avotu.
Šī pārbaude neprasa dokumentācijas / plānošanas / procesa ievērošanu. Tā kā šīs pārbaudes mērķis ir atrast defektus, izmantojot nejaušu pieeju, bez jebkādas dokumentācijas, defekti netiks pieskaitīti testa gadījumiem. Tas nozīmē, ka dažreiz ir ļoti grūti atkārtot defektus, jo tam nav noteiktas pārbaudes darbības vai prasības.
Sekojot videoklipam, varat uzzināt, kā veikt adhoc testēšanu
Noklikšķiniet šeit, ja videoklips nav pieejams
Kad veicat adhoc testēšanu?
Ad hoc testēšanu var veikt, ja detalizētas pārbaudes veikšanai ir ierobežots laiks. Parasti adhoc testēšana tiek veikta pēc oficiālās pārbaudes izpildes. Un, ja laiks atļauj, sistēmā var veikt ad hoc testēšanu. Ad hoc testēšana būs efektīva tikai tad, ja testētājs ir informēts par pārbaudāmo sistēmu.
Adhoc testēšanas veidi
Ir dažādi adhoc testēšanas veidi, un tie ir uzskaitīti šādi:
| Draugu testēšana | Divi draugi savstarpēji strādā pie viena moduļa defektu identificēšanas. Pārsvarā viens draugs būs no izstrādes komandas un cits cilvēks no testēšanas komandas. Draugu testēšana palīdz testētājiem izstrādāt labākus testa gadījumus, un izstrādes komanda var arī agri veikt izmaiņas dizainā. Šī pārbaude parasti notiek pēc vienības testēšanas pabeigšanas. |
| Pāru pārbaude | Diviem testētājiem tiek piešķirti moduļi, viņi dalās idejās un strādā ar tām pašām mašīnām, lai atrastu defektus. Viena persona var veikt testus, bet cita persona var veikt piezīmes par konstatējumiem. Personu lomas testēšanas laikā var būt pārbaudītājs un rakstītājs. Draugu un pāru testēšanas salīdzinājums: Draugu testēšana ir vienības un sistēmas testēšanas kombinācija kopā ar izstrādātājiem un testētājiem, bet pāru testēšana tiek veikta tikai ar testētājiem ar dažādiem zināšanu līmeņiem. (Pieredzējuši un nepieredzējuši dalīties ar savām idejām un uzskatiem) |
| Pērtiķu pārbaude | Nejauši pārbaudiet produktu vai lietojumprogrammu bez testa gadījumiem ar mērķi salauzt sistēmu. |
Adhoc testēšanas paraugprakse
Labākās prakses ievērošana var nodrošināt efektīvu adhoc testēšanu.
Labas biznesa zināšanas
Testētājiem jābūt labām zināšanām par uzņēmējdarbību un skaidrai prasību izpratnei. Detalizētas zināšanas par biznesa procesu līdz galam palīdzēs viegli atrast defektus. Pieredzējuši testētāji atrod vairāk defektu, jo viņi labāk spēj uzminēt kļūdas.
Pārbaudes atslēgu moduļi
Galvenie uzņēmējdarbības moduļi ir jāidentificē un jāvirza ad hoc testēšanai. Vispirms jāpārbauda biznesa kritiskie moduļi, lai iegūtu pārliecību par sistēmas kvalitāti.
Ierakstīt defektus
Visi defekti jāreģistrē vai jāraksta bloknotā. Defektu novēršanai izstrādātājiem jāpiešķir defekti. Par katru derīgu defektu ir jāuzraksta attiecīgie testa gadījumi un tie jāpievieno plānotajiem testa gadījumiem.
Šie defektu atklājumi ir jāizdara pēc iegūtās mācības, un tie jāatspoguļo mūsu nākamajā sistēmā, kamēr mēs plānojam testa gadījumus.
Secinājums:
Ad-hoc testēšanas priekšrocība ir pārbaudīt testēšanas pilnīgumu un atrast vairāk defektu nekā plānotā testēšana. Defektu uztveršanas pārbaudes gadījumi tiek pievienoti kā papildu pārbaudes gadījumi plānotajiem testa gadījumiem.
Programmatūras inženierijas jomā ad-hoc testēšana ietaupa daudz laika, jo tai nav nepieciešama sarežģīta testu plānošana, dokumentēšana un testēšanas gadījumu noformēšana.