Testiranje aplikacij je bilo včasih tehnično zahtevna, časovno omejena dejavnost, načrtovana dneve ali tedne pred sprostitvijo aplikacije. Razvojne ekipe so imele manevrski prostor za kodiranje do enajste ure, preizkuševalci, ki so večino svojega dela opravljali ročno, pa so imeli le malo možnosti, da bi se zadovoljili s časom, ki jim je bil dan. Rezultat tega je bil, da so bile številne aplikacije podvržene podstandardnim preizkusom, tehnološke ekipe pa so se bile prisiljene odzvati na proizvodne težave in napake, ki so jih stopnjevali končni uporabniki in sistemi za nadzor aplikacij.
Ukvarjajo se s praksami neprekinjene integracije, okviri za preskušanje enot in praksami avtomatizacije preskusov. Namesto zagotavljanja kakovosti na koncu razvojnega postopka se zdaj med kodiranjem, integracijo in uvajanjem začnejo in v celoti izvajajo številne prakse preizkušanja. Razvojne in agilne ekipe avtomatizirajo preizkusne skripte, cevovodi CI / CD pa zahtevajo, da zaženejo teste med fazami integracije ali dostave kode. Končni rezultat je, da so razvijalci opozorjeni, ko spremembe kode prekinejo gradnjo, in lahko takoj ukrepajo, da rešijo prijavljeno težavo.
Avtomatizacija preskušanja in vključevanje preizkusnih skriptov v CI / CD cevovode je znano kot preskus v levo. To pomeni, da je mogoče v razvojni fazi narediti več praks za zagotavljanje kakovosti, da se ujamejo vprašanja prej na časovni osi izdaje. Avtomatizirano testiranje je ena od prednostnih nalog za predhodno uvajanje za agilne in devops ekipe, ki želijo povečati pogostost uvajanja.
Ob uvedbi nove funkcionalnosti izdelani testni skripti potrdijo nove zmogljivosti. Te teste lahko nato avtomatizirate in vključite v korake gradnje ali uvajanja. Namesto da bi inženirji QA izvajali regresijske teste na koncu postopka izdaje, lahko mnoge od teh testov zaženete in potrdite kot del razvoja. Ti testi se premaknejo s konca postopka izdaje na prejšnje faze razvoja in kodiranja.
Preizkus levo v smeri premika omogoča zavzetost ekip za zavezanost kakovosti
Preizkušanje v levo in desno smer ne spodbuja le učinkovitosti in izboljšuje kakovosti, ampak ustvarja tudi pomembne spremembe v kulturi v agilnem procesu razvoja.
Nekatere razvojne skupine zagotavljajo zagotavljanje kakovosti in testiranje oviro pri dostavi kode v proizvodnjo. Po trdem delu pri zadovoljevanju okretnih lastnikov izdelkov in izpolnjevanju kode, soigralci QA identificirajo seznam napak, ki jih je treba odpraviti. Če QA najde veliko napak, lahko vpliva na časovni trak izdaje in jih odpravi. Še huje je, ko je treba pomembne odseke kode preoblikovati, ker napake razkrivajo težave z logiko, varnostjo ali zmogljivostjo. V tem primeru so razvijalci in inženirji za zagotavljanje kakovosti morda v isti gibčni skupini, vendar ne delujejo kot skupina.
Preizkus levo v smeri premika ekipam omogoča, da odgovornost za kakovost prenesejo na celotno skupino razvijalcev in preizkuševalcev. Ko se testiranje izvaja kot del cevovoda CI / CD, ponuja razvijalcem boljšo priložnost za reševanje težav s kakovostjo v trenutku, ko delajo na ustrezni kodi. Cevovod CI / CD razvijalca opozori na neuspešno gradnjo in večina samoorganiziranih razvojnih skupin zahteva, da te težave odpravi takoj.
Preizkus levo v smeri premika tudi razvijalcem in inženirjem za zagotavljanje kakovosti omogoča avtomatizacijo večjega dela testiranja. Najboljša praksa je, da se ekipe odločijo, kdo bo uvedel avtomatizacijo, odvisno od vrst preskusov, potrebnih za razvito funkcionalnost. Na primer, razvijalci so pogosto odgovorni za avtomatizacijo preskusov enot in API-jev, vendar inženirji avtomatizacije QA pogosto razvijejo testiranje uporabniške izkušnje in preizkuse transakcij, ki simulirajo večstopenjske klice API-jev za več storitev.
Kdaj uporabiti preskus levo v smeri
Preizkus levo v smeri premika deluje najbolje za atomske teste na ravni enote, ki imajo kratke izvedbene čase. Bistveno je, da se testi samodejno preizkusijo v cevovodu CI / CD in se izvajajo, kadar koli razvijalci sprožijo gradnjo, se hitro izvajajo in ne upočasnjujejo procesov gradnje.
Kompleksnejši in časovno zahtevnejši preskusi, kot so preizkusi uporabniške izkušnje, preskušanje transakcij, statična analiza kode in preizkušanje varnosti, se pogosto bolje izvajajo zunaj cevovodov CI / CD in na dnevnih ali pogostejših urnikih. Ti testi še vedno ponujajo zgodnje povratne informacije razvijalcem o vprašanjih kakovosti, vendar so avtomatizirani zunaj CI / CD, da se izognejo upočasnjevanju ali ozkim gradnjam.
Thomas J. Sweet, podpredsednik za IT storitve pri GM Financial, je z mano delil svoja osebna spoznanja o mejah strategij testiranja v levo in desno smer. Predlaga: »Premik v levo je vedno strategija, razen pri preskušanju integracije pri dobavah neodvisnih ponudnikov, saj pogosto nimate dostopa do njihove izvorne kode. Tudi če imate notranje aplikacije s starejšimi monolitnimi arhitekturami, lahko začnete z uveljavljanjem osnovnih pravil za prijavo, ki zahtevajo pregled kode in varnostno skeniranje. Če pregled vključuje bistvena opozorila in napake, je treba prijavo zavrniti. "
Ena od potencialnih rešitev za nadaljnje testiranje s partnerji za integracijo je izvajanje virtualizacije storitev. Ta tehnika omogoča razvojnim skupinam, da simulirajo odziv nadaljnjega sistema na različne vložke. Dobro deluje, če so spodnji sistemi dobro opredeljeni. Orodja Micro Focus, Tricentis in drugih omogočajo to zmožnost.
Rob Pociluk, zelo izkušen vodja zagotavljanja kakovosti, je močan zagovornik testiranja v levem premiku v agilnem razvoju. »Pripravljenost in zmožnost testiranja majhnih delov kode ohranja QA prilagodljivo in v toku med potekom sprinta. Ekipe bi se morale še vedno paziti, da preveč ne bi uporabljale premika v levo, saj lahko izgubite namen same kode. "
Torej, tudi če ekipe v celoti prevzamejo testiranje v levo, obstajajo tehtni razlogi, da še vedno načrtujete preskusno okno za celotno kodo, ki je namenjena izdaji. Zagotavlja, da se vsi avtomatizirani testi izvedejo v končni gradnji, hkrati pa omogoča razporejanje dodatnih preskusov, ki zahtevajo popolnoma delujoč sistem.
Eden od teh testov je UAT (test sprejemljivosti uporabnikov), kjer izbrani končni uporabniki in strokovnjaki za vsebino potrdijo in posredujejo povratne informacije. Med razvojem je mogoče opraviti nekaj UAT-a, vendar ljudi morda ne bo težko prepričati, da pogosto izvajajo to testiranje ali kadar funkcionalnost ni popolnoma pripravljena.
Predpogoji za preskusne strategije levo-desno
Testiranje v levo in desno smer je vedno večja praksa devopsa, vendar ima svoje predpogoje in vnaprejšnje naložbe. Potrebne so nekatere bistvene zmogljivosti in prakse.
- Za podporo številu graditev in preskusov, ki se izvajajo hkrati, so potrebne zadostne preskusne zmogljivosti in okolja.
- Agilne ekipe zahtevajo komplet orodij za testiranje izdelkov, ki se zlahka vključijo v cevovode CI / CD in orodja za razporejanje opravil ter ki lahko potrdijo funkcionalnost, kakovost kode, varnost in učinkovitost.
- Arhitekti, strokovnjaki za infosec, vodje zagotavljanja kakovosti in drugi starejši člani organizacije bi morali določiti preskusne standarde in cilje na ravni storitve, ki tvorijo privzeta merila za sprejem.
- Kadar aplikacije zahtevajo uporabniški vnos, preskusne skupine potrebujejo dovolj testnih podatkov in vzorcev, da preverijo dovolj osebnosti, primerov uporabe in vzorcev vnosa.
- Ob prevzemu sprinta ali prej bi morale ekipe za scrum, vključno z inženirji za avtomatizacijo preskusov QA, določiti strategijo testiranja, katere zmogljivosti se preizkušajo, katere vrste testiranja se izvajajo, kateri postopki avtomatizacije se posodabljajo in kdo razvija teste.
- Skupine za pospeševanje bi morale izmeriti trajanje tekov cevovodov CI / CD in označiti, ko avtomatizirani preskusni koraki vplivajo na produktivnost. Skupine za preusmeritve pogosto zahtevajo dodatne urnike testiranja zunaj cevovodov CI / CD za izvajanje daljših preskusov.
- Skupine bi morale redno razpravljati o vrzelih v svojih avtomatiziranih testih, zlasti o validacijah, za katere so potrebni strokovnjaki za predmet, UAT ali testiranje s partnerji. Če gibčne ekipe teh vrzeli ne morejo odpraviti z avtomatizacijo, morajo cikli sproščanja upoštevati režijske stroške, da zmanjšajo tveganja in opravijo te teste.
Na koncu bi morali tudi agilne ekipe in organizacije devops redno meriti in razpravljati o svoji pokritosti s testi. Uporaba strategije preskušanja v levo ne deluje, če razvojne skupine in inženirji za avtomatizacijo kakovosti dejansko ne izvajajo, avtomatizirajo in integrirajo dovolj testov za odkrivanje težav in reševanje tveganj.
Pospeševanje ciklov izdaje ali omogočanje neprekinjene dostave brez zadostne avtomatizacije preskusov lahko povzroči pomembne težave s kakovostjo, ki poslabšajo izkušnjo za končne uporabnike. Agilne razvojne ekipe, ki prepogosto pritiskajo na izdaje, se nato znajdejo pri proizvodnih težavah in napakah, namesto da bi vlagale v več in boljšo avtomatizacijo.
