Jeg vil gjennomgå den ofte glemte delen av applikasjon og testaktiviteter som er minst like viktig, eller viktigere, for å bygge kvalitet i leveransen. Test av Backend-delen i applikasjonen er nøkkelen til å forhindre feil og redusere risiko. Den gode effekten av dette er at antall systemtester og integrasjonstester blir færre fordi de dekker flere områder i applikasjonen.
Kvalitet har aldri vært mer viktig enn det er i dagens IT-løsninger. Underslår man kostnaden av kvalitet, tvinges IT-løsningen til å velge bort kvalitetsdrivere som sikrer fornøyde sluttbrukere og gode leveranser. Ofte er lanseringsdatoen og x-antall funksjonaliteter langt viktigere enn å bygge robust og stabil leveranse. Koden skal utvikles basert på krav og koden skal også testes basert på krav. Noe av dette kan testes ved funksjonell-delen av applikasjonen og resten må dekkes i resten av applikasjonen eller tjenesten. Årsaken til feil som oppdages i grensesnittet skyldes som oftest feil lenger ned i applikasjon.
Årsaker til feil i IT-leveranser
IT-leveranser skiller mellom effektmål (gevinsten som leveransen skal gi) og resultatmål (hva som skal være oppnådd når leveransen er ferdig). Resultatmålet er knyttet til tidsplan, tildelt budsjett og at leveransen oppfyller de ønskede kvalitetsstandardene. Når dette ikke møtes så feiler det ofte pga. følgende årsaker:
- Mangel på interesse fra ledelse
- Kostnadsbesparende tilnærminger
- Mangel på riktig planlegging
- Valg av teknologier
- Unnlatelse av å håndtere omfang
- For optimistisk prosjektplan
- Overkapasitet i prosjektet
- Dårlig kommunikasjon
- Lite testing eller manglende testfaser
Med utgangspunkt i siste årsak, lite testing eller manglende testfaser, så mislykkes IT-leveranser fordi testaktiviteter er mer undertrykt enn utviklingsoppgaver. Hver fase av programvarenes livssyklus, SDLC, er like viktig. Programvaren mislykkes fullstendig hvis du hopper over testfaser eller gjennomfører test kun mot slutten. Fokuset i disse leveranse er ofte på funksjonell testing og mindre på kodekvalitet. Manglende kunnskap og kostnadsbesparende tiltak, er ofte grunnen til en slik leveranse.
Kunne du tenke deg å jobbe med test? Visma Consulting ser nå etter en ny testleder. Kanskje det er deg?
Whitebox vs. Blackbox Testing
Hvis målet ditt er å bekrefte at systemet fungerer som det skal, så er det ofte at man fokuserer på Blackbox-testing av systemet i realistiske scenarier og miljøer. Det fordi det er den eneste virkelige måten å vite at systemet faktisk fungerer.
På den annen siden, hvis du bruker testing med hensikten for å fjerne feil og risiko, er det ofte slik at man fokuserer på Whitebox-testing av intern struktur, design og kode som gir langt bedre avkastning enn noe annet.
En annen metode man kan bruke for å få bedre oversikt over testaktiviteter for en applikasjon er å bruke Testhuset (se figur 1) som forenkler komplekse IT-leveranser inn i følgende test-kategorier:
Frontend testing – Verifiserer funksjonaliteter til Testhuset som dører, vinduer og vannkrana fungerer i henhold til kravene. Dette dekkes ofte gjennom system, akseptanse eller regresjonstesting.
Backend testing – Verifiserer at nivået på programvarearkitekturen til Testhuset er i hold til intern struktur av komponenten eller systemet. Det vil si om grunnmuren holder huset på plass, vannrøret lever som forventet og ikke lekker vann, og at pipa er koblet (integrasjonen) til vedovnen i henhold til kravene. Dette dekkes ofte gjennom enhetstest, komponenttest, integrasjonstesting, sikkerhetstest og ytelsestest.
Backend Testing – Ikke test forretningslogikk gjennom brukergrensesnittet
Alt for ofte blir det syndet med å teste forretningslogikk gjennom brukergrensesnittet. Resultatet av en slik tilnærming er at årsaken ikke blir funnet men kun symptomene, samt at antall test-caser stiger drastisk for å verifisere logikken i applikasjonen. Det gir mer mening å flytte testfokuset lavere slik at potensielle feil kan forhindres som en del av utviklingsløpet før grensesnittet er utviklet.
Når det gjelder 100 % testdekning, så er dette tallet bortkastet fordi kostnaden er større enn gevinsten. Uansett tall så må leveranseteamet ta eierskap på testkoden på lik linje som vanlig utviklingskode, ellers finnes det ingen sjanse til å lykkes med Backend testing.
Følgende eksempel tar utgangspunkt i en netthandel side og belyser hvor testfokuset bør settes.
Les mer: 5 fokusområder for å bygge en testkultur
Eksempel – Netthandelside med 3-nivå arkitektur
La oss ta en nettbutikk med en 3-nivå arkitektur som eksempel. En nettbutikk inneholder blant annet krav om brukskvaliltet, sikkerhet og følgende funksjonaliteter som innlogging, søk og betaling i en 3-nivås arkitektur.
Basert på disse kravene så holder det ikke å teste Frontend-delen av applikasjon gjennom systemtest og akseptansetest. Her må fokuset flytte over til backend delen fordi logikken av innlogging og søk må testes på regler og logikk, samt at betaling som er en integrasjon må alltid verifiseres at den fungerer før leveransen skal til produksjon. Dersom noe eller ingenting fungerer som forventet, mister du fornøyde kunder, tapte inntekter og totale kostnaden av feil i produksjon er langt mer kritisk enn om du oppdager dette i utviklingsløpet.
1. Presentasjonslag – Administrerer brukergrensesnittet og den tilhørende kode. Typiske utfordringer i dette laget er:
- Caching av ukryptert data
- Feiler å håndterte exceptions
- Blokkerer brukergrensesnittet under langvarige requester
Formålet er å finne feil basert på funksjonelle eller ikke-funksjonelle krav til systemet. Utgangspunktet for nettsiden er å teste kravene fra et brukerperspektivt og bevare brukskvaliteten for nettsiden.
2. Forretningslag – Administrerer forretningsregler og logikk. Formålet er å forhindre feil basert på en analyse av den interne strukturen til komponenten eller systemet. Typiske utfordringer i dette laget er :
- Bufrer for mye data i forretningslaget
- Feiler å validere for lengde, rekkevidde, format og type
- Velger feil dataformat for forretningsentitiene
For innloggingsfunksjonaliteten er blant annet exception management, validering og sikkerhet en viktig del av verifiseringen for nettsiden. Fungerer ikke innlogging som forventet taper virksomheten lønnsomhet ved nedetid. Enhetstester og ytelsestestes er testaktiviter som sikrer kvaliteten for funksjonalitetene.
For søk-funksjonaliteten er blant annet Exception Management, Concurrency og Transactions og Data Access viktig del av verifiseringen. Testomfanget innebærer å teste at søk-logikken blir validert. Om logikken feiler så gir det misfornøyde kunder samt tape inntekter. Enhetstester er testaktivitet som sikrer kvaliteten for en slik funksjonalitet.
3. Data aksess lag – Administrerer og forenkler tilgang til data som er lagret i en persistent database. Typiske utfordringer i dette laget er:
- Dårlig håndtering av ekstremt store XML-datasett
- Feilier å validere og begrense datafelt
- Dårlig håndtering av Exception for Datatilgang
Formålet er å forhindre feil på kommunikasjonen fra klient og webserver til databasen.
4. Applikajsonstjenestelag – Administrerer kobling og logikken for betalingstjenesten. Formålet er å forhindre feil at nettsiden alltid er koblet til Nets eller Vipps og betalingen blir gjennomført for riktig bruker. Test at applikasjonen håndterer bestillinger, beregning, tillegg av merverdiavgift. Integrasjonstest må blant annet teste at koblingen til betalingstjenesten er som forventet til en hver tid.
Ytelsestest må sjekke at API-laget håndterer maks antall betalinger fra brukere i løpet av en bestemt dag og at betalingen ikke timer-ut når loggene til databasen er full.
Les mer: Hvordan lykkes med smidig testing i dagens IT-prosjekter?
Kvalitet bygges inn, den testes ikke inn
Det første alle må erkjenne er at kvalitet bygges inn, den testes ikke inn. Test verifiserer kun applikasjonen, test reduserer ikke risikoen som vi ikke kjenner til fra før. Hensikten er å oppdage feil tidlig ved å skifte fokuset til venstre i utviklingsløpet. Dette sparer ikke bare penger, men det sparer også for massevis av arbeid når feil oppdages tidligere.
Les mer: Bygg en testkultur som sørger for kvalitet i leveransene
For å kjenne risikoene for applikasjon, så krever dette at hele teamet lærer å tenke kritisk rundt forretningsverdi og kundeverdi. Følgende spørsmål må stilles; “Trenger vi virkelig dette?” og “Kan vi løse dette problemet på en enklere måte?” til “På hvilken måte kan dette brukes til å forårsake risiko?” og «Hvilke kriterier må oppfylles for at dette skal mislykkes?».
«Kjenn risikoene og feil kjapt»
En arbeidskultur eller beste praksis må bli integrert del i hverdagen for leveranseteamet. De må gjennomføre risikovurdering for hver modul, tjeneste og API de utvikler. Når utfallet er kjent så må planen aktiveres for å reduserer risikoen gjennom å kombinere aktiviteter fra både frontend test og backend test. Høy kvalitet i IT-leveransen er mulig dersom teamet finner akseladden i testregnskapet.