Bedre, raskere og billigere testing
Nye leveranser av IT-systemer skal leveres hyppigere enn tidligere, samtidig som graden av kompleksitet knyttet til IT-systemer krever at man har bedre kontrollmekanismer enn tidligere. Stadige økende behov for effektivisering og innsparinger, stiller høye krav til oss i denne bransjen. Kontroll av leveranser er ikke noe som kommer av seg selv, men krever god testutførelse. Jeg vil i denne artikkelen gå gjennom noen av de viktigste elementene som kan bidra til å gjøre testingen bedre, raskere og billigere.
Still høyere krav til testlederen
Altfor ofte ser man administrative testledere som kun produserer teststrategier, testplaner og testrapporter. Arbeidet de gjør under en testperiode består hovedsakelig av å delegere testoppgaver og følge med på innrapportering av feil. Jeg mener ikke at dette er totalt unødvendig, men dagens testledere må heve seg over dette. En testleder i dag må være mer deltakende og mer tilstede i alle faser av prosjektet, særlig der det brukes smidige arbeidsmetoder.
Testledere fra Systek forteller at de ofte ender opp med å bli fageksperter på flere områder og dermed raskt kan bidra med å utarbeide og kvalitetssikre krav og brukerhistorier. Én av årsakene til dette er at de utfører testoppgaver som tidligere kun var tiltenkt testere i et testteam. Istedenfor å være en sjef bør testlederen være en leder som er med på å dra lasset. Ved å komme nærmere IT-systemene får testlederen kunnskap om blant annet hvilke deler av systemet som er tidskrevende å teste, hvilke deler som er komplekse, hvor risikoen for feil er størst.
Innfør automatisert test, men stopp og analyser!
I veldig mange prosjekter jobber testteamene forholdsvis atskilt og et samarbeid på tvers av testteamene (feks systemtestteamet og akseptansetestteamet) er totalt fraværende. Dette fører til at man stadig vekk ender opp med dobbeltarbeid og dermed mister tid som kunne blitt brukt på å oppdage feil i systemet under test i stedet for at unødvendig mange feil blir sendt videre til produksjon.
La oss anta at man har et system som beregner priser for diverse varer avhengig av valgt valuta. Leverandøren av systemet har laget en rekke tester for å beregne priser på diverse varer med diverse valuta. Når dette systemet kommer til systemtest eller akseptansetest ser man altfor ofte at tiden igjen brukes til å kvalitetssikre beregningen fremfor å verifisere andre aspekter av løsningen på grunn av at man mangler kunnskap om automatiseringen som muligens har blitt utført på enhets- eller komponentnivå. Noen testteam har i lang tid også automatisert test av GUI og beklageligvis ser man at det ofte utføres unødvendige automatiske tester på deler som er godt testet på lavere nivå. Dette kan løses ved at man analyserer de automatiske testene og innfører testautomatisering på en slik måte at man får produsert vedlikeholdbare og effektive tester.
Automatiske tester som blir produsert på komponentnivå, kalt enhetstester, er billigere å produsere og enklere å vedlikeholde enn tester produsert i lagene høyere opp. Fokuser derfor på å ha flest mulig tester på komponentnivå og færrest mulig på GUI nivå. Be derfor alltid om å få en rapport fra testkjøringene slik at det kan hjelpe deg med å analysere videre automatisering.
Figuren under viser fordelingen av automatiske tester på forskjellige nivåer sett opp mot mengden manuelle tester som blir kjørt. Iskrem-modellen beskriver en situasjon som vi stadig møter på i prosjekter. Ofte har man hatt en stor mengde med enhetstester, men disse har etterhvert blir fjernet eller kommentert bort fordi man ikke har holdt disse oppdatert i henhold til nye endringer på systemet. I slike prosjekter støter man også gjerne på mange manuelle testscripter som kjøres for hver leveranse. Mengden med “testomfang” øker i slike prosjekter høyere opp. Vi mener at man bør kunne snu denne trenden og gå fra en iskrem modell til en pyramide-modell. I en pyramide-modell er situasjonen snudd på hodet. Man har en stor mengde med kjørbare og oppdaterte enhetstester som tester en stor del av systemet, etterfulgt av en mindre mengde med automatiske integrasjonstester og automatiske gui tester. Et annet aspekt som bør nevnes er tidsbruk knyttet til testkjøringer. Ønsker man å ha raske leveranser med korte testperioder, er pyramide-modellen å foretrekke fremfor den litt utdaterte men mer populære iskrem-modellen.
Velg korrekt verktøy
Når dere skal velge verktøy for automatisering av test er det flere aspekter som må vurderes.
Har dere eget utviklingsteam eller skal systemet overtas av en drift- og vedlikeholdsavdeling?
Skal systemet brukes av få eller mange brukere?
Kommer systemet til å endre seg betraktelig i nærmeste fremtid eller være stabilt?
Slike og andre spørsmål må vurderes spesielt før man går til innkjøp av et verktøy for automatisert test av GUI. Det er også viktig å sjekke ut:
- Hvor anerkjent verktøyet er i markedet?
- Hvordan er supportsystemet?
- Hvor lenge skal en automatisert test leve?
- Hvor mange ganger vil testen bli kjørt?
- Hvor lang tid sparer man for hver kjøring?
- Priser for lisenskostnader opp mot faktisk besparelse
Det er også viktig å velge verktøy som enkelt kan integreres sammen med deres byggesystemer og rapporteringsverktøy. Mange av verktøyene krever ikke noe spesialkompetanse og flere leverandører av slike verktøy prøver å inkludere AI i sine verktøy. Slike forutsetninger vil føre til økte kostnader og vi har også erfart at prisene har doblet seg fra år til år. Velg et verktøy for automatisert test som tilfredsstiller deres krav idag, men lag testene slik at de etter en tid kan erstattes med nye tester laget med et helt annet verktøy. Som alle andre ting i universet har også en automatisert test en gitt levealder.
Innfør påkrevd eksperimentell manuell testing
Som en konklusjon kan man si at tester som følger en gitt bruksanvisning eller beskrivelse bør kunne automatiseres og testerne i de forskjellige fasene bør og skal utfordres til å utføre eksperimentell testing. Det er på denne måten man finner nye feil i et system. Dette kan illustreres ved å følge en sti gjennom et skogholt, hvis du følger denne et gitt antall ganger i blåbærsesongen, vil du ende opp med å plukke med deg alle blåbærene som befinner seg i nærheten av denne stien. Men siden ingen av oss drar på blåbærtur på denne måten, anbefaler jeg dere alle til å sende ut testerne deres på en eksperimentell reise inn i systemet. Alle feil som oppdages under test er en besparelse.
Oppskriften på bedre, raskere og billigere testing er deltakende testleder, smartere automatisering og eksperimentell testing!
Lykke til!
