Mis on agiilne testimine?
AGILE TESTING on testimispraktika, mis järgib vilgas tarkvaraarenduse reegleid ja põhimõtteid. Erinevalt juga meetodist võib agiilset testimist alustada projekti alguses, pidev integreerimine arenduse ja testimise vahel. Agile testimise metoodika ei ole järjestikune (selles mõttes, et seda teostatakse alles pärast kodeerimisfaasi), vaid pidev.
Selles artiklis me arutame
- Vilgas katseplaan.
- Agile testimise strateegiad.
- Agile testimise kvadrant.
- Kvaliteedi tagamise väljakutsed on kiire tarkvaraarendusega.
- Automaatika oht agiilses protsessis.
Vilgas katseplaan
Vilgas testimiskava sisaldab selles iteratsioonis tehtud testide tüüpe, nagu näiteks katseandmete nõuded, infrastruktuur, testikeskkonnad ja testitulemused. Erinevalt juga mudelist kirjutatakse agiilses mudelis iga väljalaske jaoks katseplaan ja seda ajakohastatakse. Tüüpilised katseplaanid agiilselt hõlmavad järgmist
- Katse ulatus
- Uued funktsioonid, mida katsetatakse
- Testimise tase või tüübid funktsioonide keerukuse põhjal
- Koormuse ja jõudluse testimine
- Infrastruktuuri kaalumine
- Maandamise või riskide plaan
- Varude hankimine
- Tulemused ja verstapostid
Agile testimise strateegiad
Agile testimise elutsükkel hõlmab nelja etappi
a) kordus 0
Esimese etapi või iteratsiooni 0 ajal sooritate esmaseid seadistamisülesandeid. See hõlmab inimeste tuvastamist testimiseks, testimistööriistade installimist, ressursside ajastamist (kasutatavuse testimise labor) jne. Iteratsioon 0 saavutamiseks on seatud järgmised sammud
a) Projekti ärijuhtumi kindlakstegemine
b) Pange paika piiritingimused ja projekti ulatus
c) Too välja peamised nõuded ja kasutamisjuhud, mis viivad disaini kompromissideni
d) Esitage üks või mitu kandidaatarhitektuuri
e) riski tuvastamine
f) Kulude prognoosimine ja eelprojekti koostamine
b) Ehitamise kordused
Agiilse testimise metoodika teine etapp on ehitus iteratsioonid, suurem osa katsetest toimub just selles etapis. Seda faasi vaadeldakse kui korduste kogumit, et luua lahuse juurdekasv. Selleks rakendab meeskond iga iteratsiooni raames hübriidi praktikatest XP, Scrum, Agile modelleerimine ja agiilsed andmed jne.
Ehitamise iteratsioonis järgib vilgas meeskond prioriteetsete nõuete praktikat: iga iteratsiooniga võtavad nad kõige olulisemad nõuded, mis jäävad tööüksuste virnast alles, ja viivad need ellu.
Ehituse iteratsioon liigitatakse kaheks, kinnitavateks ja uurivateks katseteks. Kinnitav testimine keskendub kontrollimisele, kas süsteem täidab sidusrühmade kavatsusi, nagu meeskonnale on seni kirjeldatud, ja meeskond teostab seda. Kuigi uuriv testimine tuvastab probleemi, mille kinnitusmeeskond on vahele jätnud või ignoreerinud. Uuriva testimise käigus määrab testija võimalikud probleemid defektilugude näol. Uuriv testimine tegeleb selliste levinud probleemidega nagu integreerimise testimine, koormus- / stressitestimine ja turvatestimine.
Jällegi on kinnituskatsete jaoks kaks aspekti: arendaja testimine ja vilgas aktsepteerimise testimine . Mõlemad on automatiseeritud, et võimaldada pidevat regressioonitesti kogu elutsükli vältel. Kinnitav testimine on testimise vilgas samaväärsus spetsifikatsiooniga.
Agile aktsepteerimise testimine on kombinatsioon traditsioonilisest funktsionaalsest testimisest ja traditsioonilisest vastuvõtutestist kui arendusmeeskond ja sidusrühmad teevad seda koos. Ehkki arendaja testimine on segu traditsioonilisest ühikutestimisest ja traditsioonilisest teenuse integreerimise testimisest. Arendaja testimine kontrollib nii rakenduse koodi kui ka andmebaasi skeemi.
(c) vabastage mängu lõpp või üleminekuetapp
Väljaandmise, lõppmängu eesmärk on oma süsteem edukalt tootmisse juurutada. Selles etapis hõlmab tegevus lõppkasutajate, tugiisikute ja operatiivtöötajate koolitust. See hõlmab ka toote väljaandmise turundamist, varundamist ja taastamist, süsteemi ja kasutaja dokumentatsiooni viimistlemist.
Lõplik agiilse metoodika testimise etapp hõlmab süsteemi täielikku testimist ja aktsepteerimist. Lõpliku katsetamisetapi takistusteta lõpetamiseks peaksite toodet ehituse korduste ajal rangemalt katsetama. Lõppmängu ajal töötavad testijad selle defektilugude kallal.
d) Tootmine
Pärast vabastamisetappi liigub toode tootmisetappi.
Nõtked testivad kvadrandid
Vilgas testimise kvadrandid eraldavad kogu protsessi neljaks kvadrandiks ja aitavad mõista, kuidas agiilset katsetamist tehakse.
a) Agile I kvadrant - selles kvadrandis on põhirõhk sisekoodikvaliteedil ja see koosneb tehnikapõhistest testjuhtumitest, mida rakendatakse meeskonna toetamiseks. See hõlmab
1. Üksuse testid
2. Komponentkatsed
b) Agile II kvadrant - see sisaldab ettevõtte juhtimiseks mõeldud juhtumeid, mis on rakendatud meeskonna toetamiseks. See kvadrant keskendub nõuetele. Selles faasis tehtav test on
1. Võimalike stsenaariumide ja töövoogude näidete testimine
2. Kasutajakogemuse, näiteks prototüüpide testimine
3. Paaritestimine
c) Agile III kvadrant - see kvadrant annab tagasisidet esimesele ja teisele kvadrandile. Testjuhtumeid saab kasutada automatiseerimise testimise aluseks. Selles kvadrandis viiakse läbi palju iteratsiooni ülevaatusi, mis suurendavad toote suhtes usaldust. Selles kvadrandis tehtud testimine on
1. Kasutatavuse testimine
2. Uurimuslik testimine
3. Paaritestimine klientidega
4. Koostöö testimine
5. Kasutaja aktsepteerimise testimine
d) Agile IV kvadrant - see ruut keskendub mittefunktsionaalsetele nõuetele nagu jõudlus, turvalisus, stabiilsus jne. Selle kvadrandi abil tehakse rakendus mittefunktsionaalsete omaduste ja oodatava väärtuse edastamiseks.
1. Mittefunktsionaalsed testid, näiteks stressi ja jõudluse testimine
2. Autentimise ja häkkimise turvalisuse testimine
3. Infrastruktuuri testimine
4. Andmete migratsiooni testimine
5. Mastaapsuse testimine
6. Koormuse testimine
Kvaliteedi tagamise väljakutsed kiire tarkvaraarendusega
a) Vigade tõenäosus on rohkem nõtke, kuna dokumentatsioonile antakse vähem prioriteeti, see survestab QA meeskonda lõpuks rohkem
b) Uued funktsioonid võetakse kiiresti kasutusele, mis vähendab testimeeskondade jaoks aega, et tuvastada, kas uusimad funktsioonid vastavad nõudele, ja kas see vastab tõepoolest ärimudelitele
c) Testijatelt nõutakse sageli rollirolli mängimist
d) Katse täitmise tsüklid on väga tihendatud
e) Väga vähem aega testiplaani koostamiseks
f) Regressioonitesti jaoks on nende ajastus minimaalne
g) Muutus nende rollis kvaliteedi väravavahiks olemisest kvaliteedis partneriks olemiseks
h) Nõuete muutmine ja ajakohastamine on omane agiilsele meetodile, mis on QA jaoks suurim väljakutse
Automaatika oht agiilses protsessis
- Automatiseeritud kasutajaliides pakub kõrget kindlustunnet, kuid nende käivitamine on aeglane, hooldamine habras ja ehitamine kulukas. Automatiseerimine ei pruugi testide tootlikkust märkimisväärselt parandada, kui testijad ei tea, kuidas testida
- Ebausaldusväärsed testid on automatiseeritud testimisel suur probleem. Ebaõnnestunud testide parandamine ja rabedate testidega seotud probleemide lahendamine peaksid olema esmatähtsad, et vältida valepositiivseid tulemusi
- Kui automatiseeritud test käivitatakse käsitsi, mitte CI (pideva integreerimise) kaudu, on oht, et neid regulaarselt ei käitata ja see võib põhjustada testide ebaõnnestumise
- Automatiseeritud testid ei asenda uurivat käsitsi testimist. Toote eeldatava kvaliteedi saamiseks on vaja katsetüüpide ja tasemete segu
- Paljud kaubanduslikult saadaval olevad automaatikatööriistad pakuvad lihtsaid funktsioone, näiteks käsitsi testjuhtumite hõivamise ja taasesituse automatiseerimine. Selline tööriist julgustab kasutajaliidese kaudu testima ja viib olemuselt rabedate ja raskesti hooldatavate testideni. Samuti tekitab tarbetut keerukust testijuhtumite hoidmine väljaspool versioonihaldussüsteemi
- Aja kokkuhoiu huvides on automaatika testimiskava mitu korda halvasti planeeritud või planeerimata, mistõttu test ebaõnnestub
- Katse seadistamise ja lammutamise protseduurid jäävad testi automatiseerimisel tavaliselt vahele, samas kui käsitsi testimise ajal kõlab testi seadistamise ja lammutamise protseduur sujuvalt
- Produktiivsusmõõdikud, näiteks mitu päevas loodud või täidetud testimisjuhtu, võivad olla kohutavalt eksitavad ja viia suurte investeeringuteni kasutute testide läbiviimisse
- Vilgas automatiseerimisrühma liikmed peavad olema tõhusad konsultandid: vastutulelik, koostöövalmis ja leidlik, vastasel korral tõrjub see süsteem kiiresti
- Automatiseerimine võib pakkuda ja pakkuda testimislahendusi, mis nõuavad pakutava väärtusega võrreldes liiga palju pidevat hooldust
- Automatiseeritud testimisel võib puududa asjatundlikkus tõhusate lahenduste väljatöötamiseks ja pakkumiseks
- Automatiseeritud testimine võib olla nii edukas, et nende lahendamiseks on olulised probleemid otsas ja pöörduvad seega ebaoluliste probleemide poole.
Järeldus
Tark testimise vilgas metoodika hõlmab testimist võimalikult vara tarkvaraarenduse elutsüklis. See nõuab klientide kõrget sekkumist ja testimiskoodi niipea, kui see kättesaadavaks muutub. Kood peaks olema piisavalt stabiilne, et see süsteemi testimiseks viia. Vigade parandamise ja testimise tagamiseks saab teha ulatusliku regressioonitesti. Peamiselt teeb tiimidevaheline suhtlus mudeli katsetamise edukaks !!!