DevOps er den nyeste udvikling i en lang række ændringer, der har præget softwareudviklingsmetoder gennem tiden. Fra vandfaldsmodellen til Agile, og nu til DevOps, har hver overgang ændret både rollefordelingen og de aktiviteter, som testere udfører. For at forstå, hvordan DevOps påvirker testning, er det vigtigt at se på de tidligere faser og hvordan de har udviklet sig.

I en vandfaldsmodel har testere ansvaret for at udarbejde teststrategier og eksekvere dem. Testeren arbejder relativt uafhængigt med at finde og rapportere fejl i softwaren. Selvom samarbejde med udviklere, testledere og andre funktioner er en del af processen, er det stadig testeren, der bærer hovedansvaret for selve testaktiviteten. Denne rolle som 'test' er dermed tæt forbundet med identiteten som professionel tester i teamet.

I Agile-miljøer ændres denne rolle. Testning bliver et kollektivt ansvar for hele udviklingsteamet. Testideer, udforskning af softwaren og problemløsning foregår i fællesskab, hvilket giver teamet en bredere vifte af perspektiver. Denne samarbejdende tilgang betyder, at testning ikke længere er en isoleret aktivitet, men et kontinuerligt engagement i hele udviklingsprocessen. Desuden ændrer forholdet til forretningen sig. I Agile er kravsbeskrivelser mere samarbejdsorienterede gennem metoder som Behaviour Driven Development (BDD), og vigtigheden af accepttestning bliver mindre presserende, da forretningen er mere integreret i den daglige udvikling.

DevOps går endnu længere. I DevOps-rammen er det ikke længere kun udviklingsteamet, der er ansvarlige for testningen, men et større netværk af samarbejdspartnere, som omfatter både operationelle infrastrukturer og overvågning, kundesupport og analyse. Denne udvidelse af teamet og ansvarsområderne skaber nye muligheder for at skubbe testaktiviteter ud i organisationen og inkorporere ny teknologi og processer. Eksempler på dette er brugen af on-demand cloud-baseret infrastruktur, som muliggør testning i et produktionslignende miljø, eller A/B-test, som giver hurtig feedback fra kunder og kan anvendes til kontinuerlige forbedringer af softwaren.

En anden vigtig dimension i DevOps er hastigheden. Det grundlæggende mål med DevOps er at skabe en kultur, der fremmer hurtigere og mere pålidelige softwareudgivelser. Denne hastighed kan være en udfordring for testere, som måske kæmper med at finde den rette balance mellem at udforske nye funktioner og samtidig sikre, at udgivelserne ikke hæmmes. Testere i et DevOps-miljø skal derfor være i stand til hurtigt at tilpasse sig nye værktøjer og metoder for at opretholde kvaliteten uden at forsinke udgivelsen.

Automation bliver ofte fremhævet som løsningen på at fremskynde testning. Mens automatisering af tests inden for udviklingsteamet ofte nævnes som den primære metode til at øge hastigheden, kan andre tilgange være lige så effektive. For eksempel kan forbedret overvågning af produktionen og automatiserede deploy- og rollback-mekanismer være lige så afgørende for at sikre hurtigere reaktioner på problemer i produktionsmiljøet.

DevOps blev først præsenteret som et koncept i 2009, og dets primære mål var at bygge bro mellem udviklings- og operationsafdelingerne for at reducere risici i softwareudrulninger. Den oprindelige filosofi om DevOps satte fokus på at fremme samarbejde på tværs af discipliner og skabe tillid både mellem personer og i deres processer og værktøjer. Denne tillid er nødvendig for at opnå hyppigere og pålidelige udgivelser. I praksis betyder det, at udviklere og operationsfolk skal arbejde tættere sammen for at sikre, at softwaren er klar til produktion og kan rulles ud hurtigt og uden frygt for fejl.

I takt med at DevOps bevægelsen er blevet mainstream, især efter udgivelsen af bogen The Phoenix Project i 2013, har flere organisationer implementeret disse principper. DevOps' fokus på kommunikation og samarbejde, automatisering af softwarelevering og infrastrukturændringer samt en kultur, der understøtter hyppige og pålidelige udgivelser, er blevet anerkendt som en nøgle til succes i moderne softwareudvikling.

Det er dog væsentligt at bemærke, at selvom DevOps lover hurtigere og mere pålidelige udgivelser, er det vigtigt at teste kontinuerligt på tværs af udviklingscyklusserne for at undgå fejl, der kun opdages efter en lancering. Testere skal derfor ikke kun fokusere på at holde tempoet oppe, men også sikre, at alle aspekter af softwarekvaliteten bliver adresseret – fra funktionalitet til brugervenlighed og sikkerhed.

Hvordan Definerer Man Risici og Teststrategier i DevOps?

I mange organisationer, der sigter mod hyppigere udgivelser, bliver testning ofte betragtet som en nødvendig, men tidskrævende opgave. Testning forsvinder ikke blot, fordi målet er at udgive oftere. I stedet skal testmetoderne udvikles til at være mere fleksible og hurtige. Det betyder, at testning skal være mere responsiv i et DevOps-miljø, hvor udvikling og operationer arbejder tæt sammen. Den centrale udfordring er at sikre, at testning kan følge med i en hurtigere udviklingscyklus uden at gå på kompromis med kvaliteten.

I et DevOps-miljø er det ikke længere kun udviklingsteamet, der vurderer kvaliteten af produktet. I stedet bliver operationsteamene også en kritisk kilde til feedback. Hvis du kan få hurtig og rig feedback fra operationsteamet, ændrer det fundamentalt de krav, der stilles til testningen før en udgivelse. I sidste ende er det brugeren, der bestemmer, hvad der er kvalitet, og hvad der ikke er det. At lade brugeren teste produktet giver et direkte billede af, hvordan produktet opfattes af den vigtigste interessent. Dette kan være en udfordring for testere, der tidligere har været den "stemme", som repræsenterer brugeren i udviklingsholdet.

Automatisering af testene spiller en væsentlig rolle i denne sammenhæng. Automatiserede pipelines gør det muligt at udføre gentagne tests hurtigt og effektivt, men det er også en investering, både i udvikling og vedligeholdelse. I et miljø, hvor tid til markedet er afgørende, vil det måske ikke være muligt at bruge så meget tid på at skrive forudgående testautomatisering som tidligere. En pragmatisk tilgang til testautomatisering i DevOps betyder, at der skal være nok automatisering til at hjælpe med at træffe beslutningen om at udgive, men ikke så meget, at det hæmmer processen.

Når det kommer til at udvikle en teststrategi i DevOps, er det vigtigt at definere de specifikke risici og udfordringer, som organisationen står overfor. Det er her, risikoarbejdsmøder spiller en vigtig rolle. En risiko-workshop giver mulighed for at afstemme og bekræfte, hvilke risici der skal tages i betragtning, når man tester. En sådan workshop kan hjælpe med at undgå misforståelser om, hvad der er risikoen, og hvilken prioritet disse risici skal have.

Test i DevOps handler ikke kun om at afprøve funktionalitet, men også om at forstå, hvordan organisationens risikovillighed påvirker teststrategien. Hvis organisationen ønsker at frigive software hurtigt og ofte, skal man forstå de risici, som hyppigere udgivelser medfører. Jo oftere der udgives, jo flere muligheder for fejl opstår, selvom disse fejl typisk vil være mindre, når ændringerne er mindre.

En vigtig pointe i denne proces er at måle organisationens risikovillighed. Spørgsmålet er ikke, om fejl kan opstå, men om organisationen er villig til at acceptere, at fejl kan opstå i produktionsmiljøet, så længe de bliver rettet hurtigt. Dette kan give ledelsen en klarere forståelse af, hvor meget testning og risikostyring der er nødvendigt for at sikre en pålidelig udgivelse, samtidig med at man opretholder en høj hastighed i udviklingscyklussen.

I en risiko-workshop kan man udforske organisationens nuværende niveau af testrigor og sammenligne det med, hvad man ønsker i fremtiden. Denne form for refleksion hjælper med at identificere områder, hvor organisationen er villig til at tage større risici, og hvor der stadig er behov for strengere testkrav. Spørgsmål som "Hvor mener du, at produktet aktuelt står i forhold til testniveauet?" og "Hvor ønsker du, at produktet skal være med hensyn til testniveauet?" kan være nyttige i denne proces.

Når risikoen er blevet identificeret, er det tid til at overveje, hvordan disse risici kan håndteres. Risici som funktionalitet, kode-sammenlægning, tvær-browser-kompatibilitet, brugeroplevelse, tilgængelighed, sikkerhed, ydeevne og infrastruktur er nogle af de områder, der skal overvejes. Disse risici skal derefter prioriteres, så teamet ved, hvilke problemer der skal adresseres først. Det er også nyttigt at sammenligne den risikoliste, der skabes i værkstedet, med eksterne kilder, som f.eks. James Bach’s Heuristic Risk-Based Testing, for at sikre, at alle relevante risici er blevet overvejet.

Når du har en prioriteret liste over risici, kan du begynde at udarbejde en plan for, hvordan disse risici kan afbødes. Det er ofte nemt at identificere risici, men det kan være en udfordring at finde de rette løsninger, især når man arbejder med automatisering og hyppige udgivelser. Testning i et DevOps-miljø er ikke længere en isoleret aktivitet, men en integreret del af udviklings- og driftsprocessen, der kræver en løbende evaluering af både risici og testmetoder.

Endtext

Hvordan skal vi forstå og håndtere risici i softwareudvikling og testning?

I enhver softwareudvikling er der uundgåeligt risici, som kan opstå, selv med de bedste intentioner og metoder. Diskussionen om risikohåndtering kan ofte føles som en tung opgave, og mange føler sig utilpasse ved at tage ansvar for at afbøde risici. Det er vigtigt at forstå, at formålet med risikohåndtering ikke er at eliminere alle risici, men at reducere dem til et niveau, der er acceptabelt i forhold til de mål, vi ønsker at opnå. For at illustrere denne forskel kan vi bruge et konkret eksempel. Som leder af et frivilligt Brownie-kursus, hvor vi afholder overnatningslejre, er der en trappe til toiletterne, der er placeret på et lavere niveau. For at afbøde risikoen for, at en af børnene falder på trappen om natten, efterlader vi trappen oplyst. Denne handling fjerner ikke risikoen for et fald, men den reducerer betydeligt sandsynligheden for, at det sker. Risiciene er blevet afbødet, men de er ikke blevet elimineret.

Denne tilgang til risikohåndtering skal overvejes bredt, når vi taler om softwareudvikling. Ikke alle aktiviteter, der kan afbøde risici, handler om testning. Ændringer i kodningspraksis, designworkshops eller produktionsmonitorering kan også være effektive risikohåndteringsmetoder. Et interessant spørgsmål at stille i risikohåndteringsdiskussioner inden for DevOps er: "Hvor sent kan vi gøre dette?" Dette udfordrer idéen om, at risici skal afbødes, før leveringen finder sted, og om de kan adresseres i produktion. Jo flere risici vi udskyder, desto hurtigere kan vi levere, men jo mere risikerer vi også at støde på problemer i produktionen. Det er derfor vigtigt at finde den rette balance for organisationen. Et risikeworkshop kan hjælpe med at skabe en fælles forståelse af, hvilke risici der er til stede, og hvordan vi ønsker at afbøde dem. Resultaterne af en sådan aktivitet kan bidrage til opbygningen af en teststrategi.

I forhold til teststrategier, og specifikt den agile testpyramide, er det vigtigt at forstå, at pyramiden oprindeligt blev udviklet af Mike Cohn i 2009. Pyramiden består af tre lag: Enheder (unit tests), integrationstest og brugergrænsefladetests (UI tests). Testpyramiden opfordrer udviklingsteams til at overveje forholdet mellem automatiserede test på hvert niveau. Der bør være flere enhedstest, da de fokuserer på små, diskrete funktionaliteter, mens der skal være færre UI-tests, som dækker hele systemet. I de senere år har der dog været stigende utilfredshed i testmiljøet med den brede og ukritiske adoption af testpyramiden som grundlag for teststrategien. Det er ikke nødvendigvis den bedste tilgang for alle projekter eller teams. Testpyramiden fungerer måske ikke som den ideelle model for alle situationer, og det er nødvendigt at tage højde for, at ikke alle automatiserede test-suiter følger den samme struktur.

Flere testere har derfor overvejet alternative modeller til testpyramiden. I en artikel foreslår John Ferguson Smart et alternativ, hvor der fokuseres på, om testene er skrevet for at opdage, beskrive eller demonstrere. Richard Bradshaw introducerede et alternativ i 2015 på Midlands Exploratory Workshop on Testing, hvor han også inddrog automatiseringsværktøjer og -færdigheder. Marcel Gehlen har yderligere overvejet, hvordan den oprindelige pyramidemodel kan fortolkes på en mere fleksibel måde, hvor man ikke nødvendigvis behøver at følge de oprindelige lag slavisk. Hans tilgang beholder pyramiden som en visuel og rammesættende enhed, men tillader mere fleksibilitet i, hvordan man anvender den.

I 2017 præsenterede Noah Sussman et alternativ til pyramiden, der kaldes "bug filter"-modellen. Denne model introducerer idéen om, at fejl kan bevæge sig mellem forskellige niveauer og at nogle kan gå ubemærket hen. Sussman argumenterer for, at bugs i et produkt kan opdeles i forskellige størrelser, fra små, enkle fejl, der hurtigt kan identificeres og rettes, til større fejl, der måske ikke bliver opdaget før senere i testforløbet. Denne model giver et nyttigt perspektiv på, hvordan fejl ikke nødvendigvis følger en lineær sti gennem testprocessen. Små fejl, der fanges tidligt i enhedstest, kan vokse til større problemer, hvis de ikke fanges, før de når slutbrugeren eller produktionen.

Tænk på et produkt som en funktion til brugerregistrering. Her kan der være en bug, hvor formularen ikke accepterer et gyldigt telefonnummer, og en anden, der forhindrer brugeren i at gennemføre registreringen. Små fejl, som de første, er lettere at finde og rette, mens større problemer måske først afsløres i slut-til-slut test, som dækker en bredere infrastruktur, herunder eksterne systemer og tjenester. Hvis små fejl ikke bliver opdaget tidligt i enhedstestene, kan de udvikle sig til større problemer senere, hvis de ikke bliver opdaget i integrations- eller UI-testene. Dette er hvor "bug filter"-modellen bliver relevant, da den giver et visuelt billede af, hvordan fejl kan bevæge sig op og ned gennem lagene af testen og blive opdaget på forskellige stadier.

Forskellen mellem en fysisk sorteringsenhed for plastikklodser og en bug-filtermodel ligger i det faktum, at bugs i software ikke er konstante som plastikklodser. En fejl, der starter som en lille fejl i en enhedstest, kan udvikle sig til en større fejl, hvis den ikke bliver håndteret korrekt i et tidligt stadie. Samtidig kan fejl, der ikke er blevet opdaget i de første testlag, opstå senere i produktionen, når nye perspektiver, som brugeren interagerer med systemet, introducerer nye testkrav.

I en DevOps-ramme er det essentielt at forstå, at testautomatisering ikke kun handler om at udvikle software isoleret. Den skal ses i en bredere sammenhæng, der inkluderer driften og driftsaspekterne. Teststrategien skal derfor tage højde for, at automationsmodellen ikke kun skal fokuseres på udviklingsstadierne, men også tage højde for den produktion og de driftskrav, som software vil møde i det virkelige liv.

Hvordan samarbejde på tværs af udviklingsteam kan forbedre softwaretest og support

I en moderne udviklingskultur, især indenfor agile metoder og DevOps, er samarbejde ikke længere begrænset til udviklingsteamet alene. Test og support involverer ofte flere afdelinger, hvilket giver en dybere forståelse af, hvordan software fungerer i produktion og hvordan eventuelle problemer kan løses. En række praktikker som peer review, debrief, pararbejde og jobrotation spiller en vigtig rolle i at fremme dette samarbejde og forbedre både produktivitet og kvalitet.

Peer review og debrief

Peer review og debrief er to begreber, der ofte bruges i testkontekster, men de adskiller sig i deres anvendelse. Peer review finder sted før en aktivitet, hvor man får feedback på idéer, planer eller testscripts, mens debrief finder sted efter testen for at evaluere resultaterne og drøfte, hvad der kunne være forbedret. Begge praksisser er hyppigt anvendt i agile teams, men i en DevOps-kultur bliver flere aktører involveret, hvilket giver mulighed for at indhente perspektiver fra folk, der arbejder med drift, analyse eller support.

At inkludere personer fra disse teams i peer review og debriefing kan tilbyde nye synspunkter på, hvordan softwaren fungerer under virkelige driftsbetingelser. For eksempel kan en medarbejder fra driftsteamet komme med værdifuld feedback om, hvordan en ny funktion vil påvirke systemets ydeevne, mens en supportmedarbejder kan påpege områder, hvor brugere ofte støder på problemer.

Det er vigtigt at understrege, at disse aktiviteter ikke nødvendigvis behøver at være tidskrævende. De kan være kortvarige, tid-boksede sessioner, hvor deltagerne på skift præsenterer deres arbejde og diskuterer eventuelle mangler eller områder, der kræver mere opmærksomhed. Det handler om at skabe et åbent forum for deling af viden, uden at det bliver en byrde for teamet.

Pararbejde

Pararbejde er en praksis, hvor to personer arbejder sammen om den samme opgave, samtidig og på samme sted, og kontinuerligt deler idéer og perspektiver. I udviklingsteam er det almindeligt at bruge pararbejde for at fremme kreativitet, problemløsning og fokus. Når to personer arbejder tæt sammen, opstår der en form for kreativ synergi, hvor de kan udfordre hinandens tanker og hurtigt finde løsninger på problemer. Pararbejde tvinger også deltagerne til at kommunikere konstant, hvilket øger forståelsen for både opgaven og, ikke mindst, hvorfor opgaven udføres på en bestemt måde.

Selvom pararbejde traditionelt er et værktøj indenfor agile udviklingsteams, kan det også anvendes på tværs af teams. For eksempel kan en udvikler, der arbejder på at ændre en workflow i et produkt, samarbejde med en supportmedarbejder for at teste, hvordan ændringerne påvirker logningen af data. Eller en udvikler kan samarbejde med en driftsekspert for at teste, hvordan en ny funktion påvirker systemets ydeevne under høj belastning.

Hvis pararbejde er nyt for deltagerne, kan det være nyttigt at følge en struktureret tilgang for at sikre, at alle får noget ud af sessionen. Et eksempel på en struktur kunne være at dele en time op i 10 minutters diskussion om kontekst og mål, 20 minutters session, hvor den ene person kører sessionen, mens den anden giver input, og derefter 20 minutters testning med den anden deltager i "kører"-rollen. Den sidste del af sessionen bruges til debriefing og evaluering.

Jobrotation

En anden praksis, der fremmer samarbejde mellem udvikling og support, er jobrotation. Nogle organisationer implementerer rotationsprogrammer, hvor udviklere i en kort periode arbejder i supportteamet for at få et førstehåndsindtryk af, hvordan deres produkt bruges, hvilke problemer brugerne støder på, og hvordan disse problemer kan diagnosticeres og løses. Dette kan skabe en dybere forståelse for brugerens behov og give udviklerne mulighed for at se, hvordan deres kode fungerer i den virkelige verden.

Virksomheder som Automattic, der står bag WordPress, og Etsy har implementeret succesfulde rotationsprogrammer, der giver medarbejdere fra alle afdelinger mulighed for at deltage i supportarbejde. Dette fremmer ikke kun bedre samarbejde mellem teams, men bygger også empati og giver værdifuld indsigt i, hvordan brugerne interagerer med produktet.

At rotere udviklerne gennem supportpositioner, eller at lade supportmedarbejdere deltage i udviklingsarbejdet, kan føre til et mere sammenhængende team og et produkt, der er bedre til at imødekomme både brugernes og systemets behov. Denne praksis hjælper med at bryde ned barrierer mellem afdelinger og fremmer en fælles forståelse af, hvad der er vigtigt for både udvikling og drift.

I sidste ende er det afgørende, at samarbejde på tværs af udviklings-, support- og driftsteams ikke kun ses som en nødvendighed, men som en mulighed for at forbedre både produktiviteten og kvaliteten af det endelige produkt. Ved at inkludere flere perspektiver i de forskellige faser af udvikling og test kan man sikre, at løsninger er både funktionelle og i stand til at levere værdi under de virkelige forhold, de vil blive brugt i.

Jak vytvořit šperky z drátu: techniky a tipy pro originální náušnice ze stříbra a skla
Jak rozpoznat a pochopit složité rodinné vztahy a mezilidské napětí
Jak upravit expozici a kontrast ve fotografiích pomocí Photoshopu