Har du tenkt på at det er mulig å ha en programvareløsning helt uten bugs, som likevel ikke gjør det som var tenkt? En QA-ingeniør vil sørge for at det ikke skjer deg.

– Humans like to approximate, forteller Shantanu Roy på video fra Dhaka. Han er en av QA-ingeniørene som jobber for Cefalo i Bangladesh. En ressurs som er vanskelig å få tak på i Norge, men som vi har veldig god tilgang på i Dhaka.

– Vi mennesker har en tendens til å miste informasjon underveis i en prosess. Vi omtrentliggjør og forenkler hele tiden. Det er menneskets natur, og det kan føre til at noe ser ganske annerledes ut på slutten av en utviklingsprosess enn det som egentlig ble forespurt. Min jobb er å sørge for at det ikke skjer, påpeker han.

Hans jobb er å sørge for at sluttbruker får en feilfri og intuitiv opplevelse som ikke lugger.

– Det skjer oftere enn du tror at en programvare som er uten feil likevel ikke gjør som produkteier forventet eller ba om. Dette unngår jeg ved å teste ofte, og hele tiden opp mot kravspekken som er angitt på forhånd.

Teamet jobber bedre med en QA på laget

Du må ikke ha en QA-ingeniør, men du er nødt til å teste. Da kan du jo teste skikkelig fra starten av? Roy mener det er flere prosessfordeler for teamet som helhet, der det finnes en QA-ingeniør til stede som alltid stiller spørsmål.

– QA-folk er skikkelig skeptiske! Som en djevelens advokat stiller vi spørsmål ved alt – hovedsakelig for ikke å miste informasjon underveis. Min erfaring er at utviklingsteamet etter hvert lærer seg å tenke som QA`en gjør, for de vet at spørsmålene vil komme uansett.

Noe annet Roy trekker frem er at QA-ingeniører ikke blindt aksepterer krav.

– Vi er flinke til å si nei, og vi er ikke redd for å ta opp hva vi mener er feil. Det vet jeg at flere av kundene våre setter pris på.

En tredje fordel er at han tror utviklerne blir tryggere med en QA-ingeniør på laget. Og en trygg utvikler presterer bedre. Utvikleren vet at dersom det dukker opp bugs i forbindelse med en endring, så vil de plukkes opp – og da blir man ikke så redd for å gjøre endringer.

– Vi hjelper utviklere med å gjøre jobben sin på sitt beste nivå, sier Roy som også har en fjerde grunn til hvorfor teamet fungerer bedre med en QA-ressurs.

– QA-ressursen blir bindeleddet mellom produkteier og utvikler, og kan fungere som en bro eller en katalysator mellom de ulike rollene i prosjektet. Vi er ikke redd for å starte diskusjoner i teamet for å finne problemer så tidlig som mulig. Den billigste måten å fikse feil på er jo å forhindre dem i utgangspunktet. Så det er det jeg gjør – hver dag, smiler han.

En typisk arbeidsdag for en QA-ingeniør

Som de fleste andre som jobber innen utvikling startes hver morgen med et teammøte. Her ser teamet over kravene til produktet og diskuterer internt for å finne gode løsninger. På denne måten kan de unngå feil og bugs før de skjer.

– Jo oftere vi kvalitetssikrer, jo mindre sannsynlig er det at vi opplever feil, forklarer Roy. – Skulle jeg finne noe som må endres, så kommuniserer jeg direkte med både utvikler og produkteier. Kravspekken gjennomgås kontinuerlig, så jeg har god kontroll på at vi får et produkt som leverer som forventet.

Hans favorittdel av jobben er når han får «misbruke» systemet. Da forsøker han å bruke produktet på en måte det ikke er ment. Slik finner han alle «edge cases» så teamet kan ta stilling til dem.

– Disse observasjonene diskuterer jeg videre med utvikler. Her sørger vi for å ha tydelig, skriftlig kommunikasjon om detaljene. Hvis det er veldig komplisert, tar jeg stolen og setter meg sammen med utvikleren så vi kan finne rotårsaken til problemene sammen. Det er utrolig viktig at vi finner rotårsakene når feil oppstår.

Noe annet QA-ingeniører gjør, er at de foreslår forbedringer underveis. Hvis Roy tror at produkteier eller sluttbruker vil ha nytte av noe, eller at det ville være mer fornuftig å gjøre noe, så vil han foreslå det til både produkteier og utvikleren som sitter på prosjektet. På denne måten hjelper han produktet med å nå sitt fulle potensial.

– Vi gjør også regresjonstesting for å unngå sommerfugleffekten (at endring ett sted skaper problemer et annet sted). Dette skriver vi automatiserte tester for, bare for å sjekke at systemet er stabilt med de nye endringene. I tillegg gjør vi også ytelsestester, der vi legger på mye stress for å se hvordan systemet reagerer. Her tester vi funksjon og ytelse under perioder med stor belastning. Det er jo viktig at betalingsløsninger tåler julehandelen for eksempel, påpeker han.

TRIVES I CEFALO: Shantanu Roy har jobbet hos Cefalo i en årrekke og trives godt som QA-ingeniør med norske kunder.

Derfor trenger du en QA-ingeniør!

Likte du denne artikkelen? Les hvorfor du bør ha en QA-ressurs på teamet ditt.

Les mer

Er du nysgjerrig på ekstern utvikling? Vi tar gjerne en hyggelig prat med deg på telefon, møte eller video.