Mis on agiilne testimine? Protsess ja elutsükkel

Mis on agiilne testimine?

Agiilne testimine on testimispraktika, mis järgib agiilse tarkvaraarenduse reegleid ja põhimõtteid. Erinevalt Waterfall-meetodist saab Agile Testing alata projekti alguses pideva arenduse ja testimise integreerimisega. Agiilse testimise metoodika ei ole järjestikune (selles mõttes, et seda teostatakse alles pärast kodeerimisfaasi), vaid pidev.

Agiilse testimise põhimõtted

Siin on agiilse testimise peamised põhimõtted:

  • Selles Agile testimismudelis on töötav tarkvara edusammude esmaseks mõõdupuuks.
  • Parima tulemuse saavad saavutada iseorganiseeruvad meeskonnad.
  • Väärtusliku tarkvara varajane ja pidev tarnimine on meie kõrgeim prioriteet.
  • Tarkvaraarendajad peavad kogu projekti jooksul igapäevaselt kogunema.
  • Agility suurendamine pideva tehnilise täiustamise ja hea disaini kaudu.
  • Agiilne testimine tagab, et lõpptoode vastab ettevõtte ootustele, pakkudes pidevat tagasisidet.
  • Agiilse testimise protsessis peame testimise läbi viima juurutamise ajal, mis vähendab arendusaega.
  • Agile'i testimisprotsess peaks töötama järjepidevas arendustempos
  • Arutage regulaarselt, kuidas tõhusamaks saada.
  • Parimad arhitektuurid, nõuded ja kujundused tekivad iseorganiseeruvatest meeskondadest.
  • Iga kord, kui meeskond kohtub, vaatab ta oma käitumist üle ja kohandab seda, et muutuda tõhusamaks.
  • Näost näkku vestlus arendusmeeskonnaga on kõige tõhusam ja tõhusaim meetod meeskonnasiseseks teabe edastamiseks.

Agiilne testimine sisaldab erinevaid põhimõtteid, mis aitavad meil Tarkvara tootlikkust tõsta.

Agiilse testimise elutsükkel

Agiilse testimise elutsükkel läbitakse viies erinevas faasis, nagu näeme järgmisel pildil:

Agiilse testimise elutsükkel

Siin on Agile protsessi testimise etapid.

1. etapp: mõju hindamine: Selles algfaasis kogume sisendeid sidusrühmadelt ja kasutajatelt. Seda faasi nimetatakse ka tagasisidefaasiks, kuna see aitab testijatel järgmise elutsükli eesmärke seada.

2. etapp: agiilne testimise planeerimine: See on agiilse testimise elutsükli teine ​​faas, kus kõik sidusrühmad tulevad kokku, et planeerida testimisprotsessi ajakava ja tulemusi.

3. etapp: vabastamisvalmidus: Selles etapis vaatame üle välja töötatud funktsioonid/ juurutatud, kas need on kasutamiseks valmis või mitte. Selles etapis otsustatakse ka, kumb peab minema tagasi eelmisesse arendusfaasi.

4. faas: igapäevased löögid: See etapp hõlmab iga püstijalu hommikust koosolekut, et jõuda järele testimise olekusse ja seada eesmärk kogu päevaks.

5. etapp: Agility testimine Revvaata: Agiilse elutsükli viimane faas on Agility Review Koosolek. See hõlmab iganädalasi kohtumisi sidusrühmadega, et korrapäraselt hinnata ja hinnata edusamme eesmärkide suhtes.

Agiilne testiplaan

Agiilne testiplaan hõlmab selles iteratsioonis tehtud testimise liike, nagu testiandmete nõuded, infrastruktuur, testkeskkonnadja testitulemused. Erinevalt juga mudelist koostatakse agiilses mudelis testiplaan, mida värskendatakse iga versiooni jaoks. Tüüpilised agiilse testimise plaanid hõlmavad

  • Katse ulatus
  • Uued funktsioonid, mida testitakse
  • Testimise tase või tüübid, mis põhinevad funktsioonide keerukusel
  • Koormus- ja jõudluse testimine
  • Infrastruktuuri kaalumine
  • Leevendus- või riskiplaan
  • Varude hankimine
  • Saadetised ja verstapostid

Agiilsed testimisstrateegiad

Agiilse testimise elutsükkel hõlmab nelja etappi

Agiilsed testimisstrateegiad

iteratsiooni 0

Esimese etapi või iteratsiooni 0 ajal sooritate algseadistusülesandeid. See hõlmab inimeste tuvastamist testimiseks, testimistööriistade installimist, ressursside ajastamist (kasutatavuse testimise labor) jne. Iteratsioonis 0 on seatud järgmised sammud.

  • Projekti ärilise aluse loomine
  • Määrake piirtingimused ja projekti ulatus
  • Kirjeldage peamisi nõudeid ja kasutusjuhtumeid, mis aitavad kaasa disaini kompromissidele
  • Joonistage üks või mitu kandidaatarhitektuuri
  • Riski tuvastamine
  • Kulude kalkulatsioon ja eelprojekti koostamine

Ehituse iteratsioonid

Agiilse testimise metoodika teine ​​faas on ehitusiteratsioonid, suurem osa testimisest toimub selles etapis. Seda faasi vaadeldakse iteratsioonide kogumina, et luua lahenduse juurdekasv. Selleks tehke iga iteratsiooni jooksul meeskond rakendab XP, Scrum, Agile modelleerimise ja agiilsete andmete ja muu sellise praktika hübriid.

Ehitamise iteratsioonis järgib agiilne meeskond prioriteetsete nõuete praktikat: iga iteratsiooniga võtavad nad kõige olulisemad nõuded, mis jäävad tööobjekti virnast, ja rakendavad need.

Ehitusiteratsioon jaguneb kaheks: kinnitav testimine ja uuriv testimine. Kinnitustestide kontsentraadid kontrollimisel, et süsteem täidab sidusrühmade kavatsusi, nagu on meeskonnale seni kirjeldatud, ja et meeskond seda teostab. Kuigi uuriv testimine tuvastab probleemi, mille kinnitav meeskond on vahele jätnud või ignoreerinud. Uuriva testimise korral määrab testija võimalikud probleemid defektilugude kujul. Uuriv testimine tegeleb levinud probleemidega, nagu integratsioonitestimine, koormus-/pingetestimine ja turbetestimine.

Jällegi, kinnitaval testimisel on kaks aspekti arendaja testimine ja agiilne vastuvõtutest. Mõlemad on automatiseeritud, et võimaldada pidevat regressioonitesti kogu elutsükli jooksul. Kinnitav testimine on spetsifikatsioonile vastava testimise vilgas vaste.

Agiilne vastuvõtutest on kombinatsioon traditsioonilisest funktsionaalsest testimisest ja traditsioonilisest vastuvõtutestimisest arendusmeeskonnana ning sidusrühmad teevad seda koos. Kuigi arendaja testimine on segu traditsioonilisest üksuse testimisest ja traditsioonilisest teenuse integreerimise testimisest. Arendaja testimine kontrollib nii rakenduse koodi kui ka andmebaasi skeemi.

Laske mängu lõpp või üleminekufaas välja

Mängu „Vabasta, lõpeta mäng” eesmärk on teie süsteem edukalt tootmisse juurutada. Tegevused hõlmavad selles etapis lõppkasutajate, tugi- ja operatiivinimeste koolitamist. Samuti hõlmab see toote väljalaske turustamist, varundamist ja taastamist, süsteemi ja kasutaja dokumentatsiooni viimistlemist.

Viimane agiilse metoodika testimise etapp hõlmab täielikku süsteemi testimist ja vastuvõtutestimist. Viimase testimisetapi ilma takistusteta lõpuleviimiseks peaksite toodet rangemalt testima, kui see on ehitusiteratsioonides. Lõppmängu ajal töötavad testijad selle defektilugude kallal.

Produktsioon

Pärast vabastamisetappi liigub toode tootmisfaasi.

Agiilsed testimiskvadrandid

Agiilsed testimiskvadrandid

Agiilse testimise kvadrandid eraldavad kogu protsessi neljaks kvadrandiks ja aitavad mõista, kuidas vilgas testimine toimub.

Agiilne kvadrant I

Selles kvadrandis on põhirõhk sisemisel koodikvaliteedil ja see koosneb tehnoloogiapõhistest testjuhtumitest, mida rakendatakse meeskonna toetamiseks.

  • Ühikutestid
  • Komponentide testid

Agiilne kvadrant II

See sisaldab testjuhtumeid, mis on äripõhised ja mida rakendatakse meeskonna toetamiseks. See kvadrand keskendub nõuetele. Selles etapis läbiviidava testi tüüp on

  • Võimalike stsenaariumide ja töövoogude näidete testimine
  • Kasutajakogemuse, näiteks prototüüpide testimine
  • Paaritestimine

Agiilne kvadrant III

See kvadrant annab tagasisidet esimesele ja teisele kvadrantile. Testjuhtumeid saab võtta aluseks automatiseerimise testimisel. Selles kvadrandis viiakse läbi palju iteratsiooniülevaate voorusid, mis suurendavad usaldust toote vastu. Selles kvadrandis tehtud testid on sellised

  • Kasutatavuse testimine
  • Uurimuslik testimine
  • Paaritestimine klientidega
  • Koostöö testimine
  • Kasutajate aktsepteerimise testimine

Agiilne kvadrant IV

See kvadrand keskendub mittefunktsionaalsetele nõuetele, nagu jõudlus, turvalisus, stabiilsus jne. Selle kvadrandi abil luuakse rakendus, et pakkuda mittefunktsionaalseid omadusi ja oodatavat väärtust.

  • Mittefunktsionaalsed testid, nagu stressi- ja jõudlustestid
  • Turvatestimine seoses autentimine ja häkkimine
  • Infrastruktuuri testimine
  • Andmete migratsiooni testimine
  • Skaleeritavuse testimine
  • Koormustestimine

QA väljakutsed agiilse tarkvaraarendusega

  • Veavõimalused on paindlikumad, kuna dokumentatsioonile omistatakse vähem prioriteeti, mis lõpuks avaldab kvaliteedikontrolli meeskonnale rohkem survet
  • Uued funktsioonid võetakse kasutusele kiiresti, mis vähendab testimeeskondade jaoks saadaolevat aega, et teha kindlaks, kas uusimad funktsioonid vastavad nõuetele ja kas see vastab tõesti ärilistele vajadustele
  • Testijatelt nõutakse sageli poolarendaja rolli
  • Testi täitmise tsüklid on tugevalt tihendatud
  • Väga vähem aega katseplaani koostamiseks
  • Regressioonitestide jaoks on neil minimaalne ajastus
  • Muutus nende rollis kvaliteedi väravavalvajast kvaliteedipartneriks
  • Nõuete muudatused ja uuendused on omane agiilsele meetodile, muutudes QA suurimaks väljakutseks

Agiilse protsessi automatiseerimise oht

  • Automaatne kasutajaliides tagab kõrge usaldusväärsuse, kuid nende täitmine on aeglane, hooldatav ja kulukas. Automatiseerimine ei pruugi oluliselt parandada testimise tootlikkust, kui testijad ei tea, kuidas testida
  • Ebausaldusväärsed testid on automaattestimise peamine probleem. Ebaõnnestunud testide parandamine ja rabedate testidega seotud probleemide lahendamine peaks olema esmatähtis, et vältida valepositiivseid tulemusi
  • Kui automatiseeritud test käivitatakse käsitsi, mitte CI (pidev integreerimine) kaudu, on oht, et need ei tööta regulaarselt ja võivad seetõttu põhjustada testide ebaõnnestumist.
  • Automaattestid ei asenda uurimuslikku käsitsi testimist. Toote eeldatava kvaliteedi saavutamiseks on vaja testimistüüpe ja -tasemeid
  • Paljud kaubanduslikult saadavad automatiseerimistööriistad pakuvad lihtsaid funktsioone, nagu käsitsi testjuhtumite jäädvustamise ja taasesitamise automatiseerimine. Selline tööriist julgustab kasutajaliidese kaudu testimist ning viib oma olemuselt rabedate ja raskesti hooldatavate testideni. Samuti tekitab tarbetut keerukust testjuhtumite salvestamine väljaspool versioonikontrollisüsteemi
  • Aja säästmiseks on automatiseerimise testiplaan sageli halvasti planeeritud või planeerimata, mille tulemusel test ebaõnnestub
  • Testimise seadistamise ja lammutamise protseduurid jäävad tavaliselt testimise automatiseerimise ajal vahele, samal ajal kui käsitsi testimise korral kõlab testi seadistamise ja lammutamise protseduur sujuvalt
  • Tootlikkuse mõõdikud, nagu päevas loodud või teostatud testjuhtumite arv, võivad olla kohutavalt eksitavad ja viia suure investeeringuni kasutute testide käitamisse.
  • Agiilse automatiseerimismeeskonna liikmed peavad olema tõhusad konsultandid: vastutulelikud, koostööaldised ja leidlikud, vastasel juhul läheb see süsteem kiiresti üles
  • Automatiseerimine võib pakkuda ja tarnida testimislahendusi, mis nõuavad pakutava väärtusega võrreldes liiga palju pidevat hooldust
  • Automaattestimisel võib puududa asjatundlikkus tõhusate lahenduste väljamõtlemiseks ja pakkumiseks
  • Automaattestimine võib olla nii edukas, et neil saavad olulised probleemid otsa, mida lahendada, ja seega pöördutakse ebaoluliste probleemide poole.

Järeldus

Tarkvara testimise agiilne metoodika hõlmab testimist võimalikult varakult tarkvaraarenduse elutsükkel. See nõuab klientide ulatuslikku kaasamist ja testimiskoodi niipea, kui see saadaval on. Kood peaks olema piisavalt stabiilne, et seda süsteemi testida. Vigade parandamise ja testimise tagamiseks saab teha ulatuslikke regressiooniteste. Peamiselt teeb agiilse mudelitestimise eduks meeskondade vaheline suhtlus!!!