Lederskab i test: Test som et team

I de senere år er ansvaret for test blevet mere distribueret. I stedet for at dedikerede teams ejer testen opfordrer teams nu brugere, analytikere, udviklere og testere til at omfordele ansvaret for test for at understøtte et bedre samarbejde. Derfor flyttes nogle testaktiviteter og noget testansvar til et tidligere tidspunkt.

I denne artikel gennemgår jeg:

• Tidligere testning
• Test som aktivitet, ikke som rolle
• En ny rolle
• Agile testinterventioner
• Relationer til udviklere
• Udfordringer ved distribuerede og outsourcede teams

Introduktion til tidligere testning

Tidligere testning, eller forskydning til venstre, kan henvise til flere forskellige scenarier. Det kan betyde, at udviklere påtager sig mere ejerskab og ansvar for deres egen test. Det kan også betyde, at testere involveres tidligere i projektet, udfordrer krav og giver eksempler videre til udviklere gennem en proces med adfærdsdrevet udvikling (BDD). 

Nogle gange kan det betyde, at der slet ikke er nogen testere (dun-dun-duuu), og at forretningsanalytikere og udviklere påtager sig det fulde ansvar for testen.

Tidligere testning er ikke nyt – fortalere for test har i mange år prædiket mantraet "test tidligt, test ofte". Helt tilbage i 1993 blev det foreslået, at alle artefakter i en trinvist opbygget proces – både dokumentation og software – kunne (og ofte burde) testes.

Tidligere testning handler primært om at bringe tankegangen omkring test ind tidligere i processen.

Selvom vandfaldsmodellen var den dominerende livscyklustilgang på det tidspunkt, er antallet af trin eller deres varighed ikke det vigtige. Det underliggende princip var, at de videnskilder, der giver retning for design og udvikling af software, skulle udfordres eller testes. 

I et trinvist projekt kan dette indebære formelle gennemgange. I et agilt projekt kan testeren (eller udvikleren, forretningsanalytikeren eller brugeren) foreslå scenarier, der udfordrer forfatteren af et krav eller en historie til at tænke konkrete eksempler igennem og drøfte dem, før der skrives kode.

Dette er de vigtigste ændringer, der er forbundet med fænomenet tidligere testning:

1. Tilgangen med adfærdsdrevet udvikling (BDD) har gjort det muligt for udviklere, brugere/forretningsanalytikere og testere at samarbejde om det, der kan kaldes forretningshistorier. Testdrevet udvikling er blevet brugt af mange udviklere i 15 år eller mere. I dag anvendes BDD bredere, fordi det fremmer et bedre samarbejde i agile teams og samtidig introducerer BDD-værktøjer, som kan bruges af udviklere. Det er en lettere tilgang, hvor test kommer først.
2. Kontinuerlig levering (CD) har eksisteret i 5-10 år, og dens rødder findes i de stærkt automatiserede tilgange til automatisering af bygning og udgivelse, som blev udviklet af store onlinevirksomheder. Den er nu taget i brug af de fleste organisationer med en online tilstedeværelse.
3. CD systematiserede og fremskyndede udgivelsesprocessen gennem automatisering. Men det fremhævede også forsinkelserne i produktion, implementering og ændringer af infrastrukturen, som tidligere var blevet skjult af langsomme processer for bygning, test og udgivelse. DevOps er en kulturel ændring af tankegangen, hvor udviklere samarbejder langt tættere med driftspersonale. Lige nu dukker der næsten dagligt nye værktøjer op, og leverandører promoverer DevOps som "den næste store ting". Det er en meget hypet og dynamisk situation.
4. SMAC, eller sociale medier, mobil, analyse og skyen, repræsenterer en ændring i den måde, organisationer håndterer ændringer i forretning og systemer på i den mobile verden. Eksperimenter i forretningen, der implementeres som ændringer i produktionssystemer, overvåges på et detaljeret niveau. De indsamlede "Big Data" behandles, og forretningsbeslutninger træffes på baggrund af de opnåede analyser.

Hyppige eksperimenter med produktionssystemer muliggør forretningsinnovation "i markedsføringens tempo". Eksperimenter er kernen i det, der var det vigtigste modefænomen i 2010'erne – digital transformation.

Test som aktivitet, ikke som rolle

Tidligere testning ændrer testerens rolle. Omfordelingen af test, som tilgangen med tidligere testning har udløst, gør det klart, at testere ikke alene er ansvarlige for test, dvs. testere ejer ikke længere testen. 

Hvis man tænker over det, ejede de faktisk aldrig testningen helt, men der var en stiltiende forståelse i projekter af, at uanset hvad resten af teamet, især udviklerne, gjorde inden for testning, fungerede testerne som et sikkerhedsnet. Hvis udviklerne var pressede på tid og reducerede deres testning for at kunne levere, blev sikkerhedsnettet leveret af testerne.

Testning er nu en aktivitet, ikke en rolle.

Udviklere tager bedre testpraksisser og større synlighed i deres arbejde til sig. God komponenttestning eller enhedstestning har specifikke mål, der adskiller sig fra systemtestning (for eksempel). Derfor kan omfanget (eller mængden) af testning på systemniveau reduceres. 

Den korrekte fordeling af testmål og testning for at opfylde disse mål er det primære formål med teststrategien. Desværre blev udviklerne indtil for nylig ikke holdt effektivt ansvarlige, så de var afhængige af sen systemtestning som kompensation.

Testning tidligt i processen gør udviklerne mere ansvarlige.

Samlet set omfordeles ansvaret for testning, så testerens rolle ændrer sig. Testere udfører måske mindre taktisk testning, men deres strategiske bidrag bliver større. Testere ejer måske teststrategien, udfordrer krav, rådgiver interessenter og opbygger et tættere forhold til udviklerne for at understøtte bedre udviklertestning og testautomatisering.

En ny rolle

Testning tidligt i processen indebærer, at når det er muligt at give feedback, som hjælper teamet med at forstå, udfordre og forbedre mål, krav, design eller implementering – så skal denne feedback gives. 

Brugere, BA'er, udviklere og hele softwareteamet bør være klar til at udveksle feedback på denne måde. Nogle gange er der modstand, men det overordnede mål er at gennemføre et bedre og mere velinformeret projekt—det er alt.

Den nemmeste måde at opsummere denne adfærd på er: 'involver dig tidligt'—så tidligt som muligt. Deltag i diskussionen, og samarbejd om idéer, krav og på hvert trin, hvor resultatet af det pågældende trin har betydning for værdien af projektets endelige leverance. 

Sagt enkelt udfordrer testeren videnskilder, uanset om disse kilder er interessenter, brugere, udviklere, forretningshistorier, dokumenter eller fortilfælde.

Den mest almindelige tilgang er at udfordre gennem eksempler. På alle trin kan disse eksempler betragtes som test. De kan hurtigt kasseres efter brug eller omsættes til testautomatisering eller manuelle kontroller. Disse eksempler kan blot bruges taktisk til at påpege fejl i folks tankegang eller gives til udviklerne som eksempelvis idéer eller udgangspunkter for udviklertest. De kan også bruges som hjælpemidler i coaching for at vise brugere eller udviklere, hvordan der kan oprettes bedre test.

Betragt dit softwareprojekt som en proces til indhentning af viden. Denne viden indsamles gennem hele projektet og udvikler sig ofte over tid. Målet med testning tidligt i processen er at sikre denne viden gennem udfordring og testning tæt på dens kilde og så vidt muligt sikre, at der er tillid til den, før den fastlåses i kode.

Testning tidligt i processen viderefører test-først-filosofien. Agile metoder har altid fremmet samarbejde og hurtig feedback—testning tidligt i processen kan ses som en målrettet tilgang med hurtig feedback. Hvis dit team anvender en tilgang med testning tidligt i processen, kan de rigtige værktøjer gøre hele forskellen. Se vores kuraterede liste over værktøjer til softwaretest for at finde det bedste match til dit team.

Agile testinterventioner

Tilgangen med testning tidligt i processen er grundlæggende for en teststrategi i agile projekter. I en agil sammenhæng kan teststrategi ses som en række testinterventioner. I alle projekter er der kritiske tidspunkter, hvor der opstår muligheder for at indsamle og give feedback. Testeren skal fokusere på disse kritiske tidspunkter og være klar til at bidrage på disse tidspunkter.

I dine egne projekter skal du identificere kritiske tidspunkter, hvor intervention er mulig, og identificere de valg, du kan træffe, når I tester som team. Skal testeren for eksempel skrive enhedstest for udviklerne, give eksempler for at hjælpe dem i gang eller coache dem for at forbedre deres testevner? Kun du og dit nye softwaretestteam kan beslutte dette.

Vi bruger en typisk Scrum-proces til at demonstrere, hvordan testinterventioner kan placeres i Scrum-tilgangen. Interventioner finder enten sted på projekt- (eller udgivelses-)niveau eller på sprintniveau. Diagrammet nedenfor viser et overblik på projektniveau og de fem vigtigste interventioner.

Udfordring af brugerhistorier og definition af brugerhistorier er de steder, hvor testeren henholdsvis validerer en brugerhistorie og de foreslåede acceptkriterier for en brugerhistorie. Integrationstest kontrollerer, at nye funktioner forbindes korrekt med andre funktioner og med systemet som helhed. Systemtest og bruger- (acceptans-)test udføres efter behov.

Et projekt har normalt flere sprints, og de fire sprintinterventioner vises i diagrammet nedenfor. Det daglige standupmøde er en mulighed for at rapportere fremdrift, rejse bekymringer, identificere risici eller drøfte spørgsmål, der er rejst, og svar, der er modtaget under sprintet. 

Forfinelse af brugerhistorier og bidrag til udviklertestning er daglige aktiviteter, der foregår som en del af diskussioner med brugere, analytikere og udviklere. Testeren indarbejder udviklernes test og nye systemtest i en voksende samling af test, der skal automatiseres.

I tabellen nedenfor kan du se en tabeloversigt over testernes interventioner. Din proces kan være anderledes eller baseret på Scrum med variationer, men tabellen identificerer typiske interventionstyper i en typisk Scrum-proces. Du har måske flere eller færre aktive interventioner på forskellige tidspunkter i din egen unikke proces.

Jeg foreslår, at du identificerer de kritiske øjeblikke, fremlægger dit bidrag og forhandler med dit team. Du tilbyder mere testledelse og vejledning i stedet for blot frivilligt at påtage dig ansvaret for testarbejdet. Denne tilgang gør det meget lettere at demonstrere din værdi for teamet, men teamet har måske ikke brug for lige så mange testere.

Forholdet til udviklerne

I nogle organisationer kan forholdet mellem udviklerne være præget af mistillid, skyldplacering og konflikt. I værste fald er forholdet giftigt: Udviklerne tester næsten ikke, og testere betragtes som udviklernes tjenere. Testere indtager adfærd, der kan kaldes medafhængig, og opfører sig som ofre. Denne situation er præcis det, som shift-left-tilgangen forsøger at undgå.

Der findes mange metaforer, som er blevet brugt til at beskrive et godt forhold mellem udviklere og testere. Vi vil bruge en arbejdsform med pilot og navigatør til at illustrere, hvordan det tilsvarende forhold mellem udvikler og tester kan fungere. Men først skal vi se på en dysfunktionel situation.

Navigatøren går ikke om bord på flyet, men vinker til piloten, da denne letter. Navigatøren rejser med bus, separat men langsomt. Til sidst når navigatøren frem til destinationen, men efter nogen tid viser det sig, at flyet er fløjet i den forkerte retning og er styrtet ind i et bjerg.

Navigatøren burde vel have været med på flyet? Forestil dig, hvordan piloter og navigatører arbejder sammen i virkeligheden.

• Piloten kan ikke flyve flyet uden en navigatør. Navigatøren kan ikke flyve flyet.
• Piloten og navigatøren bliver enige om flyveplanen, før rejsen begynder.
• Piloten letter og flyver flyet.
• Navigatøren følger kursen og sammenligner den med flyveplanen og/eller den endelige destination under hensyntagen til ugunstige hændelser, især vejret.
• Navigatøren leder efter afvigelser, udstikker en ny kurs og underretter piloten, som foretager justeringer af flyveruten.
• Og så videre.

Forholdet mellem pilot og navigatør kan sammenlignes med forholdet mellem programmør og tester. Det giver heller ikke mening at opdele udviklere og testere i separate teams, der arbejder sekventielt. Alligevel er det konventionelt sådan, vi har arbejdet i de seneste cirka tredive år – især i større, langsigtede projekter.

Shift-left omfordeler tænkningen omkring test og bringer den reelt frem i processen. Testere fungerer som fuldgyldige partnere for udviklerne, ligesom navigatører gør for piloter:

• Testeren og udvikleren indsamler i fællesskab oplysninger om kravene.
• Typisk udfordrer testeren kravene gennem eksempler (mulige eller faktiske testidéer).
• Udvikleren tænker over implementeringen og bruger eksemplerne til at give retning for designet.
• Testeren, udvikleren, interessenterne, brugerne og analytikerne bliver enige om en fælles forståelse af et pålideligt krav.
• Testeren er i konstant kommunikation med udvikleren og drøfter ændringer i kravene, risikoen for fejl, og hvordan test kan vise, at funktioner fungerer, eller afsløre fejl.
• Testeren ser på, hvordan den funktion, der arbejdes på, integreres både på et teknisk niveau og på et brugerrejse-niveau, samt hvordan integrationen kan testes.
• Testeren ser ud over den umiddelbare funktion, som udvikleren arbejder på, for at identificere fremtidige udfordringer, risici, ændringer og usikkerheder.
• Og så videre.

Det beskrevne ideelle forhold mellem udvikler og tester opstår ikke automatisk. Det skal etableres af teamet. Du kan betragte hver af de ovenstående aktiviteter som interventioner, men interventioner er ikke altid behagelige for alle parter. Giv denne tilgang de bedste muligheder for at lykkes ved at drøfte hver interventionstype med dine samarbejdspartnere helt fra begyndelsen – når du først ved, at I skal arbejde tæt sammen.

Interventioner er ligesom gode brugerhistorier udløsere for samtaler.

Hver interventionstype kræver samtykke fra begge sider til, at det er noget, der er gyldigt at gøre. For at føle sig tryg skal hver part have tillid til den anden og tro på, at der er en god grund til at stille spørgsmål, rejse problemstillinger og udfordre krav eller forståelse på daglige statusmøder, planlægningssessioner eller retrospektiver.

Udfordringer ved distribuerede og outsourcede teams

I drøftelserne ovenfor er det stiltiende blevet antaget, at alle arbejder i det samme team og er placeret samme sted. Når softwaretestteamets arbejdsbyrde outsources og/eller flyttes til udlandet, kommer flere negative faktorer i spil. Tabellen viser tre typiske faktorer, der bør tages i betragtning.

Nogle virksomheder udvider eksisterende softwaretestteams for at opbygge kapacitet til større projekter eller hyrer specialiserede testvirksomheder i stedet for at være afhængige af kontraktansatte eller interne brugere til test. I andre situationer kan al udvikling og/eller test overdrages til leverandører. I alle tilfælde skal kundevirksomheden styre sine leverandører. Det betyder ikke, at det er tilstrækkeligt at skrive en restriktiv kontrakt med strenge sanktionsklausuler.

Når tingene går galt, ønsker du hurtige svar og samarbejde fra din leverandør; du ønsker ikke, at de gemmer sig bag juridiske klausuler i kontrakter.

Hemmelighederne bag succes er:

• Hvis du ikke styrer din leverandør, vil de styre dig (hvis I ikke er fuldgyldige partnere og lader leverandøren fastsætte vilkårene, vil leverandøren sidde med alle kortene).
• Målet er at definere et godt arbejdsforhold. Dette skal etableres på alle niveauer – hos interessenter, ledere såvel som praktikere.
• Kontrakter bør formuleres, så alle ansvarsområder på begge sider identificeres, og så passende målepunkter, tærskler, ratebetalinger og acceptkriterier defineres for at fremme god adfærd (på begge sider af aftalen).
• Aftaler bør fremme åbenhed og opbakning til det fælles mål om, at projektet lykkes.

Stof til eftertanke

Og til sidst nogle spørgsmål, der kan få dig til at tænke. 

Hvilket forhold har du som tester til dine udviklere? Eller hvis du er udvikler og læser dette, hvilket forhold har du så til testere? Måske kan du spørge dine samarbejdspartnere inden for udvikling eller test, hvordan de ville beskrive jeres forhold. Sammenlign jeres svar!

For at softwaretestteams kan være produktive, skal de kommunikere og samarbejde.