Hva er Smidig Testing?
I utgangspunktet er smidig testing like lett som det er vanskelig. På et overordnet nivå handler smidig testing om å forhindre feil og å finne feil. Hvis tradisjonell testing var vanskelig så er nok smidig testing enda vanskeligere. Det handler ikke bare om prosesser, metodikk eller teknikker som skal utføres av testressursen.
Smidig testing handler mer om å endre mentaliteten til kvalitet. Det ultimate målet med smidig testing er å gjøre testing til en integrert del av den smidige utviklingsprosessen, enten det er Scrum, Kanban, Lean eller noe annet.
For å lykkes med smidig testing så er det viktig å forstå selve byggesteinene. Fundamentet som sikrer smidig testing for et produkt eller en tjeneste er som følger:
Figur 1
Denne artikkelen ble først publisert i mars 2018.
Slik kommer du i gang
For å komme i gang med smidig testing er det viktig å begynne med det elementære som sammen blir strategien til hele teamet under utvikling og forvaltning.
Punkt 1:
Software-testing er ikke mindre viktig i smidige team enn i tradisjonell utvikling. Ved overgang fra tradisjonell utvikling til smidig utvikling blir ofte organisasjoner og produktteam bekymret for kostnadene som kommer ved tidlig testing. I mange tilfeller tror de at sprinttesting og systemtesting er nok, men denne forutsetningen er feil fordi testing kun utført av testressursen går under kategorien å finne feil. Risikoen for feil vil være ukjent da kvaliteten til produktet er manglende på grunn av forståelsen av smidig testing.
Trenger du hjelp med test og testledelse? Se hva vi kan tilby deg her!
Ofte praktiserer produktteamene i smidig testing med en testressurs som kun tester i sprinten og gjennomfører systemtestene, eller kun vurderer en testutvikler som blir satt på oppgaven med å automatisere funksjonelle tester for å få opp farten og øke testdekning. Faren ved dette er at smidig testing ikke blir gjennomført på en god måte som sikrer kvalitet. En god testressurs bidrar med testaktivitetene som er beskrevet under software-testing i figur 1.
Første oppgave er å danne grunnlag for testing ved å gjennomføre risikobasert testplanlegging sammen med teamet. Utfallet av dette er at forretningkritiske og sluttbrukerområder blir definert som en del av oppstarten. Etter hvert som produktet eller tjenesten utvikles så kommer sprinttestplanlegging med utvikling av testcase, regressjontesting, exploratory testing og planlegge lansering av produktet.
Les mer: Vi leverer kvalitetssikring, testledelse, funksjonell test og teknisk test.
Punkt 2:
Utvikling og automatisering er grunnlaget for å forhindre feil, og er nøkkelen til å sikre høy kvalitet. Det er fordi koden som blir utviklet også skal testautomatiseres i henhold til risikoanalysen og teststrategien. Uten dette er kvalitet dødsdømt. Det å skylde på testeren for at feil ikke er oppdaget før det er i produksjon er ikke riktig. En tester kan ikke avdekke alle logiske feil som ikke er håndtert riktig i koden. Om testeren er heldig så kan noe av dette bli avdekket som symptomer i grensesnittet. Løsningen er at utvikleren må ta sitt ansvar og teste koden.
I de største IT-selskapene i verden, som Google og Facebook, får ikke utvikleren sjekke inn koden uten testkoden. Det er fordi kvalitet kun oppnås ved å automatisere koden, ikke ved å lage x antall testcaser som skal gjennomføres av testressursen senere.
Å redusere antall tester som må utføres manuelt bør ikke være et av hovedmålene for automatisert testing. Kanskje det største målet med testautomatisering er å ha kapasitet til å sikre at alle deler av et system testes på en effektiv, systematisk og komplett måte ved hjelp av en metodikk og verktøy som lett kan repeteres.
Automatisering av koden kommer også til stor nytte når teknisk gjeld skal håndteres. Det er fordi testene kjapt bekrefter at koden som er endret i forvaltning ikke knekker andre områder for produktet eller tjenesten. 100 % testdekning er ikke målet, men å kunne verifisere at komponenter og integrasjoner fungerer til enhver tid må være et krav. Som nevnt i punkt 1, er det viktig å kartlegge hva som er forretningskritisk og hva som har størst konsekvens for kunden. Det er disse områdene som er viktig å automatisere, som kan bety at testdekningen er langt lavere enn 100 %.
Punkt 3:
Teampraksis handler om hvordan få gode og effektive team. Det er viktig at produktteamet skaper en egen arbeidskultur som er basert på best practices. Noe av det som definerer et godt produktteam er de som baserer seg på smidig testing manifesto (se figur 2) og gjennomfører kodegjennomgang, praktiserer DONE og tester tidlig, tester ofte og tester nok. I tillegg bør man ha stop the line-mentalitet når det gjelder kvalitet og et stort fokus på å håndtere teknisk gjeld for sikre høy kvalitet.
Figur 2
Punkt 4: Monitorering og overvåking er indirekte en annen måte å verifisere produktet eller tjenesten. Det kan gi teknisk og funksjonell innsikt om leveransen som ikke er avdekket tidligere.
Et testmiljø er ikke det samme som et produksjonsmiljø, det er ikke alltid lett å forutse hvilke tekniske eller funksjonelle aspekter som kan feile etter leveranse. Det å kunne innhente data fra monitorering og overvåking kan fortelle om effekten av lansering, for eksempel om leveransen har hatt postiv eller negativ utvikling for en applikasjon med tanke på antall brukere som er innlogget. Monitorering kan også hjelpe forretningssiden å verifisere hypoteser eller A/B-teste funksjonelle aspekter som kan verdiøke organisasjoner i form av kostnadsbesparelser eller investeringer som gir riktig avkastning.
Avslutningvis
For å oppsummere så sikrer smidig testing at vi ikke mister det store bildet i en verden som krever mer og mer. Mentaliteten må endres til at hele teamet tar ansvar for kvaliet, slik at vi kan sikre time-to-market, hyppige leveranser av programvare og kundens kriterier. Kvalitet er essensielt for å lykkes, men bare for de som er villige til å investere i dette.