Slik lykkes du med smidig kvalitetssikring

Hyppige IT-leveranser er avgjørende for mange virksomheter. Samtidig er kravene til kvalitet på IT-løsningene både viktigere og mer omfattende. Hvordan kan god kvalitet sikres i en stadig økende mengde av IT-leveranser?

Av: Mona Tran, testleder i Webstep

Hensikten med smidig kvalitetssikring er at kvalitetssikringen er en integrert del av utviklingsprosessen, og uansett om metodikken er Scrum, Kanban, Lean eller tilsvarende. Smidig kvalitetssikring følger de samme prinsippene som smidig programvareutvikling med korte iterasjoner, tilpasning til brukerbehov, og at personene i produktteamet har god kommunikasjon og godt samarbeid seg imellom. Produktteamet består av personer med kompetanse på teknologi/utvikling, brukeropplevelse, testing og på forretningsutvikling, og teamet blir ledet av en produkteier som styrer produktkøen og prioriteringen av den.

En viktig forutsetning for å lykkes med hyppige leveranser med god kvalitet er at produktteamet jobber tett med interessenter, fagressurser og brukere på hvert eneste steg i utviklingsprosessen, dvs. fra behovsanalyse til leveranse av løsningen. Det er også viktig at teamet kontinuerlig identifiserer forbedringer for hvordan produktteamet kan jobbe bedre sammen for å lykkes med hyppige leveranser av god kvalitet.

Kontinuerlig kvalitetssikring er avgjørende

Kvalitetssikring og testing er en pågående aktivitet og ikke en fase som kommer på slutten av utviklingsløpet. Før utviklingen starter bør løsningskonseptet brukertestes på skissenivå eller med klikkbare prototyper. Underveis i utviklingsløpet må koden testes med automatiserte enhets- og integrasjonstester før funksjonell testing og utvikling av automatiserte ende til ende-tester i brukergrensesnittet.

Det er viktig å ha hyppige og små leveranser som kan testes fortløpende av produktteamet med produkteier i et testmiljø. I tillegg kan det lønne seg å invitere brukerne av løsningen til utforskende testing med jevne mellomrom, og på den måten fange opp flere erfaringer for å forbedre produktet.

Forhindre feil fremfor å finne feil

Mange feil oppstår i fasen fra krav til utvikling, siden produktteamet gjør antakelser og implementerer kravene uten nødvendige avklaringer med fagressurser. Noe som medfører at disse antakelsene først blir avklart når funksjonaliteten blir testet etter utvikling, og at flere justeringer må til for at funksjonaliteten blir godkjent. Og flere runder med justeringer stjeler verdifull tid.

Det er billigere å forebygge feil enn å oppdage feilen etter utviklingsløpet, så feil bør bli avdekket så tidlig som mulig. Det er bedre å avklare detaljer i fellesskap i forkant av utviklingsløpet istedenfor at det blir gjort når funksjonaliteten skal testes. Hvilke avklaringer som bør dokumenteres i oppgavene, kan produkttteamet i fellesskap bli enige om.

Aktiviteter som parprogrammering og kodegjennomgang vil bidra til å skape en felles forståelse av oppgaven som skal løses, og forbedre kommunikasjon og samarbeid i teamet.

Forstå brukerne

I et smidig testløp må hele produktteamet ha god innsikt i brukernes faktiske behov, slik at produktteamet kan kvalitetssikre at behovene blir ivaretatt og ikke kun verifisere den spesifikasjonen som blir levert. Testing av implementert funksjonalitet kan i stor grad utføres gjennom automatiserte tester på ulike nivåer:

– Enhetstester
– Integrasjonstester
– Ende til ende-tester i brukergrensesnittet

Disse automatiserte testene bør kjøres i et eget miljø med kontinuerlig integrering (continuous integration – også kalt CI).

Fokuser på vanlig bruksmønster

En tenker ofte at målet med testing er å avdekke feil, men hovedmålet med produktutviklingen er å utvikle en løsning som fungerer som forventet for brukerne. Det er derfor viktig å fokusere på de positive testene som omfavner vanlig bruksmønster. Negative tester som verifiserer om løsningen håndterer ugyldige verdier og hindrer brukeren i å utføre handlinger de ikke har rettigheter til, skal selvsagt utføres også. Nivået og omfanget av disse negative testene må produktteamet ha god dialog om.

Produktteamet er ansvarlig for kvalitet

Alle i produktteamet er ansvarlig for kvaliteten på løsningen og ikke kun en dedikert tester. Hele teamet må kommunisere godt sammen for å ha enighet om prosessene som teamet skal jobbe etter.

Hvis hele teamet er ansvarlig for kvaliteten, trenger da teamet en kvalitets- og testansvarlig? Svaret er et rungende JA – teamet trenger en pådriver for å sikre god kvalitet. I tillegg til ivaretakelse av god kvalitet på funksjonalitet i hele utviklingsfasen, trenger også løsningens ikke-funksjonelle krav å bli ivaretatt. Med ikke-funksjonelle krav menes krav til sikkerhet, universell utforming (WCAG 2.1), brukervennlighet, ytelse, etc. Den testansvarlige vil hjelpe teamet med å bygge opp teamets kompetanse rundt kvalitetssikring og testing, og i tillegg kan samme ressurs også bidra med oppgaver og aktiviteter utenom bare kvalitetssikring og testing.

Oppsummering

For å lykkes med smidig kvalitetssikring må hele teamet være bevisst på hva som sørger for god kvalitet for brukerne av løsningen. Gjennom kontinuerlige forbedringer og læring av hverandre vil teamet få økt kunnskap om kvalitetssikring, slik at kvaliteten på løsningen øker. Husk også å invitere sluttbrukerne av løsningen til kvalitetssikring før utvikling starter og testing underveis!

Ledende på kvalitetssikring og testing

Hvis du har et behov for å kvalitetssikre en leveranse eller et prosjekt, så nøl ikke med å ta kontakt med oss! Vi dekker hele test- og kvalitetsløpet: Fra kvalitets- og teststrategi, til analyse, gjennomføring og rapportering.

Webstep har lang erfaring fra kvalitetssikring og testing av ulike plattformer og teknologier, og er sertifiserte innen standarder som ISO, ISEB/ISTQB Test Manager, Advanced og Agile Test. Ta kontakt for en prat om mulighetene!