Lederskap i testing: Testing som team

De siste årene har ansvaret for testing blitt mer fordelt. I stedet for at dedikerte team har ansvaret for testingen, oppmuntrer team nå brukere, analytikere, utviklere og testere til å fordele testansvaret på nytt for å støtte bedre samarbeid. Derfor blir enkelte testaktiviteter og ansvarsområder flyttet til et tidligere tidspunkt.

I denne artikkelen skal jeg ta for meg:

• Flytt testing til et tidligere tidspunkt
• Testing som en aktivitet, ikke en rolle
• En ny rolle
• Smidige testinngrep
• Forholdet til utviklere
• Utfordringer med distribuerte og utkontrakterte team

Introduksjon til å flytte testing til et tidligere tidspunkt

Å flytte testing til et tidligere tidspunkt, eller venstreforskyvning, kan vise til flere ulike scenarioer. Det kan bety at utviklere tar mer eierskap til og ansvar for sin egen testing. Det kan også bety at testere involveres tidligere i prosjektet, utfordrer krav og gir utviklerne eksempler gjennom en prosess for atferdsdrevet utvikling (BDD). 

Noen ganger kan det bety at det ikke finnes testere i det hele tatt (dun-dun-duuu), og at forretningsanalytikere og utviklere tar fullt ansvar for testingen.

Å flytte testing til et tidligere tidspunkt er ikke noe nytt – forkjempere for testing har i mange år forkynt mantraet «test tidlig, test ofte». Allerede i 1993 ble det foreslått at alle artefakter i en trinnvis prosess – både dokumenter og programvare – kunne (og ofte burde) testes.

Å flytte testing til et tidligere tidspunkt handler først og fremst om å bringe tankegangen rundt testing tidligere inn i prosessen.

Selv om fossefallsmodellen var den dominerende livssyklustilnærmingen på den tiden, er det ikke antallet eller varigheten på trinnene som er viktig. Det underliggende prinsippet var at kildene til kunnskap som gir retning for utformingen og utviklingen av programvare, bør utfordres eller testes. 

I et trinnvis prosjekt kan dette innebære formelle gjennomganger. I et smidig prosjekt kan testeren (eller utvikleren, forretningsanalytikeren eller brukeren) foreslå scenarioer som utfordrer forfatteren av et krav eller en brukerhistorie til å tenke gjennom konkrete eksempler og diskutere dem før det skrives kode.

Dette er de viktigste endringene som er knyttet til fenomenet med å flytte testing til et tidligere tidspunkt:

1. Tilnærmingen atferdsdrevet utvikling (BDD) har gjort det mulig for utviklere, brukere/forretningsanalytikere og testere å samarbeide om det som kan kalles forretningshistorier. Testdrevet utvikling har blitt brukt av mange utviklere i 15 år eller mer. I dag tas BDD i bruk bredere fordi det fremmer bedre samarbeid i smidige team, samtidig som det introduserer BDD-verktøy som kan brukes av utviklere. Det er en enklere test-først-tilnærming.
2. Kontinuerlig levering (CD) har eksistert i 5–10 år, og røttene finnes i de svært automatiserte tilnærmingene til bygging og lansering som ble utviklet av store nettbaserte virksomheter. Den er nå tatt i bruk av de fleste organisasjoner med en tilstedeværelse på nettet.
3. CD systematiserte og fremskyndet lanseringsprosessen gjennom automatisering. Men den synliggjorde også forsinkelsene i produksjon, distribusjon og endringer i infrastrukturen som tidligere hadde vært skjult av langsomme prosesser for bygging, testing og lansering. DevOps er en kulturell endring i tankesett der utviklere samarbeider langt tettere med driftspersonell. Akkurat nå dukker det opp nye verktøy nesten daglig, og leverandører markedsfører DevOps som «det neste store». Det er en svært hypet og dynamisk situasjon.
4. SMAC, eller sosiale medier, mobil, analyse og sky, representerer en endring i måten organisasjoner håndterer forretnings- og systemendringer på i den mobile verdenen. Eksperimentering i virksomheten, implementert som endringer i produksjonssystemer, overvåkes på et detaljert nivå. De «store» datamengdene som samles inn, behandles, og forretningsbeslutninger tas basert på analysene som innhentes.

Hyppig eksperimentering med produksjonssystemer muliggjør innovasjon i virksomheten «i markedsføringens tempo». Eksperimentering står sentralt i det som var det viktigste fenomenet på 2010-tallet – digital transformasjon.

Testing som en aktivitet, ikke en rolle

Å flytte testing til et tidligere tidspunkt endrer testerens rolle. Omfordelingen av testing som følger av denne tilnærmingen, tydeliggjør at testere ikke alene har ansvaret for testing, det vil si at testere ikke lenger eier testingen. 

Hvis man tenker over det, hadde de egentlig aldri eneansvar for testingen, men det fantes en stilltiende forståelse i prosjekter om at uansett hva resten av teamet, særlig utviklerne, gjorde av testing, fungerte testerne som et sikkerhetsnett. Hvis utviklerne fikk dårlig tid og reduserte testingen for å kunne levere, var det testerne som utgjorde sikkerhetsnettet.

Testing er nå en aktivitet, ikke en rolle.

Utviklere tar i bruk bedre testpraksis og får bedre innsikt i arbeidet sitt. God komponenttesting eller enhetstesting har spesifikke mål som skiller seg fra systemtesting (som et eksempel). Derfor kan omfanget (eller mengden) systemtesting reduseres. 

Den riktige fordelingen av testmål, og testing for å oppfylle disse målene, er hovedformålet med teststrategien. Dessverre ble utviklerne inntil nylig ikke holdt effektivt ansvarlige, så de var avhengige av sen systemtesting for å kompensere.

Testing tidligere i prosessen gjør utviklerne mer ansvarlige.

Samlet sett omfordeles ansvaret for testing, slik at testernes rolle endres. Testere kan utføre mindre taktisk testing, men deres strategiske bidrag øker. Testere kan ha ansvaret for teststrategien, utfordre krav, rådføre seg med interessenter og etablere et tettere forhold til utviklerne for å støtte bedre testing utført av utviklerne og testautomatisering.

En ny rolle

Testing tidligere i prosessen innebærer at når det er mulig å gi tilbakemeldinger som hjelper teamet med å forstå, utfordre og forbedre mål, krav, design eller implementasjon – skal disse tilbakemeldingene gis. 

Brukere, BA-er, utviklere og hele programvareteamet bør være klare til å utveksle tilbakemeldinger på denne måten. Noen ganger finnes det motstand, men det overordnede målet er å gjennomføre et bedre og mer informert prosjekt – det er alt.

Den enkleste måten å oppsummere denne atferden på er «bli involvert tidlig»—så tidlig som mulig. Delta i diskusjonen og samarbeid om ideer, krav og på hvert trinn der resultatet av trinnet påvirker verdien av prosjektets endelige leveranse. 

Enkelt sagt utfordrer testeren kunnskapskilder, enten disse kildene er interessenter, brukere, utviklere, forretningshistorier, dokumenter eller presedenser.

Den vanligste tilnærmingen er å utfordre gjennom eksempler. På alle stadier kan disse eksemplene betraktes som tester. De kan forkastes raskt etter bruk eller innarbeides i testautomatisering eller manuelle kontroller. Eksemplene kan ganske enkelt brukes taktisk for å påpeke svakheter i folks tankegang, eller gis til utviklere, for eksempel som ideer eller utgangspunkt for utviklertester. De kan også brukes som hjelpemidler i opplæring for å vise brukere eller utviklere hvordan bedre tester kan utformes.

Tenk på programvareprosjektet ditt som en prosess for å tilegne seg kunnskap. Denne kunnskapen samles inn gjennom hele prosjektet og utvikler seg ofte over tid. Målet med testing tidligere i prosessen er å kvalitetssikre denne kunnskapen gjennom utfordring og testing nær kilden, og å sørge for at den så langt som mulig er pålitelig før den fryses inn i kode.

Testing tidligere i prosessen tar test-først-filosofien videre. Smidig utvikling har alltid fremmet samarbeid og raske tilbakemeldinger—testing tidligere i prosessen kan ses på som en målrettet tilnærming med raske tilbakemeldinger. Hvis teamet ditt tar i bruk en tilnærming med testing tidligere i prosessen, kan de riktige verktøyene utgjøre hele forskjellen. Se vår kuraterte liste over verktøy for programvaretesting for å finne det som passer best for teamet ditt.

Testinngrep i smidig utvikling

Tilnærmingen med testing tidligere i prosessen er grunnleggende for en teststrategi i smidige prosjekter. I en smidig kontekst kan teststrategien ses på som en serie med testinngrep. I alle prosjekter finnes det kritiske øyeblikk der det oppstår muligheter til å samle inn og gi tilbakemeldinger. Testeren må fokusere på disse kritiske øyeblikkene og være klar til å bidra på disse tidspunktene.

I dine egne prosjekter må du identifisere kritiske øyeblikk der inngrep er mulig, og identifisere valgene du kan ta når dere tester som et team. Bør testeren for eksempel skrive enhetstester for utviklerne, gi dem eksempler for å komme i gang eller veilede dem for å forbedre testevnene deres? Bare du og ditt nye programvaretestingsteam kan avgjøre dette.

Vi bruker en typisk Scrum-prosess for å demonstrere hvordan testinngrep kan plasseres i Scrum-tilnærmingen. Inngrep skjer enten på prosjekt- (eller leveranse-)nivå eller på nivået til en sprint. Diagrammet nedenfor viser en visning på prosjektnivå og de fem viktigste inngrepene.

Utfordring av brukerhistorier og definisjon av brukerhistorier er der testeren henholdsvis validerer en brukerhistorie og de foreslåtte akseptansekriteriene for en brukerhistorie. Integrasjonstester kontrollerer at nye funksjoner kobles riktig til andre funksjoner og til systemet som helhet. System- og brukerakseptansetester gjennomføres etter behov.

Et prosjekt har vanligvis flere sprinter, og de fire sprintinngrepene vises i diagrammet nedenfor. Det daglige statusmøtet er en mulighet til å rapportere fremdrift, ta opp bekymringer, identifisere risikoer eller diskutere spørsmål som er reist og svar som er mottatt under sprinten. 

Forbedring av brukerhistorier og bidrag til utviklertesting er daglige aktiviteter som skjer som en del av diskusjoner med brukere, analytikere og utviklere. Testeren innarbeider utviklertester og nye systemtester i en voksende samling tester som skal automatiseres.

I tabellen nedenfor kan du se en tabellarisk oppsummering av testernes involvering. Prosessen din kan være annerledes eller basert på Scrum med variasjoner, men tabellen identifiserer typiske typer involvering i en typisk Scrum-prosess. Du kan ha flere eller færre aktive involveringer på ulike tidspunkter i din egen unike prosess.

Jeg foreslår at du identifiserer de kritiske øyeblikkene, foreslår ditt bidrag og forhandler med teamet ditt. Du tilbyr mer testledelse og veiledning i stedet for å melde deg frivillig til å ta ansvar for testarbeidet. Denne tilnærmingen gjør det mye enklere å demonstrere verdien din for teamet, men teamet trenger kanskje ikke like mange testere.

Forholdet til utviklerne

I noen organisasjoner kan forholdet mellom utviklere være preget av mistillit, skyldfordeling og konflikter. På sitt verste er forholdet giftig: Utviklerne tester nesten ikke i det hele tatt, og testere blir betraktet som utviklernes tjenere. Testere utvikler det som kan kalles medavhengig atferd og opptrer som ofre. Denne situasjonen er nettopp det tilnærmingen med å flytte testingen frem i prosessen forsøker å unngå.

Det finnes mange metaforer som har blitt brukt til å beskrive et godt forhold mellom utvikler og tester. Vi bruker en arbeidsform med pilot og navigatør for å illustrere hvordan det tilsvarende forholdet mellom utvikler og tester kan fungere. Men først skal vi se på en dysfunksjonell situasjon.

Navigatøren går ikke om bord i flyet, men vinker til piloten når de tar av. Navigatøren reiser med buss, separat, men sakte. Til slutt ankommer navigatøren reisemålet, men etter en stund viser det seg at flyet har fløyet i feil retning og krasjet inn i et fjell.

Burde ikke navigatøren ha vært om bord i flyet? Tenk på hvordan piloter og navigatører faktisk arbeider sammen.

• Piloten kan ikke fly flyet uten en navigatør. Navigatøren kan ikke fly flyet.
• Piloten og navigatøren blir enige om flyplanen før reisen begynner.
• Piloten tar av og flyr flyet.
• Navigatøren følger kursen og sammenligner den med flyplanen og/eller det endelige reisemålet, samtidig som det tas hensyn til ugunstige hendelser, særlig været.
• Navigatøren ser etter avvik, legger opp en ny kurs og varsler piloten, som foretar justeringer av flyruten.
• Og så videre.

Forholdet mellom pilot og navigatør kan sammenlignes med forholdet mellom programmerer og tester. Det gir heller ingen mening å dele utviklerne og testerne inn i separate team som arbeider sekvensielt. Likevel er det dette vi tradisjonelt har gjort de siste tretti årene eller så – særlig i større, langsiktige prosjekter.

Tilnærmingen med å flytte testingen frem i prosessen omfordeler tenkningen rundt testing og flytter den i praksis frem i prosessen. Testere fungerer som fullverdige partnere for utviklerne, på samme måte som navigatører gjør for piloter:

• Testeren og utvikleren samler inn informasjon om kravene sammen.
• Testeren utfordrer vanligvis kravene gjennom eksempler (mulige eller faktiske testideer).
• Utvikleren tenker på implementeringen og bruker eksempler til å gi retning for utformingen.
• Testeren, utvikleren, interessentene, brukerne og analytikerne blir enige om en felles forståelse av et pålitelig krav.
• Testeren kommuniserer kontinuerlig med utvikleren og diskuterer endringer i kravene, risikoen for feil og hvordan testing kan vise at funksjoner fungerer eller avdekke feil.
• Testeren ser på hvordan funksjonen det arbeides med, skal integreres både på et teknisk nivå og på brukerreisenivå, og hvordan integrasjonen kan testes.
• Testeren ser utover den umiddelbare funksjonen utvikleren arbeider med, for å identifisere fremtidige utfordringer, risikoer, endringer og usikkerheter.
• Og så videre.

Forholdet mellom utvikler og tester i en idealverden oppstår ikke automatisk. Det må utarbeides av teamet. Du kan se på hver av aktivitetene ovenfor som involveringer, men involveringer er ikke alltid komfortable for alle parter. Gi denne tilnærmingen best mulig sjanse til å lykkes ved å diskutere hver type involvering med samarbeidspartnerne dine helt i begynnelsen – når du først vet at dere skal arbeide tett sammen.

Involveringer, i likhet med gode brukerhistorier, er utgangspunkt for samtaler.

Hver type involvering krever samtykke fra begge sider om at det er riktig å gjøre dette. For å føle seg komfortabel må hver part stole på at den andre har en god grunn til å stille spørsmål, ta opp problemer og utfordre krav eller forståelse i daglige møter, planleggingsmøter eller retrospektiver.

Utfordringer med distribuerte og utkontrakterte team

I diskusjonene ovenfor har det underforstått vært lagt til grunn at alle arbeider i samme team og befinner seg på samme sted. Når arbeidsbelastningen i programvaretesting settes ut og/eller flyttes til andre land, spiller flere negative faktorer inn. Tabellen viser tre typiske faktorer det bør tas hensyn til.

Noen selskaper utvider eksisterende programvaretestingsteam for å bygge opp kapasitet til større prosjekter, eller leier inn spesialiserte testselskaper i stedet for å basere seg på oppdragstakere eller interne brukere til testingen. I andre situasjoner kan all utvikling og/eller testing overlates til leverandører. I alle tilfeller må kundeselskapet administrere leverandørene sine. Det betyr ikke at det er tilstrekkelig å skrive en restriktiv kontrakt med strenge sanksjonsklausuler.

Når ting går galt, ønsker du raske svar og samarbeid fra leverandøren din; du ønsker ikke at de skal gjemme seg bak juridiske klausuler i kontraktene.

Hemmelighetene bak suksess er:

• Hvis du ikke styrer leverandøren din, vil de styre deg (hvis dere ikke er fullverdige partnere og lar leverandøren definere vilkårene, vil leverandøren ha alle kortene på hånden).
• Målet er å definere et godt arbeidsforhold. Dette må etableres på alle nivåer – hos interessenter, ledere og praktikere.
• Kontrakter bør utformes slik at alle ansvarsområder på begge sider identifiseres, med hensiktsmessige målemetoder, terskelverdier, trinnvise betalinger og akseptansekriterier definert for å oppmuntre til god atferd (på begge sider av avtalen).
• Avtaler bør oppmuntre til åpenhet og oppslutning om det felles målet om at prosjektet skal lykkes.

Til ettertanke

Og til slutt, noen spørsmål som kan få deg til å tenke. 

Hvilket forhold har du som tester til utviklerne dine? Eller, hvis du er utvikler og leser dette, hvilket forhold har du til testere? Kanskje du kan spørre samarbeidspartnerne dine innen utvikling eller testing hvordan de ville beskrive forholdet deres. Sammenlign svarene!

For at programvaretestingsteam skal være produktive, må de kommunisere og samarbeide.