Gjennomganger av brukervennlighet og brukeropplevelse som en del av kvalitetssikringen

Hvis du tror god design er dyrt, bør du se på kostnadene ved dårlig design.

Dr. Ralf Speth, administrerende direktør, Jaguar Land Rover

I løpet av det siste tiåret har brukeropplevelse blitt den virkelige forskjellen mellom gode applikasjoner og fantastiske applikasjoner. 

Den tekniske siden ved å utvikle programvare er på mange måter et løst problem. De virkelige mulighetene for eksepsjonell suksess med programvareprodukter ligger i UX. Den neste banebrytende appen vil ha et grensesnitt som kan brukes umiddelbart. Dette har ført til en forskningsbasert, UX-fokusert tilnærming til produktutvikling. 

Resultatene av dette fokuset taler for seg selv.

For eksempel gir hver dollar som investeres i UX, 100 dollar i avkastning, ifølge en rapport fra Forrester Research. I tillegg viser en studie at den økonomiske ytelsen til designorienterte selskaper overgår S&P med 219 % over en tiårsperiode. 

Det finnes også den legendariske historien om hvordan det å endre teksten på én knapp førte til 300 millioner dollar i økt salg for et e-handelsselskap på ett år!

Men til tross for all denne hypen og ståheien finnes det flere applikasjoner med mangelfull eller svært mangelfull brukeropplevelse for hver applikasjon med en god brukeropplevelse. De forferdelige er enkle å oppdage; de får deg til å ville slå hull i laptopskjermen eller kaste mobilen ut av et vindu. Darwin tar seg av disse applikasjonene.

Den virkelige utfordringen er apper med en sånn passe UX. Det er de opplevelsene som er som den velkjente «flisen i hodet» – du klarer ikke for alt i verden å finne ut hvorfor du ikke liker dem!

Jeg kan høre deg si: «Vi vet alt dette; jeg leser The QA Lead, for pokker, så hva har dette med meg å gjøre?» Jeg kommer til det.

Betydningen av UX

Da jeg var tidlig i karrieren som leder for utviklingsteam, jobbet vi med et stort programvareløsningsprosjekt for en av kundene våre. Dette var en del av en større digital transformasjonsstrategi som ble gjennomført for kunden. Det var et typisk utviklingsteam som hovedsakelig besto av programvareutviklere og QA-ingeniører, og som brukte Scrum med sprinter på to uker.

Det fantes et lite UX-team, men det var for det meste delt mellom flere prosjekter. Vanligvis deltok UX-medarbeiderne på teamets daglige møter i de tidlige fasene av prosjektet, men så snart kunden hadde godkjent det visuelle designet, overleverte de alle malene for det visuelle designet samt flytene, før de gikk videre til arbeid på andre prosjekter.

Under den første sprintdemoen var kunden først og fremst opptatt av at det visuelle designet og brukergrensesnittet ikke samsvarte helt med designmalene. Det var også et avvik mellom funksjonaliteten som var foreslått, og det som faktisk var implementert.

Riktignok var avviket ikke stort, men uansett hvor mye vi forsøkte å forsikre kunden om at UX-delen skulle ryddes opp i under en av de senere sprintene, viste kroppsspråket hans at han ikke var fornøyd med det.

Heldigvis tok QA-lederen i teamet vårt ordet, sa at dette var et avvik, og at det ikke kom til å skje igjen. Og så gjorde hun noe fantastisk. La meg beskrive det her:

1. Hun tok selv initiativ til å friske opp UX-kunnskapene sine ved å lese intensivt.
   
2. Deretter gjennomførte hun selv en grunnleggende heuristisk UX-gjennomgang av funksjonaliteten som var levert, snakket med UX-medarbeiderne og fikk hjelp fra dem der det var nødvendig.
   
3. Hun opprettet nye oppgaver i JIRA for å rette opp avviket mellom det som var lovet, og det som var levert – sett fra et UX-perspektiv.
   
4. Hun satte opp en samtale med UX-sjefen vår og fikk godkjenningen hans til å innføre en ny prosess der de visuelle aspektene ved applikasjonen ble rettet opp under hver sprint, og ikke bare på slutten.
   
5. Til slutt fikk hun også QA-medarbeiderne våre til å forstå det grunnleggende innen UX, slik at de kunne oppdage åpenbare problemer og hjelpe teamet med å håndtere dem tidlig.

Prikken over i-en? Under den neste sprintdemoen smilte produkteieren/kunden fra øre til øre, og etter noen måneder ble QA-lederen vår forfremmet til QA-sjef! 😉

Romantiske versus klassiske perspektiver på virkeligheten

Hele denne episoden fikk meg til å tenke på det enorme gapet mellom hvordan vi i utviklingsmiljøet ser på en applikasjon, og hvordan kunder og brukere ser på den. Robert Pirsig snakker i sin banebrytende bok Zen og kunsten å vedlikeholde en motorsykkel om to perspektiver på virkeligheten: det klassiske og det romantiske.

Ifølge Pirsig ser de som har et dominerende romantisk perspektiv, ting og vurderer dem ut fra hvordan de fremstår. De er først og fremst interessert i hvordan ting er, og bryr seg ikke om hvordan de fungerer – den underliggende ordenen. Dette er den kunstneriske halvdelen av skillet mellom kunst og vitenskap.

På den annen side bekjenner vi ingeniører & forskere oss til det klassiske perspektivet, der skjønnheten ligger i mekanismene som ligger til grunn for den ytre formen. Ingeniører kan se skjønnhet i Python-kode eller under panseret på en bil, noe som ser stygt ut for dem på den romantiske siden.

Som med alt annet er dette åpenbart ikke en binær klassifisering, men et kontinuum der de fleste av oss i hovedsak foretrekker ett av perspektivene.

Det finnes noen interessante følger av denne måten å klassifisere verden på:

1. De flestes dominerende perspektiv er som standard enten klassisk eller romantisk, ikke begge deler.
2. Folk – tenk på kunder, interne eller eksterne – med det romantiske perspektivet er langt flere enn dem med det klassiske perspektivet. Hvis du noen gang har måttet spille rollen som teknisk støtte for familie og venner, vet du hva jeg snakker om!

3. Svært få kan bytte mellom modusene, og selv for dem er det en aktivitet som krever innsats.
4. Virkelighet = klassisk + romantisk. De utelukker ikke hverandre. Begge er viktige aspekter av helheten.  Skjønnhet er funksjonell. Funksjon kan være vakker.

Ta blomster, for eksempel. De har så flotte mønstre som ser ut til å ikke ha noen funksjon. Likevel har skjønnheten vi ser i blomster, en underliggende struktur forankret i matematikk: Fibonacci-rekken styrer strukturen og mønstrene vi ser i blomster. Struktur og eterisk skjønnhet går hånd i hånd i naturen.

Og det handler ikke bare om skjønnhet. Plasseringen av frøene i en solsikke følger Fibonacci-rekken og det gylne snitt for å få plass til flest mulig frø i blomsten. De samme prinsippene gjelder for ingeniørarbeid og brukeropplevelse. 

Dette bringer oss endelig til kjernen i denne artikkelen: De som arbeider med kvalitetsutvikling, er ideelt posisjonert til å dra nytte av begge disse tilsynelatende konkurrerende perspektivene.

Programvare-QAs rolle i UX / brukervennlighet

Som testfagperson har du hatt langt mer erfaring med grensesnitt enn den gjennomsnittlige utvikleren eller brukeren. 

Du har testet så mange applikasjoner grundig og gjentatte ganger (til det kjedsommelige!) at du kan ha nådd nivået for tenkning på høyere nivå, også kalt 4D-tenkning når det gjelder UX – omtrent som den legendariske stormesteren i sjakk som tenker i posisjoner, i motsetning til undertegnede, som strever med å finne ut hvilken brikke som skal flyttes! ;-)

Derfor, til tross for den massive overgangen til automatisering – et utmerket tiltak, uten tvil – er det noe som taler for noe manuell testing. Når alt kommer til alt, hvis mennesker skal bruke en applikasjon, gir det mening å få et menneskelig perspektiv inn i testingen.

Slik gjennomfører du en UX- / brukervennlighetsgjennomgang som testingeniør

Hvis kvalitetssikring skal ta UX i betraktning, må det begynne samtidig med designfasen, altså i begynnelsen av livssyklusen. Her er trinnene du kan følge for å inkludere UX-gjennomgangen i testingen og bli en QA-generalist!

Brukervennlighetsheuristikker for utforming av brukergrensesnitt 

Gjør deg kjent med Jakob Nielsens 10 generelle prinsipper for interaksjonsdesign. Dette settet med retningslinjer er et pålitelig referansepunkt for enhver brukervennlighetsgjennomgang. Ta hensyn til disse prinsippene i diskusjonene med UX-teamet og i testplanen. Du kan også se nærmere på et hvilket som helst antall grunnkurs i brukervennlighet og UX-design.

Lær prinsippene for tilgjengelighet

Du har kanskje gjennomført tilgjengelighetstesting som en del av testplanen din tidligere, men hvis du forstår prinsippene bak tilgjengelighet – mulig å oppfatte, mulig å betjene, forståelig og robust – får du evnen til å oppdage det andre kanskje overser.

UX-teamet er din nye møteplass

Ikke vær en fremmed: Bli kjent med UX-teamet på prosjektet. Samarbeid med dem. Del testplanen din med dem, og få tilbakemeldinger på hva du kan inkludere fra et UX-perspektiv.

Fordelene ved denne interaksjonen går begge veier, ettersom testplanen din vil gi designteamet innsikt i hvor gjennomførbare designfunksjonene de ønsker å foreslå, er. Som QA-leder må samhandlingen din med UX-teamet være like tett som den du har med utviklerne. 

Inkluder analyse i testplanen din

Brukeranalyser av produktet du tester, er en gullgruve av informasjon for testere. Analyse kan hjelpe deg med å identifisere risikoområder og brukeradferd. Dette kan igjen hjelpe deg med å identifisere og prioritere rettelser så tidlig som mulig i produktets livssyklus.

Flytt testingen til venstre – helt til du ikke kan flytte den lenger

Produktet du tester, er som en baby. Du må sørge for at det får hjelpen det trenger helt fra produktets unnfangelse. Gå helt tilbake til begynnelsen.

Før utviklingen 

Test på designstadiet så snart en prototype er klar. Bruk erfaringen din med applikasjoner og kunnskapen din om prinsipper for brukervennlighet og retningslinjer for tilgjengelighet til å kontrollere om det må gjøres endringer FØR produktet går over i utviklingsfasen. 

Hvis QA ennå ikke er en del av designfasen, bør du sørge for at det blir det, hvis mulig.

Målrettet manuell testing

Gå gjennom hele opplevelsen av å bruke produktet fra start til slutt som en del av den manuelle testingen. Fokuser på å stille de riktige spørsmålene, og tenk både som en bruker og som en QA-ingeniør. 

Begynn med å ta et skritt tilbake og se på produktet fra et bredere perspektiv. Liker du opplevelsen? 

Se deretter nærmere på det. Er det enkelt å bruke? Er flytene tydelige og intuitive? Er de kjedelige og trege? Finnes det overlapp eller duplisering av handlinger som kan være irriterende for brukeren? Er designet brukervennlig på ulike skjermstørrelser? 

Til slutt

Fremtidens arbeidsliv tilhører dem som har flere sett med komplementære ferdigheter som det er nesten umulig for maskiner å overta (men ta en titt på artikkelen min om AI i testautomatisering for å få et inntrykk av hva de kan gjøre). 

Å bli en QA-polymat med UX-ferdigheter kan være en flott måte å spille på dine naturlige evner og din erfaring, tilføre mye ekstra verdi uten å bruke for mye krefter eller bevege deg for langt ut på sidelinjen.

Er dette noe som begeistrer deg? Eller mener du at UX bare er perifert knyttet til dette fagområdet? Fortell meg gjerne hva du mener i kommentarene nedenfor.

Hvis du er klar for å lære mer, kan du lese eller lytte til denne podkasten: SLIK FORENKLER PROGRAMVARE MED ÅPEN KILDEKODE INTEGRASJON I AUTOMATISERINGSUTVIKLING (MED JAMES WALKER OG SANJAY KUMAR)