Test af applikationer plejede at være en teknisk udfordrende, tidskrævet aktivitet planlagt dage eller uger før en applikations frigivelse. Udviklingsteams fik spillerum til kode indtil den ellevte time, og testere, der udførte meget af deres arbejde manuelt, havde ikke andet valg end at nøjes med den tid, de fik. Resultatet var, at mange applikationer blev testet under standard, og teknologiteams blev tvunget til at reagere på produktionsproblemer og mangler eskaleret af slutbrugere og applikationsovervågningssystemer.
Devops kontinuerlig integrationspraksis, enhedstestrammer og testautomatiseringspraksis har hævet dette paradigme. I stedet for at udføre kvalitetssikring i slutningen af udviklingsprocessen starter mange testpraksis nu og udføres fuldt ud under kodning, integration og implementering. Devops og agile teams automatiserer testscripts, og CI / CD-rørledninger kalder på for at køre testene under deres kodeintegrations- eller leveringsfaser. Nettoresultatet er, at udviklere advares, når deres kodeændringer bryder build og kan tage øjeblikkelige skridt til at løse det rapporterede problem.
Automatisering af test og integration af testskripts i CI / CD-rørledninger kaldes shift-left-test. Det indebærer, at der kan udføres mere kvalitetssikringspraksis i udviklingsfasen for at fange problemer tidligere i frigivelsestidslinjen. Automatisering af test er en af prioriteringsprioriteterne for agile og devops-teams, der ønsker at øge installationsfrekvensen.
Ved introduktionen af ny funktionalitet validerer de konstruerede testscripts de nye muligheder. Disse tests kan derefter automatiseres og inkluderes i build- eller implementeringstrinene. I stedet for at få QA-ingeniører til at køre regressionstest i slutningen af en frigivelsesproces, kan du køre og validere mange af disse tests som en del af udviklingen. Disse tests skifter til venstre fra slutningen af frigivelsesprocessen til tidligere udviklings- og kodningsfaser.
Shift-left-test muliggør agile teams engagement i kvalitet
Skift-venstre-test driver ikke kun effektivitet og forbedrer kvaliteten, det skaber også en betydelig kulturændring i den agile udviklingsproces.
Nogle udviklingsteam opfatter kvalitetssikring og test som en barriere for at få deres kode leveret til produktion. Efter alt det hårde arbejde med at tilfredsstille smidige produktejere og udfylde koden identificerer QA-holdkammerater en liste over fejl, der kræver afhjælpning. Hvis QA finder mange fejl, kan det påvirke frigivelsestidslinjen for at rette dem. Endnu værre er, når vigtige sektioner i koden har behov for ombygning, fordi fejl udsætter logik, sikkerhed eller ydeevne. I dette scenarie er udviklere og QA-ingeniører muligvis i det samme adræt hold, men fungerer ikke som et team.
Shift-left-test giver agile teams mulighed for at skifte kvalitetsansvar til hele teamet af udviklere og testere. Når test køres som en del af CI / CD-pipelinen, giver det en bedre mulighed for udviklere at løse kvalitetsproblemer på det tidspunkt, hvor de arbejder på den relevante kode. CI / CD-pipelinen advarer udvikleren af den mislykkede build, og de fleste selvorganiserende udviklingsteams skal løse disse problemer med det samme.
Shift-left-test giver også udviklere og QA-ingeniører mulighed for at automatisere mere af testen. En bedste praksis er, at hold beslutter, hvem der implementerer automatiseringen, afhængigt af hvilke typer test der kræves for den udviklede funktionalitet. For eksempel er udviklere ofte ansvarlige for automatisering af enheds- og API-tests, men QA-automatiseringsingeniører udvikler ofte end-to-end brugeroplevelsestests og transaktionstest, der simulerer multisteg API-opkald til flere tjenester.
Hvornår skal man anvende skift-venstre test
Shift-left-test fungerer bedst til de mere atomare tests på enhedsniveau, der har korte udførelsestider. Det er vigtigt, at tests automatiseret i CI / CD-pipelinen, og at de kører, når udviklere udløser en build, udfører hurtigt og ikke bremser build-processerne.
Mere komplekse og tidskrævende tests såsom end-to-end-brugeroplevelsestest, transaktionstest, statisk kodeanalyse og sikkerhedstest kører ofte bedre uden for CI / CD-rørledninger og på daglige eller hyppigere tidsplaner. Disse tests giver stadig tidlige feedback til udviklere om kvalitetsproblemer, men de automatiseres uden for CI / CD for at undgå langsommere eller flaskehalsopbygninger.
Thomas J. Sweet, en vicepræsident i it-tjenester hos GM Financial, delte med mig hans personlige indsigt i grænserne for skift-venstre teststrategier. Han foreslår, ”Skift til venstre er altid en strategi, undtagen når man udfører integrationstest på tredjepartsleverandører, da man ofte ikke har adgang til deres kildekode. Selv når du har interne apps med ældre monolitiske arkitekturer, kan du starte med at håndhæve grundlæggende check-in-politikker, der kræver en kodevurdering og sikkerhedsscanning. Indtjekningen skal afvises, hvis scanningen indeholder vigtige advarsler og fejl. ”
En potentiel løsning til downstream-test med integrationspartnere er at implementere virtualisering af tjenester. Denne teknik gør det muligt for udviklingshold at simulere et downstream-systems svar på forskellige input. Det fungerer godt, når downstream-systemerne er veldefinerede. Værktøjer fra Micro Focus, Tricentis og andre muliggør denne mulighed.
Rob Pociluk, en meget erfaren kvalitetssikringschef, er en stærk tilhænger af skift-venstre-test i agil udvikling. ”At være klar og i stand til at teste små sektioner med kode holder QA fleksibel og i løkken under løbet af en sprint. Hold bør stadig beskytte sig mod at bruge shift-venstre for meget, da du kan miste formålet med selve koden. ”
Så selv når hold fuldt ud omfavner shift-left-test, er der gode grunde til stadig at planlægge et testvindue på en kodefuldstændig build, der er målrettet til frigivelse. Det sikrer, at alle automatiserede tests udføres på den endelige build, men muliggør også planlægning af yderligere test, der kræver et fuldt fungerende system.
En af disse tests er UAT (test af brugeraccept), hvor udvalgte slutbrugere og fageksperter validerer og giver feedback. Nogle UAT kan udføres under udviklingen, men det er måske ikke let at få folk til at udføre denne test ofte, eller når funktionaliteten ikke er helt klar.
Forudsætninger for at skifte til venstre teststrategier
Shift-left-test er en voksende devops-praksis, men den har sine forudsætninger og investeringer på forhånd. Der kræves nogle væsentlige funktioner og fremgangsmåder.
- Tilstrækkelig testkapacitet og miljøer er nødvendige for at understøtte antallet af builds og tests, der kører samtidigt.
- Agile teams kræver et værktøjssæt til test af produkter, der let integreres i CI / CD-rørledninger og jobplanlægningsværktøjer, og som kan validere funktionalitet, kodekvalitet, sikkerhed og ydeevne.
- Arkitekter, infosec-specialister, QA-ledere og andre seniormedlemmer i organisationen bør oprette teststandarder og mål på serviceniveau, der danner standardacceptkriterierne.
- Når applikationer kræver brugerinput, har testteams brug for tilstrækkelige testdata og mønstre til at validere nok personas, brugssager og inputmønstre.
- Ved sprint-engagement eller tidligere bør scrum-hold, herunder QA-testautomatiseringsingeniører, opstille en teststrategi for, hvilke muligheder der bliver testet, hvilke typer test der implementeres, hvilke automatiseringsprocesser der opdateres, og hvem der udvikler testene.
- Devops-hold skal måle varigheden af CI / CD-pipeline-kørsler og markere, når automatiserede testtrin påvirker produktiviteten. Devops-hold kræver ofte yderligere testplaner uden for CI / CD-rørledninger for at udføre test, der kører længere.
- Hold bør regelmæssigt diskutere huller i deres automatiserede tests, især valideringer, der kræver fageksperter, UAT eller test med partnere. Hvis agile teams ikke kan løse disse huller med automatisering, skal frigivelsescyklusser være en faktor i omkostningerne for at reducere risici og gennemføre disse tests.
Endelig bør agile teams og devops-organisationer regelmæssigt måle og diskutere deres testdækning. Anvendelse af en teststrategi med skift til venstre fungerer ikke, hvis udviklingsholdene og kvalitetsautomatiseringsingeniørerne faktisk ikke implementerer, automatiserer og integrerer tilstrækkelige tests til at fange problemer og løse risici.
Fremskyndelse af frigivelsescyklusser eller muliggør kontinuerlig levering uden tilstrækkelig testautomatisering kan resultere i betydelige kvalitetsproblemer, der forringer slutbrugernes oplevelse. Agile udviklingsteam, der skubber udgivelser for ofte, finder sig selv i at løse produktionsproblemer og mangler i stedet for at investere i mere og bedre automatisering.
