Lietojumprogrammu testēšana agrāk bija tehniski sarežģīta, laika ziņā sarežģīta darbība, kas bija ieplānota dienas vai nedēļas pirms lietojumprogrammas izlaišanas. Izstrādes komandām tika dota rīcības brīvība kodēšanai līdz vienpadsmitajai stundai, un testētājiem, kuri lielu daļu sava darba veica manuāli, nebija lielas izvēles, kā vien iztikt ar viņiem atvēlēto laiku. Rezultāts bija tāds, ka daudzām lietojumprogrammām tika veikta neatbilstoša testēšana, un tehnoloģiju komandas bija spiestas reaģēt uz ražošanas jautājumiem un defektiem, ko saasināja galalietotāji un lietojumprogrammu uzraudzības sistēmas.
Izgatavo nepārtrauktu integrācijas praksi, vienību testēšanas ietvarus un testēšanas automatizācijas praksi ir atbalstījuši šo paradigmu. Tā vietā, lai veiktu kvalitātes nodrošināšanu izstrādes procesa beigās, daudzas testēšanas prakses tagad tiek sāktas un pilnībā izpildītas kodēšanas, integrēšanas un izvietošanas laikā. Devops un veiklās komandas automatizē skriptu testēšanu, un CI / CD cauruļvadi aicina testus veikt kodu integrēšanas vai piegādes fāzēs. Rezultāts ir tāds, ka izstrādātāji tiek brīdināti, kad viņu koda izmaiņas izjauc būvējumu, un viņi var nekavējoties rīkoties, lai novērstu paziņoto problēmu.
Testēšanas automatizēšana un testēšanas skriptu integrēšana CI / CD cauruļvados ir pazīstama kā nobīdes pa kreisi testēšana. Tas nozīmē, ka izstrādes posmā var veikt vairāk kvalitātes nodrošināšanas prakses, lai jautājumus uztvertu agrāk laidiena grafikā. Pārbaužu automatizēšana ir viena no priekšdarba prioritātēm veiklām un novirzošām komandām, kuras vēlas palielināt izvietošanas biežumu.
Ieviešot jaunu funkcionalitāti, uzbūvētie testa skripti apstiprina jaunās iespējas. Pēc tam šos testus var automatizēt un iekļaut būvēšanas vai izvietošanas darbībās. Tā vietā, lai QA inženieri atbrīvošanas procesa beigās palaistu regresijas testus, jūs varat palaist un apstiprināt daudzus no šiem testiem kā daļu no izstrādes. Šie testi pāriet pa kreisi no izlaišanas procesa beigām uz agrāko izstrādes un kodēšanas fāzi.
Testēšana pa kreisi un pa kreisi ļauj veiklām komandām uzticēties kvalitātei
Pārslēgšana pa kreisi un pa kreisi ne tikai veicina efektivitāti un uzlabo kvalitāti, bet arī rada ievērojamas kultūras izmaiņas veiklā izstrādes procesā.
Dažas izstrādes komandas kvalitātes nodrošināšanu un testēšanu uztver kā šķērsli koda piegādei ražošanā. Pēc visa smagā darba, lai apmierinātu veiklus produktu īpašniekus un aizpildītu kodu, kvalitātes nodrošināšanas komandas biedri identificē to kļūdu sarakstu, kurām nepieciešama novēršana. Ja QA atrod daudz kļūdu, tas var ietekmēt izlaišanas laika skalu, lai tās novērstu. Vēl sliktāk ir tad, kad nozīmīgām koda sadaļām ir jāpārveido, jo trūkumi atklāj loģikas, drošības vai veiktspējas problēmas. Šajā scenārijā izstrādātāji un kvalitātes nodrošināšanas inženieri var būt vienā un tajā pašā veiklā komandā, bet nedarbojas kā komanda.
Pārslēgšana pa kreisi un pa kreisi ļauj veiklām komandām nodot kvalitātes atbildību pilnai izstrādātāju un testētāju komandai. Kad testēšana notiek kā daļa no CI / CD cauruļvada, tā sniedz labāku iespēju izstrādātājiem risināt kvalitātes problēmas brīdī, kad viņi strādā pie attiecīgā koda. CI / CD cauruļvads brīdina neizdevušās būves izstrādātāju, un lielākajai daļai pašorganizējošo izstrādātāju komandu šīs problēmas nekavējoties jānovērš.
Testēšana pa kreisi un pa kreisi nodrošina arī izstrādātājiem un kvalitātes nodrošināšanas inženieriem iespējas vairāk testēt. Labākā prakse ir komandām izlemt, kurš īsteno automatizāciju atkarībā no testu veidiem, kas nepieciešami izstrādātajai funkcionalitātei. Piemēram, izstrādātāji bieži ir atbildīgi par vienību un API testu automatizāciju, bet kvalitātes nodrošināšanas inženieri bieži izstrādā gala gala lietotāju testēšanas un darījumu testus, kas simulē daudzpakāpju API izsaukumus uz vairākiem pakalpojumiem.
Kad jāpiemēro nobīdes pa kreisi testēšana
Pārslēgšanās pa kreisi pa kreisi vislabāk darbojas vienības līmeņa atomu testiem, kuriem ir īss izpildes laiks. Ir svarīgi, lai CI / CD cauruļvadā automatizētie testi tiktu veikti vienmēr, kad izstrādātāji sāk būvēt, tie tiktu ātri izpildīti un nepalēninātu būvēšanas procesus.
Sarežģītāki un laikietilpīgāki testi, piemēram, gala lietotāja pārbaude, darījumu pārbaude, statiskā koda analīze un drošības pārbaude, bieži darbojas labāk ārpus CI / CD cauruļvadiem un ikdienas vai biežāk. Šie testi joprojām sniedz agrīnu atgriezenisko saiti izstrādātājiem par kvalitātes jautājumiem, taču tie tiek automatizēti ārpus CI / CD, lai izvairītos no būvniecības palēnināšanās vai sašaurināšanās.
Tomass Dž. Salds, GM Financial IT pakalpojumu viceprezidents, dalījās ar mani savos personīgajos ieskatos par maiņas pa kreisi testēšanas stratēģiju robežām. Viņš ierosina: “Pārslēgšana pa kreisi vienmēr ir stratēģija, izņemot gadījumus, kad veicat trešo pušu piegādātāju piegāžu integrācijas testēšanu, jo jums bieži nav piekļuves viņu avota kodam. Pat tad, ja jums ir iekšējas lietotnes ar mantotām monolītām arhitektūrām, varat sākt, ieviešot pamata reģistrēšanās politikas, kurām nepieciešama koda pārskatīšana un drošības skenēšana. Reģistrēšanās ir jānoraida, ja skenēšana ietver būtiskus brīdinājumus un kļūmes. ”
Viens potenciāls risinājums pakārtotajā testēšanā ar integrācijas partneriem ir pakalpojumu virtualizācijas ieviešana. Šis paņēmiens ļauj izstrādes komandām simulēt pakārtotās sistēmas reakciju uz dažādiem ieguldījumiem. Tas darbojas labi, ja pakārtotās sistēmas ir labi definētas. Rīki no Micro Focus, Tricentis un citiem iespējo šo iespēju.
Robs Počiluks, ļoti pieredzējis kvalitātes nodrošināšanas vadītājs, ir spēcīgs kustīgās kreisās puses testēšanas atbalstītājs veiklā attīstībā. “Gatavība un spēja pārbaudīt nelielas koda sadaļas saglabā QA elastību un loku sprinta progresa laikā. Komandām joprojām vajadzētu pasargāties no pārāk lielas kreisās puses izmantošanas, jo jūs varat zaudēt paša koda mērķi. ”
Tātad, pat ja komandas pilnībā izmanto kreisās puses kreisās puses testēšanu, ir pamatoti iemesli, lai joprojām ieplānotu testēšanas logu koda komplektam, kura mērķis ir izlaišana. Tas nodrošina, ka visi automatizētie testi tiek veikti ar pēdējo būvējumu, bet arī ļauj ieplānot papildu testēšanu, kurai nepieciešama pilnībā funkcionējoša sistēma.
Viens no šiem testiem ir UAT (lietotāju pieņemšanas pārbaude), kur izvēlētie galalietotāji un priekšmetu eksperti apstiprina un sniedz atsauksmes. Dažus UAT var veikt izstrādes laikā, taču, iespējams, nav viegli panākt, lai cilvēki bieži veiktu šo testēšanu vai kad funkcionalitāte nav pilnībā gatava.
Priekšnosacījumi pārejas pa kreisi testēšanas stratēģijām
Pārslēgšanās pa kreisi un pa kreisi ir pieaugoša devops prakse, taču tai ir savi priekšnoteikumi un sākotnēji ieguldījumi. Nepieciešamas dažas būtiskas iespējas un prakse.
- Lai atbalstītu vienlaicīgi veikto būvējumu un testu skaitu, ir nepieciešama pietiekama testēšanas jauda un vide.
- Veiklām komandām ir nepieciešams testēšanas produktu rīks, kas viegli integrējas CI / CD cauruļvados un darba plānošanas rīkos un kas var apstiprināt funkcionalitāti, koda kvalitāti, drošību un veiktspēju.
- Arhitektiem, infosec speciālistiem, QA vadītājiem un citiem vecākajiem organizācijas locekļiem būtu jāizveido testēšanas standarti un pakalpojuma līmeņa mērķi, kas veido noklusējuma pieņemšanas kritērijus.
- Ja lietojumprogrammām ir nepieciešama lietotāja ievade, testēšanas komandām ir nepieciešami pietiekami daudz testa datu un modeļu, lai apstiprinātu pietiekami daudz personu, lietojuma gadījumu un ievades modeļu.
- Pēc sprinta saistībām vai agrāk, skrāpju komandām, tostarp QA testu automatizācijas inženieriem, jānosaka testēšanas stratēģija par to, kādas iespējas tiek pārbaudītas, kādi testēšanas veidi tiek ieviesti, kādi automatizācijas procesi tiek atjaunināti un kas testus izstrādā.
- Devops komandām vajadzētu izmērīt CI / CD cauruļvadu darbības ilgumu un atzīmēt, kad automatizētās testēšanas darbības ietekmē produktivitāti. Devops komandām bieži ir nepieciešami papildu testēšanas grafiki ārpus CI / CD cauruļvadiem, lai veiktu ilgāk veicamus testus.
- Komandām regulāri jāapspriež nepilnības automatizētajos testos, jo īpaši validācijas, kurās nepieciešami priekšmetu eksperti, UAT vai testēšana ar partneriem. Ja veiklās komandas nevar novērst šīs nepilnības ar automatizāciju, tad atbrīvošanas cikliem būtu jāņem vērā pieskaitāmās izmaksas, lai samazinātu riskus un pabeigtu šos testus.
Visbeidzot, veiklām komandām un organizācijām vajadzētu regulāri izmērīt un apspriest testu pārklājumu. Testēšanas stratēģijas maiņa pa kreisi pa kreisi nedarbojas, ja izstrādes komandas un kvalitātes automatizācijas inženieri faktiski neievieš, neautomizē un neintegrē pietiekami daudz testu, lai uztvertu problēmas un novērstu riskus.
Paātrinot izlaišanas ciklus vai nodrošinot nepārtrauktu piegādi bez pietiekamas testa automatizācijas, var rasties nozīmīgas kvalitātes problēmas, kas pasliktina galalietotāju pieredzi. Izveicīgas izstrādes komandas, kas pārāk bieži spiež izlaidumus, pēc tam nonāk pie problēmu risināšanas saistībā ar ražošanu un defektiem, nevis iegulda vairāk un labākā automatizācijā.
