Vai esat iepazinies ar Agile Testing Life Cycle (ATLC)? Tas ir process, ko izmanto programmatūras izstrādes komandas, lai nodrošinātu, ka viņu lietojumprogrammas tiek pārbaudītas pareizi un efektīvi.
Šajā rakstā tiks parādīts viss, kas jums jāzina par ATLC, tostarp tās priekšrocības, procesā iesaistītās darbības, praktiskas pārbaudes stratēģijas plānošana, testu veikšana, pamatojoties uz prasību apkopošanu un kļūdu izsekošanu, lietotāju pieņemšanas testi (UAT) un nepārtraukti. testu integrācija un automatizācija.
Pēc šīs rokasgrāmatas izlasīšanas jūs labāk sapratīsit, kā izmantot elastīgo testēšanu kā daļu no programmatūras izstrādes dzīves cikla!
Ja esat veikls izstrādātājs, testētājs vai produktu menedžeris, kurš meklē labāku veidu, kā piegādāt savus produktus, šajā rakstā ir izskaidroti ar tiem saistītie posmi un jāveic nepieciešamās darbības.
Pārskats par Agile Testing dzīves ciklu
Nav noslēpums, ka testēšanai ir ārkārtīgi liela nozīme veiklās izstrādes pasaulē. Taču, neskatoties uz to, veiklās piegādes ietvaros tā bieži tiek novērtēta par zemu. Iemesls, protams, ir nauda attiecībā pret laiku līdz produkcijas piegādei.
Taču bez detalizētas pārbaudes nevienam jūsu komandas izstrādātajam produktam nebūtu nekādas kvalitātes vai uzticamības garantijas. Tāpēc ir ļoti svarīgi izprast elastīgo testēšanas dzīves ciklu — no darba vienumu noteikšanas līdz izpratnei, kāda veida pārbaude jāizmanto katrā fāzē.
Izveicīgais testēšanas cikls prasa, lai izstrādātāji un testētāji būtu iesaistīti katrā sprintā. Ja tas tiek darīts labi, tiek nodrošināta testēšanas automatizācija katrā posmā, kas palīdz ātrāk un biežāk atklāt kļūdas, vēlāk samazinot problēmu novēršanas laiku.
Agile testēšana palīdz arī agrīni apstiprināt prasības un kā blakusefekts uzlabo klientu apmierinātību, piegādājot kvalitatīvu produktu.
Kas ir Agile testēšana un tās priekšrocības
Agile Testing ir novatoriska programmatūras testēšanas metodika, kas izmanto automatizāciju, lai izveidotu iteratīvu testēšanas procesu. Šī uz automatizāciju orientētā pieeja palīdz komandām ātri analizēt visas koda neatbilstības vai problēmas un pēc tam pārbaudīt modifikācijas, pamatojoties uz šīm atsauksmēm.
Tāpēc šī procesa galvenās priekšrocības šķiet acīmredzamas:
- nodrošināt, ka testēšanai ir vajadzīgā ietekme,
- tas nodrošina efektīvāku izstrādes laiku,
- izstrādātajai sistēmai kopumā ir ātrāki kļūdu novēršanas rādītāji,
- un tiek uzlabota klientu apmierinātība.
Kvalitāte un ātrums šeit ir izšķiroši faktori, jo sprints tiek definēts kā neliels laika posms (parasti 2 līdz 4 nedēļas). Jo vairāk komanda var paļauties uz sprinta testēšanā iekļauto kvalitāti, jo augstāku pārliecību un ātrāku attīstības progresu komanda var radīt.
Jebkuras veiklās komandas galvenajam mērķim jābūt koncentrēties uz automatizāciju. Tas ļauj komandām samazināt dārgas neveiksmes risku un ļauj vairāk laika veltīt jauna satura izveidei, nevis jau esošā satura labošanai.
Vēl viens blakus ieguvums ir labāks projekta izmaksu un laika skalas novērtējums. Tā kā produkts ir daudz nobriedušāks un paredzamāks, ir mazāk situāciju, kad komandai ir jārisina negaidītas problēmas, kas radušās sprinta laikā, iepriekš neaprēķinot šādus sarežģījumus.
Agile testēšanas dzīves cikla soļi
Agile testēšanas dzīves cikls sastāv no četriem atšķirīgiem posmiem.
Vienību testi
Šīs ir pārbaudes, ko izstrādātāji veic, kad kods ir gatavs no izstrādes viedokļa. Tas tiek izpildīts izolēti izstrādes vidē, neiesaistot citas sistēmas daļas.
Vienību testi tiek veikti, lai pārbaudītu kodu, un tos var veikt manuāli un automātiski.
Ja tas tiek izpildīts manuāli, izstrādātājs veic pārbaudes gadījumus pret kodu. Tas ir ātri saprotams, taču attīstībai veltītā sprinta laikā ir nepieciešams vairāk laika, it īpaši no ilgtermiņa perspektīvas.
Alternatīva tam ir izveidot automatizētu vienības pārbaudes kodu, kas būtībā pārbaudīs funkcijas kodu, vienkārši to izpildot. Tas nozīmē, ka izstrādātājam ir jāpavada laiks ne tikai jaunās funkcijas izstrādei, bet arī vienības testa koda izstrādei, kas pārbaudīs šo funkciju.
Un, lai gan no īstermiņa perspektīvas tas varētu šķist lielāks darbs, tas ietaupa laiku visam projektam, jo šādus vienību testus ir viegli izmantot atkārtoti arī vēlākos sprinta testēšanas posmos. Tos pat var iekļaut regulāros regresijas testu gadījumos, kas pēc tam ietaupa vēl vairāk laika.
Visbeidzot, jo lielāks koda pārklājums ar automatizētām vienību pārbaudēm, jo labākus koda uzticamības rādītājus var parādīt klientam.
Funkcionālie testi
Funkcionālie testi ir paredzēti, lai noteiktu, cik labi darbojas lietojumprogrammas funkcija. Šāda veida testēšana tiek izmantota, lai nodrošinātu pareizu koda funkcionalitāti, nevis tehniskos aspektus (kas galvenokārt bija vienības testēšanas daļa), kā arī novērtētu, vai tas atbilst lietotāju vajadzībām un vēlmēm.
Citiem vārdiem sakot, funkcionālie testi tiek izmantoti, lai pārbaudītu, vai izstrādātais atbilst biznesa lietotāju izvirzītajām prasībām.
Laba prakse ir apkopot svarīgus testēšanas gadījumus iepriekš un no attiecīgajām ieinteresētajām personām (vai nu no produkta īpašnieka, vai pat no galalietotājiem) un izveidot sarakstu ar visiem šādiem pārbaudes gadījumiem, kas nepieciešami saturam sprinta ietvaros.
Funkcionālo testu automatizācija ir saistīta ar vairāk pūļu testa izstrādes pusē, jo tie ir sarežģīti pārbaudāmi procesi, tostarp dažādas sistēmas daļas kopā. Labākā stratēģija šajā gadījumā ir izveidot īpašu komandu tikai funkcionālo testu izstrādei saskaņā ar to, kā galvenā izstrādes komanda izstrādā jaunas funkcijas.
Protams, projektam tas nozīmē palielinātas izmaksas atsevišķas komandas uzturēšanai, taču tam ir arī liels potenciāls ietaupīt projekta naudu ilgtermiņā. Tikai projektu vadītājiem ir jāskaidro un konkrēti jāaprēķina ieguvumi un ietaupījumi, lai biznesa lietotāju priekšā pamatotu argumentu, kas novedīs pie šāda projekta izmaksu apstiprināšanas pieauguma.
No otras puses, ja to veic manuāli, šo darbību var veikt ļoti maza komanda (dažos gadījumos pat viena persona). Tomēr būs nepieciešama pastāvīga manuāla un atkārtota darbība katrā sprintā. Laika gaitā, paplašinoties sistēmas funkciju kopumam, var būt grūtāk panākt stabilu funkcionālās pārbaudes sprintu pa sprintam.
Regresijas testi
Regresijas testa mērķis ir nodrošināt, lai viss, kas darbojās līdz šim, darbotos arī pēc nākamās izlaiduma. Ir jāveic regresijas testi, lai nodrošinātu, ka starp dažādiem moduļiem nav saderības problēmu.
Regresijas testu pārbaudes gadījumi ir vislabākie, ja tie tiek regulāri uzturēti un atkārtoti apskatīti pirms katras izlaišanas. Pamatojoties uz konkrētā projekta specifiku, vislabāk ir saglabāt tos vienkāršus, taču tie aptver lielāko daļu pašu galveno funkcionalitātes un svarīgās plūsmas no gala līdz galam, kas darbojas visā sistēmā.
Parasti katrā sistēmā ir tādi procesi, kas skar daudzas dažādas jomas, un tie ir vislabākie kandidāti regresijas pārbaudes gadījumiem.
Ja pastāv automatizēti vienību testi un funkcionālie testi, automatizācijas izveide regresijas testēšanā ir ļoti vienkāršs uzdevums. Vienkārši izmantojiet to, kas jums jau ir, svarīgākajai sistēmas daļai (piemēram, ražošanā visvairāk izmantotajiem procesiem).
Lietotāju pieņemšanas testi (UAT)
Visbeidzot, UAT apstiprina, ka lietojumprogramma atbilst ražošanas izvietošanai nepieciešamajām prasībām. Šī pieeja vislabāk darbojas, ja programmatūra tiek bieži testēta īsos un intensīvos ciklos.
UAT testu veic tikai cilvēki ārpus veiklās komandas, ideālā gadījumā biznesa lietotāji īpašā vidē, kas ir pēc iespējas tuvāka nākotnes ražošanai. Alternatīvi, produkta īpašnieks šeit var aizstāt galalietotājus.
Jebkurā gadījumā tam vajadzētu būt tīram, funkcionālam testam no galalietotāja viedokļa, bez jebkāda savienojuma ar izstrādātāju komandu. Šo testu rezultāti ir paredzēti, lai pieņemtu vissvarīgāko lēmumu par ražošanas izlaišanu.
Efektīvas pārbaudes stratēģijas plānošana
Plānošana ir svarīga veiklās testēšanas sastāvdaļa, jo tā saista visu stratēģiju. Tai arī ir jānosaka skaidras laika skalas cerības sprinta kontekstā.
Efektīvi pārvaldot veiklu testēšanas plānošanu, komandas var izveidot skaidru virzienu, kas noved pie efektīvas resursu izmantošanas sprintā. Acīmredzot sagaidāma lielāka sadarbība starp testētājiem un izstrādātājiem.
Jāizveido arī visaptverošs plāns, lai noteiktu, kad katrā izstrādes sprintā notiek vienību testēšana, funkcionālā pārbaude vai lietotāju pieņemšanas pārbaude. Tādējādi ikviens precīzi zina, kad ir nepieciešama viņu līdzdalība veiksmīgai veiklai palaišanai.
Kā izveidot plānu var pēc turpmākas apspriešanas un vienošanās. Tomēr vissvarīgākais ir padarīt to par procesu un pie tā pieturēties. Izveidojiet periodiskumu, kas būs uzticams un paredzams.
Neatkāpieties no procesa. Pretējā gadījumā realitāte būs tieši pretēja – haoss un neparedzami izlaidumi ražošanā.
Pārbaužu veikšana, pamatojoties uz prasību apkopošanu
Testi jāveic atbilstoši katra posma prasībām. Pēc tam biļetes tiek atvērtas, kad tiek atrasta kļūda vai problēma, un tās tiek piešķirtas izstrādes komandai, kas pēc tam varēs izdomāt, kas kodam ir jālabo vai jāmaina. Kad visas kļūdas ir novērstas, veiklā testēšanas izpilde var turpināties, līdz visas pārbaudes ir izturētas.
Rezultātu pārskatīšana un kļūdu izsekošana
Būtiska ir efektīva rezultātu pārskatīšana un stabils kļūdu izsekošanas process. Procesā jāiesaista visas attiecīgās ieinteresētās personas, sākot no projektu vadītājiem un testētājiem līdz izstrādātājiem, un galu galā atbalsta komandām, kā arī klientiem, lai apkopotu atsauksmes.
Tai ir jābūt pietiekami visaptverošai darbībai, lai problēmas varētu ātri identificēt un novērst, pirms tiek apdraudēts jau ieplānotais izlaišanas datums.
Izvēles rīks atkal ir komandas ziņā. Taču pēc izvēles jebkurā testa darbībā ir jāiekļauj uzticami kļūdu izsekošanas procesi, lai pārraudzītu problēmas, piešķirtu tām prioritāti atbilstoši atkarībām, ziņotu par statusa atjauninājumiem no izstrādātājiem par risinājumu vai pārsūtīšanu tālākai izmeklēšanai, un pēc tam aizvērtu biļetes, kad tās ir atrisinātas.
Pārskatīšana palīdz veiklajiem testētājiem izprast savas sistēmas uzvedību, identificējot kļūdas katrā posmā, nevis vēlāk. Regulāri pārskati arī ļauj elastīgām komandām noteikt tendences un jomas, kurās nepieciešami uzlabojumi, ļaujot tām pastāvīgi atjaunināt savu testēšanas sistēmu un ātrāk izveidot labākas kvalitātes produktus.
Produkta izlaišanas pabeigšana ar ražošanas dūmu testu
Lai maksimāli palielinātu laidiena panākumus, viens no veidiem, kā iegūt lielāku pārliecību, ir dūmu tests, kas tiek veikts pret ražošanu (tūlīt pēc izlaišanas).
Šis tests sastāv no tikai lasāmu darbību kopas ražošanas sistēmā, kas neradīs nekādus jaunus nejaušus datus, bet tomēr pārbaudīs sistēmas pamata funkcionalitāti no galalietotāju viedokļa.
Īsto ieinteresēto personu iesaistīšana procesā palīdz nodrošināt saskaņošanu un atbildību, vienlaikus palielinot pārliecību, ka mērķi ir sasniegti. Galu galā šie testi garantē veiksmīgu izlaišanu.
Nepārtraukta testu integrācija un automatizācija, lai uzlabotu efektivitāti
Uzņēmumi arvien vairāk izmanto nepārtrauktu testu integrāciju un automatizāciju, lai virzītu veiklus procesus uz nākamo līmeni.
Ja komanda var ieviest automatizāciju vairākos posmos, kā aprakstīts iepriekš, tad tos var apvienot un savienot īpašā testēšanas konveijerā, kas būtībā ir pilnībā automatizēts pakešu process, kas veic lielāko daļu testēšanas darbību neatkarīgi un bez citas komandas iesaistīšanas. biedrs.
Laika gaitā šāds visaptverošs testēšanas cauruļvads saīsinās visu testēšanas posmu kopējo laiku. Galu galā tas var novest pie patiešām ātras pakāpeniskas ražošanas izlaišanas pēc katra sprinta beigām. Lai gan šis ir ideāls scenārijs, patiesībā to ir grūti sasniegt, veicot visas pārbaudes darbības. Automatizācija ir vienīgais veids, kā tur nokļūt.
Atšķirība starp veiklo testēšanu un ūdenskrituma testēšanu
Agile testēšanas stratēģijas atšķiras no tradicionālajām ūdenskritumu testēšanas stratēģijām vairākos veidos, piemēram, periodiskums, paralēlisms vai katrai darbībai atvēlēts laiks.
Bet visievērojamākā atšķirība ir katras pieejas fokuss:
- Agile testēšana koncentrējas uz pastāvīgām, straujām izstrādes iterācijām un atgriezeniskās saites cilpām, lai identificētu problēmas un ātri uzlabotu produktu. Iteratīvs process, kas vērsts uz sadarbību ar klientiem, nepārtrauktu integrāciju un adaptīvu plānošanu.
- No otras puses, tradicionālā ūdenskrituma testēšana akcentē lineāru procesu, kurā katrs posms tiek atrisināts atsevišķi un secīgā secībā, atstājot visa risinājuma atgriezenisko saiti tikai uz pašu pēdējo projekta posmu un ļoti tuvu galīgajam produkcijas izlaišanas datumam.
Acīmredzot, jo ātrāk problēmas atklās galvenās ieinteresētās puses, jo labāka situācija projektam. Šajā ziņā veiklajai metodoloģijai noteikti ir lielākas izredzes gūt panākumus.
Secinājums
Lai gan veiklās testēšanas dzīves cikls varētu šķist īsāks nekā ūdenskrituma, patiesībā tā nav. Viss process ir nepārtraukts un turpinās līdz produkta izlaišanas datumam. Atkarībā no katram sprintam pieejamā budžeta un laika, jums būs jānosaka prioritāte, kuri testi tiek veikti konkrētā sprinta laikā.
Labi izplānota testa stratēģija palīdz izvēlēties, kurām funkcijām vai moduļiem ir jāpievērš lielāka uzmanība nekā citiem. Automatizācija ļaus vienā sprintā iekļaut vairākus testēšanas posmus, palielinot sistēmas kopējo uzticamību no sprinta līdz sprintam.
Tagad varat apskatīt dažas scrum testēšanas labākās prakses.