Aktuelt

Lesetid: 4 minutter

Hva kan test lære av design thinking?

Metodikken design thinking har vært populær de siste årene. Hvilken relevans har den for software testing?

Begrepet «design thinking» beskriver gjerne en rekke prosesser for å utvikle innovative produkter, og noen definerer det som designdrevet innovasjon. Fokuset er gjerne å innhente informasjon om brukeres behov, ønsker og bruk av produkter og tjenester. Først ønsker vi å forstå brukerne, før vi setter opp mulige løsninger som gir brukerne verdi. Vi kartlegger gjerne situasjoner og kontekster gjennom åpne spørsmål, og deretter brainstormer og undersøker hypoteser og ideer. Deretter lages prototyper på løsninger, som igjen testes. Så kort oppsummert er brukeren i sentrum. Kan test lære noe av denne metodikken?

Design thinking inkluderer testing

Fokuset på å forstå brukerens behov og situasjon gjennomsyrer design thinking, hvor vi i ulike etapper bygger oss opp mot en prototype. Denne prototypen skal deretter testes. Denne testfasen kan vi testere kjenne oss igjen i. Ut fra et brukerperspektiv skal vi gjøre undersøkelser som igjen bidrar til å innhente relevant informasjon om prototypen. Svarer prototypen til brukernes behov og ønsker? Hva er det som mangler? Hva kan gjøres annerledes? Hva er den naturlige veien videre for produktet eller tjenesten? Her begynner vi å ane likheter med utforskende testing.

Utforskende testing

Løsriver vi oss fra perspektivet om at testingen kun begrenses til å vurdere en prototype, ser vi at design thinking har mye felles med utforskende testing. Fra de første spørsmålene som vi stiller til de utvalgte brukerne er vårt fokus å få mer innsikt. Vi vil lære mer om brukeren, hva brukeren mener er viktig og hvordan brukeren ønsker å bruke produktet. Vi observerer brukerne for å innhente informasjon som ligger i det ikke-verbale, for igjen kunne vite litt mer om brukernes reaksjoner på applikasjoner og tjenester. Der situasjonen innbyr til mer kreativitet, så åpner design thinking og utforskende test begge til at vi følger veiene vi mener er viktige å forfølge. Målet er mer forståelse og innsikt. Mens design thinking sakte ønsker å bygge et produkt eller en tjeneste gjennom brukerens behov og ønsker, så kan vi si at utforskende test på samme vis gradvis bygger opp innsikt i produktet.

Arbeid med innsikt og testing bør ses på som to sider av samme sak.

doga.no

Passer den inn i «våre» metodikker?

Rent umiddelbart kan design thinking virke litt fremmed når vi sammenlikner med hvordan vi jobber med utviklingsprosjekter i dag. Selv om vi lar brukere komme til orde med sine ønsker, og kanskje flere av dem deltar i for eksempel akseptansetesting eller Beta-testing, så er det ikke ofte vi tar oss tid til grundige intervjuer og observasjoner av brukere. Det er vel også sjeldent at vi tar oss tid til å utvikle prototyper og gir brukerne tid til å ta dem i bruk. Kanskje er det vanligere at vi har litt kontakt med brukerne før vi starter utviklingen, og så noe kontakt med dem igjen når vi mener oss ferdige og vil levere? Vi har jo også brukervennlighetstesting som en del av kvalitetsegenskaper og ikke-funksjonelle krav.

Noen agile metodikker har mer fokus på prototyper og kontinuerlig læring enn andre. Vi kjenner til «Minimum Viable Product» fra Lean StartUp, og flere smidige metoder bruker gjerne user stories og user scenarios for å sette opp spesifikasjoner rundt brukeren. Det er også tilnærmelser som forsøker å inkludere brukerne i selve utviklingen, som Behavior-Driven Design (BDD). Acceptance Test Driven Development (ATDD) er en utviklingsmetodikk hvor forretning, utviklere og testere samarbeider tett for å sette akseptansekriterier for funksjonalitet før implementering starter.

Kan vi gjøre noe mer?

Vi ser altså at design thinking har store likhetstrekk med utforskende testing og en del smidige metodikker. Kan vi lære noe mer som software testere?

En første tanke er at design thinking som metodikk angår langt flere enn testere. Det er ingen grunn til at det skal finnes en egen yrkesgruppe som skal styre, tolke eller bearbeide tilbakemeldinger fra brukerne inn til utviklingsteamet. Brukerfokuset angår alle, og selv om vi testere kan bidra til innhenting av informasjon – så er det brukerne som skal tale, og hele teamet som skal lytte.

Derimot kan vi testere lære av denne måten å strukturere selve utforskingen på. Hvordan kan vi i vår egen utforsking også undersøke veier som brukere ville ta? Hvordan vil en bruker eller systemet reagere på en mindre endring som vi tar initiativ til? Hvilke fordommer, antakelser og vaner er det vi selv tar med oss inn i prosessen?

Finner du noen svar på disse spørsmålene i ditt prosjekt?