Det er ingenting som er bedre enn et perfekt prosjekt, men dessverre er det ikke alle prosjekter som er like perfekte. Quality Assurance (QA) er et eget fagfelt der hovedoppgaven er å sikre at kvaliteten på det en leverer er god nok. For at man skal sikre godkjent kvalitet, er det kritisk at også QA-prosessen er god.

Hva er QA?

Formålet med en grundig kvalitetssikringsjekk (QA-sjekk) er å sikre at det som settes ut i produksjon ikke bryter med de standardene som er satt, i tillegg til å teste for slik at man avdekker eventuelle feil eller "bugs". Dette gjøres ved å teste koden grundig for alle mulige "edge cases", dvs. uvanlige feil eller situasjoner som kan oppstå, selv om det ikke nødvendigvis trenger å være feil som er vanskelige å løse. En QA-sjekk er også en god måte å oppdage forbedringsmuligheter på, for eksempel ytelse eller effektivitet i koden. Ved å teste koden grundig kan man avdekke om koden kan bli raskere, bruke mindre minne eller på andre måter yte bedre. Formålet med en grundig QA-prosess er altså ikke bare å finne og fikse feil, men også å forbedre koden og produktet generelt. En grundig testing av koden kan bidra til et bedre produkt med høyere kvalitet, noe som vil glede både utviklere og brukere.

QA-prosessen

Hvordan QA-sjekken gjennomføres kan variere fra arbeidsplass til arbeidsplass. Noen steder er det en egen testperson og en QA-ekspert. Andre steder utfører utviklerne selv testingen sammen med en testleder. Uansett hvordan man velger å løse det, er det noen ting som er viktige å sjekke og gjøre for at QA-prosessen skal være nyttig. En slik prosess vil aldri være perfekt fra start, men QA-teamet kan lage en "lessons learned", som vil hjelpe til med å forbedre prosessen.

1. Test Suites

En “test suite” er en samling tester som brukes til å validere funksjonaliteten til et program. Testene i en “test suite” sjekker hver for et spesifikt forventet resultat for å avgjøre om programvaren fungerer som den skal. En “test suite” lar programvareutviklere bekrefte at endringer som er gjort i et program ikke brøt eksisterende funksjonalitet. Det å ha gode test suiter er essensielt for at man skal sikre både kvalitet og at integrasjonen funker som forventet. Først og fremst trenger man da et testmiljø som man deployer til før det går til produksjonsmiljøet. Man bør også ha test script til testene slik at man kan automatisere de, mer om det senere i artikkelen. Det kan være lurt med både enhets- og integrasjonstesting. Enhetstesting er at man tester de ulike partene av en integrasjon uavhengig av hverandre. Integrasjonstest er en test som tester hele flyten og at utfallet ser riktig ut.

2. Risikoanalyse

Det skal mye til at en integrasjon ender opp med å være 100% “bug free”, men man kan forhindre mye ved å la QA teamet ta en risikoanalyse. Dette går ut på å se potensielle “bugs” som kan oppstå ved å analysere alle mulige utfall av en integrasjon som kjører. Hva skjer dersom et system er nede, eller dersom koden krasjer. Her må QA teamet se på feilhåndtering og om integrasjonen vil prøve på nytt.

3. Automatisering

I Avella bruker vi som nevnt ReadyAPI som test verktøy, fordelen med dette er at testene som vi lager her, kan kjøres i en CI/CD pipeline dersom vi lager test script til hver av dem. Dette gjør at vi kan forhindre at integrasjoner som har tester som feiler kommer ut i produksjon, helt automatisert! Dersom en test feiler bør det være en dedikert plass å sende informasjonen om det som feilet. Automatisering er noe som kan avlaste et QA team svært mye. I CI/CD pipelinen vi kjører så er det lagt til flere sjekker på ting i koden som ikke burde være med, det gjør at utvikler ikke kan deploye noe før det er rettet opp i.

4. Monitorering

Monitorering av integrasjoner er til god hjelp for å samle data og videreutvikle integrasjonen. For å samle god data trenger integrasjonen et godt rammeverk for logging. QA teamet skal sørge for å at integrasjoner som lages har god logging. Det kan derfor være lurt å sette opp en felles komponent som skal ta seg av logging.

Loggemeldingene bør inneholde informasjon som tidspunkt for hendelse, type hendelse, beskrivelse av hendelse og bruker. Dette er minimum av informasjon som bør logges for å kunne følge integrasjoner og finne feil. Det kan også være nyttig å logge versjonsnummer av komponenter som er involvert i integrasjonen. Ved hjelp av gode logger kan man spore feilsøking og finne endringer som har ført til feil.

En felles komponent for logging skal sørge for standard struktur for loggingen. Loggemeldingene skal være mulig å lese, og skal kunne brukes effektivt av IT teamet.

Optimalisering av kvalitetssikringsprosessen gjennom 4 kritiske steg

De fire stegene til en vellykket QA-prosess - Test Suites, risikoanalyse, automatisering og monitorering - utgjør hjørnesteinene for å sikre høy kvalitet i leveranser. Disse stegene bidrar til tidlig identifisering av feil, optimal ressursallokering, effektiv testing og kontinuerlig forbedring. Samlet sett gir de en mer pålitelig vei mot målet om kvalitetssikring, kostnadsreduksjon og enn forbedret brukeropplevelse.

Det er flere veier til mål, men målet er alltid å sikre kvalitet. Helt enkelt!