Brugervenligheds- og brugeroplevelsesvurderinger som en del af kvalitetssikringen

Hvis du mener, at godt design er dyrt, bør du se på omkostningerne ved dårligt design.

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

I løbet af det seneste årti er brugeroplevelsen blevet den afgørende forskel mellem gode applikationer og fremragende applikationer. 

Den tekniske side af softwareudvikling er i nogen grad et løst problem. De reelle muligheder for ekstraordinær succes med softwareprodukter ligger i UX. Den næste banebrydende app vil have en grænseflade, der kan bruges med det samme. Det har ført til en forskningsbaseret, UX-fokuseret tilgang til produktudvikling. 

Resultaterne af dette fokus taler for sig selv.

For eksempel genererer hver dollar, der investeres i UX, et afkast på $100 ifølge en rapport fra Forrester Research. Derudover viser en undersøgelse, at den økonomiske præstation for design-drevne virksomheder overgår S&P's med 219 % over en periode på 10 år. 

Der findes også den legendariske fortælling om, hvordan en e-handelsvirksomhed på ét år øgede salget med $300 millioner blot ved at ændre teksten på én knap!

Men på trods af al denne hype og ståhej findes der for hver applikation med en fantastisk brugeroplevelse flere, der klarer sig dårligt eller meget dårligt på det område. De værste er nemme at få øje på; de får dig til at få lyst til at slå hul i din laptops skærm eller kaste din mobile enhed ud ad et vindue. Darwin tager sig af de applikationer.

Den virkelige udfordring er apps med en nogenlunde UX. Det er den slags, der giver de berømte oplevelser, som er “en splint i dit sind”, hvor du ikke for alt i verden kan finde ud af, hvorfor du ikke kan lide dem!

Jeg kan høre dig sige: “Vi ved alt dette; jeg læser trods alt The QA Lead, så hvad har det med mig at gøre?” Jeg kommer til det.

Vigtigheden af UX

I mine tidlige dage som leder af ingeniørteams arbejdede vi på et stort softwareløsningsprojekt for en af vores kunder. Det var en del af en større digital transformationsstrategi, der blev implementeret for kunden. Det var et typisk ingeniørteam, som primært bestod af softwareudviklere og QA-ingeniører, der brugte Scrum med sprints på 2 uger.

Der var et lille UX-team, men det var for det meste delt mellem flere projekter. Typisk deltog UX-folkene i teamets daglige møder i projektets tidlige faser, men når kunden havde godkendt det visuelle design, afleverede de alle skabelonerne til det visuelle design samt flows og gik derefter videre til at arbejde på andre projekter.

Under den første sprintdemonstration virkede kunden primært bekymret over, at det visuelle design og brugergrænsefladen ikke stemte helt overens med designskabelonerne. Der var også en forskel mellem den foreslåede funktionalitet og det, der faktisk var implementeret.

Bemærk, at forskellen ikke var stor, men uanset hvor meget vi forsøgte at forsikre kunden om, at UX-delen ville blive rettet i et af de senere sprints, viste hans kropssprog, at han ikke var tilfreds med det.

Heldigvis tog QA-lederen på vores team ordet, sagde, at dette var en anomali, og at det ikke ville ske igen. Og så gjorde hun noget fantastisk. Lad mig skitsere det her:

1. Hun tog selv initiativ til at opdatere sin UX-viden ved at læse intensivt.
   
2. Derefter gennemførte hun selv en grundlæggende heuristisk UX-gennemgang af den leverede funktionalitet, talte med UX-folkene og fik deres hjælp, hvor det var nødvendigt.
   
3. Hun oprettede nye opgaver i JIRA for at rette forskellen mellem det, der var lovet, og det, der blev leveret – set fra et UX-perspektiv.
   
4. Hun arrangerede et opkald med vores UX-chef og fik hans godkendelse til at sikre, at der blev indført en ny proces, hvor applikationens visuelle aspekter blev rettet under hvert sprint og ikke kun til sidst.
   
5. Endelig fik hun også vores QA-folk til at forstå det grundlæggende i UX, så de kunne opdage åbenlyse problemer og hjælpe teamet med at håndtere dem tidligt.

Prikken over i'et? Under den næste sprintdemonstration strålede produktejeren/kunden af glæde, og efter nogle få måneder blev vores QA-leder forfremmet til QA-chef! 😉

Romantiske kontra klassiske perspektiver på virkeligheden

Hele denne episode fik mig til at tænke over den enorme forskel mellem den måde, vi inden for ingeniørarbejde ser en applikation på, og den måde, kunder og brugere ser den på. Robert Pirsig taler i sin banebrydende bog Zen og kunsten at vedligeholde en motorcykel om to perspektiver på virkeligheden: det klassiske og det romantiske.

Ifølge Pirsig ser de, hvis dominerende perspektiv er romantisk, tingene og bedømmer dem ud fra, hvordan de ser ud. De er primært interesserede i, hvordan tingene er, og bekymrer sig ikke om, hvordan de fungerer – den underliggende orden. Dette er den kunstneriske halvdel af skellet mellem kunst og videnskab.

På den anden side tilslutter vi ingeniører & videnskabsfolk os det klassiske perspektiv, hvor skønheden ligger i de mekanismer, der ligger til grund for den ydre form. Ingeniører kan se skønhed i Python-kode eller under motorhjelmen på en bil, hvilket ser grimt ud for dem fra den romantiske side.

Som med alt andet er dette naturligvis ikke en binær klassifikation, men et kontinuum, hvor de fleste af os overvejende foretrækker det ene perspektiv.

Der er nogle interessante konsekvenser af denne måde at klassificere verden på:

1. De fleste menneskers dominerende perspektiv er som udgangspunkt enten klassisk eller romantisk, ikke begge dele.
2. Folk – tænk på kunder, interne eller eksterne – med det romantiske perspektiv er langt flere end dem med det klassiske perspektiv. Hvis du nogensinde har skullet spille rollen som teknisk support for familie og venner, ved du, hvad jeg taler om!

3. Meget få kan skifte mellem tilstandene, og selv for dem er det en aktivitet, der kræver en indsats.
4. Virkelighed = klassisk + romantisk. De udelukker ikke hinanden. Begge er væsentlige aspekter af helheden.  Skønhed er funktionel. Funktion kan være smuk.

Tag for eksempel blomster. De har så smukke mønstre, som tilsyneladende ikke har nogen funktion. Men den skønhed, vi ser i blomster, har en underliggende struktur med rødder i matematikken: Fibonaccifølgen styrer den struktur og de mønstre, vi ser i blomster. Struktur og æterisk skønhed går hånd i hånd i naturen.

Og det handler ikke kun om skønhed. Placeringen af frøene i en solsikke følger Fibonaccifølgen og det gyldne snit for at få plads til det størst mulige antal frø i blomsten. De samme principper gælder for ingeniørarbejde og brugeroplevelse. 

Dette bringer os endelig til kernen i denne artikel: Folk, der arbejder med kvalitetsteknik, er ideelt placeret til at drage fordel af begge disse tilsyneladende konkurrerende perspektiver.

Software-QA's rolle i UX / brugervenlighed

Som testprofessionel har du haft langt mere erfaring med grænseflader end den gennemsnitlige udvikler eller bruger. 

Du har testet så mange applikationer grundigt og gentagne gange (ad nauseum!), at du måske har nået niveauet for tænkning på højere niveau, også kaldet 4D-tænkning, når det gælder UX – ligesom den berømte skakstormester, der tænker i positioner, i modsætning til undertegnede, som har svært ved at finde ud af, hvilken brik der skal flyttes som den næste! ;-)

Derfor er der, på trods af den massive bevægelse mod automatisering – uden tvivl et godt skridt – noget at sige for noget manuel testning. Når alt kommer til alt, hvis mennesker skal bruge en applikation, giver det mening at inddrage et menneskeligt perspektiv i testningen.

Sådan udfører du en UX-/brugervenlighedsgennemgang som testingeniør

Hvis kvalitetssikring skal tage UX i betragtning, skal det begynde samtidig med designfasen, altså i begyndelsen af livscyklussen. Her er de trin, du kan følge for at inkludere UX-gennemgangen i din testning og blive en QA-polymat!

Brugervenlighedsheuristikker til design af brugergrænseflader 

Gør dig bekendt med Jakob Nielsens 10 generelle principper for interaktionsdesign. Dette sæt retningslinjer er et pålideligt referencepunkt for enhver brugervenlighedsgennemgang. Indarbejd disse principper i dine drøftelser med UX-teamet såvel som i din testplan. Du kan også undersøge et hvilket som helst antal grundkurser i brugervenlighed og UX-design.

Lær principperne for tilgængelighed

Du har måske tidligere udført tilgængelighedstest som en del af din testplan, men hvis du forstår principperne bag tilgængelighed—at være opfattelig, betjenelig, forståelig og robust—får du evnen til at se det, andre måske overser.

UX-teamet er dit nye samlingspunkt

Vær ikke en fremmed: Lær UX-teamet på projektet at kende. Samarbejd med dem. Del din testplan med dem, og få feedback på, hvad du kan inkludere fra et UX-perspektiv.

Fordelene ved denne interaktion går begge veje, eftersom din testplan vil give designteamet indsigt i, hvor gennemførlige de designfunktioner er, som de ønsker at foreslå. Som QA-leder skal din interaktion med UX-teamet være lige så tæt som den med udviklerne. 

Inkludér analyser i din testplan

Brugeranalyserne for det produkt, du tester, er en guldgrube af information for testere. Analyser kan hjælpe dig med at identificere risikoområder og brugeradfærd. Det kan igen hjælpe dig med at identificere og prioritere rettelser så tidligt som muligt i produktets livscyklus.

Flyt testningen til venstre, indtil du ikke kan flytte den længere

Det produkt, du tester, er som et barn. Du skal sørge for, at det får den hjælp, det har brug for, allerede fra produktets undfangelse. Gå helt tilbage til begyndelsen.

Før udviklingen 

Test på designstadiet, så snart en prototype er klar. Brug din erfaring med applikationer og din viden om brugervenlighedsprincipper og retningslinjer for tilgængelighed til at kontrollere, om der skal foretages ændringer, FØR produktet går videre til udviklingsstadiet. 

Hvis QA endnu ikke er en del af designfasen, så få det til at ske, hvis det er muligt.

Målrettet manuel test

Gennemgå hele oplevelsen af at bruge produktet fra start til slut som en del af den manuelle test. Fokuser på at stille de rigtige spørgsmål, og tænk både som en bruger og som en QA-ingeniør. 

Begynd med at træde et skridt tilbage og se på produktet fra et bredere perspektiv. Nyder du oplevelsen? 

Se derefter nærmere på det. Er det nemt at bruge? Er arbejdsgangene tydelige og intuitive? Er de besværlige og langsomme? Er der overlap eller gentagelser af handlinger, som kan være irriterende for brugeren? Er designet brugervenligt ved forskellige skærmstørrelser? 

Til sidst

Fremtidens arbejde tilhører dem med flere sæt af komplementære færdigheder, som det næsten er umuligt for maskiner at overtage (men læs min artikel om AI i testautomatisering for at få en fornemmelse af, hvad de kan gøre). 

At blive en QA-polymat med UX-kompetencer kan være en god måde at udnytte dine naturlige evner og din erfaring på, tilføre en masse ekstra værdi uden at bruge for meget energi eller bevæge dig for langt ud på et sidespor.

Er det noget, der begejstrer dig? Eller mener du, at UX kun er perifert forbundet med dette felt? Fortæl mig det i dine kommentarer nedenfor.

Hvis du er klar til at lære mere, er her en podcast, du kan læse/lytte til: SÅDAN FORENKLER OPEN SOURCE-SOFTWARE INTEGRATION I AUTOMATISERINGSUDVIKLING (MED JAMES WALKER OG SANJAY KUMAR)