Programmering

Hvordan forbedre CI / CD med shift-left testing

Testing av applikasjoner pleide å være en teknisk utfordrende, tidsnøkkel aktivitet planlagt dager eller uker før en applikasjons utgivelse. Utviklingsteamene fikk spillerom til å kode til den ellevte timen, og testere, som gjorde mye av sitt arbeid manuelt, hadde lite annet valg enn å nøye seg med den tiden de fikk. Resultatet var at mange applikasjoner gjennomgikk substandardtesting, og teknologiteamene ble tvunget til å svare på produksjonsproblemene og manglene trappet opp av sluttbrukere og applikasjonsovervåkningssystemer.

Devops kontinuerlig integrasjonspraksis, enhetstestingsrammer og testautomatiseringspraksis har oppgradert dette paradigmet. I stedet for å utføre kvalitetssikring på slutten av utviklingsprosessen, starter mange testpraksis nå og utføres fullt ut under koding, integrering og distribusjon. Devops og smidige team automatiserer testskripter, og CI / CD-rørledninger ringer for å kjøre testene i løpet av kodeintegrasjons- eller leveringsfasen. Nettoresultatet er at utviklere blir varslet når kodeendringene deres bryter bygningen og kan ta umiddelbare skritt for å løse det rapporterte problemet.

Automatisering av testing og integrering av testskript i CI / CD-rørledninger er kjent som shift-left testing. Det innebærer at mer kvalitetssikringspraksis kan gjøres i utviklingsfasen for å fange problemer tidligere i utgivelsestidslinjen. Automatisering av testing er en av prioriteringsprioriteringene for smidige og devops-team som vil øke distribusjonsfrekvensen.

Ved innføringen av ny funksjonalitet validerer de konstruerte testskriptene de nye funksjonene. Disse testene kan deretter automatiseres og inkluderes i trinnene for bygging eller distribusjon. I stedet for å la QA-ingeniører kjøre regresjonstester på slutten av en utgivelsesprosess, kan du kjøre og validere mange av disse testene som en del av utviklingen. Disse testene skifter til venstre fra slutten av utgivelsesprosessen til tidligere utviklings- og kodingsfaser.

Skift-venstre-testing muliggjør smidige teams forpliktelse til kvalitet

Skift-venstre-testing driver ikke bare effektiviteten og forbedrer kvaliteten, det skaper også en betydelig kulturendring i den smidige utviklingsprosessen.

Noen utviklingsteam opplever kvalitetssikring og testing som en barriere for å få koden levert til produksjon. Etter alt det harde arbeidet med å tilfredsstille smidige produkteiere og fullføre koden, identifiserer QA-lagkamerater en liste over feil som krever utbedring. Hvis QA finner mange feil, kan det påvirke utgivelsestidslinjen for å fikse dem. Enda verre er når viktige deler av koden trenger omprosjektering fordi feil avslører problemer med logikk, sikkerhet eller ytelse. I dette scenariet kan utviklere og QA-ingeniører være på det samme smidige teamet, men fungerer ikke som et team.

Skift-venstre-testing gjør at smidige team kan skifte kvalitetsansvar til hele teamet av utviklere og testere. Når testing kjøres som en del av CI / CD-rørledningen, gir det en bedre mulighet for utviklere å løse kvalitetsproblemer på det tidspunktet de jobber med den aktuelle koden. CI / CD-rørledningen varsler utvikleren av den mislykkede bygningen, og de fleste selvorganiserende utviklingsteam krever å løse disse problemene umiddelbart.

Skift-venstre-testing gir også utviklere og QA-ingeniører muligheter til å automatisere mer av testingen. En god praksis er at team bestemmer hvem som implementerer automatiseringen, avhengig av hvilke typer tester som kreves for utviklingen av funksjonaliteten. For eksempel er utviklere ofte ansvarlige for å automatisere enhets- og API-tester, men QA-automatiseringsingeniører utvikler ofte end-to-end brukeropplevelsestesting og transaksjonstester som simulerer flertrinns API-anrop til flere tjenester.

Når skal jeg bruke skift-venstre-testing

Skift-venstre-testing fungerer best for de mer atomnivåprøver på enhetsnivå som har korte utførelsestider. Det er viktig at tester automatisert i CI / CD-rørledningen, og som kjøres når utviklere utløser en build, kjører raskt og ikke bremser byggeprosessene.

Mer komplekse og tidskrevende tester som end-to-end brukeropplevelsestester, transaksjonstesting, statisk kodeanalyse og sikkerhetstesting kjører ofte bedre utenfor CI / CD-rørledninger og på daglige eller hyppigere tidsplaner. Disse testene gir fremdeles tidlig tilbakemelding til utviklere om kvalitetsproblemer, men de automatiseres utenfor CI / CD for å unngå å bremse eller bygge flaskehals.

Thomas J. Sweet, administrerende direktør i IT-tjenester hos GM Financial, delte med meg sin personlige innsikt i grensene for skift-venstre-teststrategier. Han foreslår: "Skift til venstre er alltid en strategi, bortsett fra når du utfører integrasjonstesting på tredjepartsleverandører, da du ofte ikke har tilgang til kildekoden. Selv når du har interne apper med eldre monolitiske arkitekturer, kan du starte med å håndheve grunnleggende innsjekkingsretningslinjer som krever en kodegjennomgang og sikkerhetskanning. Innsjekkingen bør avvises hvis skanningen inkluderer viktige advarsler og feil. ”

En potensiell løsning for testing nedstrøms med integrasjonspartnere er å implementere tjenestevirtualisering. Denne teknikken gjør det mulig for utviklingsteam å simulere et nedstrøms systems respons på forskjellige innganger. Det fungerer bra når nedstrøms systemene er godt definert. Verktøy fra Micro Focus, Tricentis og andre muliggjør denne muligheten.

Rob Pociluk, en høyt erfaren kvalitetssikringsleder, er en sterk forkjemper for skift-venstre-testing i smidig utvikling. “Å være klar og i stand til å teste små seksjoner med kode holder QA fleksibel og i løkken under fremdriften av en sprint. Lag bør fremdeles beskytte seg mot å bruke shift-venstre for mye, ettersom du kan miste formålet med selve koden. "

Så selv om lag fullt ut omfavner skift-venstre-testing, er det gode grunner til å fremdeles planlegge et testvindu på en kodefullstendig versjon rettet mot utgivelse. Det sørger for at alle automatiserte tester blir utført på den endelige bygningen, men gjør det også mulig å planlegge ytterligere tester som krever et fullt fungerende system.

En av disse testene er UAT (testing av brukeraksept), der utvalgte sluttbrukere og fageksperter validerer og gir tilbakemelding. Noen UAT kan gjøres under utviklingen, men det kan ikke være lett å få folk til å utføre denne testen ofte, eller når funksjonaliteten ikke er helt klar.

Forutsetninger for å skifte venstre teststrategier

Skift-venstre-testing er en voksende devops-praksis, men den har sine forutsetninger og forhåndsinvesteringer. Noen viktige evner og praksis er påkrevd.

  • Tilstrekkelig testkapasitet og miljøer er nødvendig for å støtte antall bygg og tester som kjører samtidig.
  • Agile team krever et verktøy for å teste produkter som enkelt kan integreres i CI / CD-rørledninger og jobbplanleggingsverktøy, og som kan validere funksjonalitet, kodekvalitet, sikkerhet og ytelse.
  • Arkitekter, infosec-spesialister, QA-ledere og andre seniormedlemmer i organisasjonen bør etablere teststandarder og mål på servicenivå som danner standardkriteriene for aksept.
  • Når applikasjoner krever brukerinndata, trenger testteam tilstrekkelig testdata og mønstre for å validere nok personas, brukstilfeller og inndatamønstre.
  • Ved sprintforpliktelse eller tidligere, burde scrumteam, inkludert QA-testautomatiseringsingeniører, sette en teststrategi på hvilke evner som blir testet, hvilke typer testing som implementeres, hvilke automatiseringsprosesser som oppdateres, og hvem som utvikler testene.
  • Devops-team bør måle varigheten av kjøringer av CI / CD-rørledninger og flagge når automatiserte testingstrinn påvirker produktiviteten. Devops-team krever ofte ekstra testplaner utenfor CI / CD-rørledninger for å utføre tester som varer lenger.
  • Lag bør regelmessig diskutere hull i automatiserte tester, spesielt valideringer som krever fageksperter, UAT eller testing med partnere. Hvis smidige team ikke kan løse disse hullene med automatisering, bør frigjøringssykluser faktorere i overhead for å redusere risikoen og fullføre disse testene.

Til slutt bør smidige team og organisasjoner regelmessig måle og diskutere testdekningen. Å benytte en skift-venstre teststrategi fungerer ikke hvis utviklingsteamene og kvalitetsautomatiseringsingeniørene faktisk ikke implementerer, automatiserer og integrerer tilstrekkelige tester for å fange problemer og løse risikoer.

Fremskynde utgivelsessykluser eller muliggjør kontinuerlig levering uten tilstrekkelig testautomatisering kan føre til betydelige kvalitetsproblemer som forringer opplevelsen for sluttbrukere. Agile utviklingsteam som presser utgivelser for ofte, finner seg selv i å løse produksjonsproblemer og mangler i stedet for å investere i mer og bedre automatisering.

$config[zx-auto] not found$config[zx-overlay] not found