Våg mer med automatisert testing!

På samme måte som en fjellklatrer må en utvikler ofte utfordre sine egne grenser for å komme fram til målet. Men det er vanskelig å nå toppen hvis klatreren ikke stoler på sikringen. Der fjellklatrere bruker tau og bolter, kan utviklere stole på automatisert testing.

Et utviklingsprosjekt handler om å innføre ny funksjonalitet. Jo større og mer uoversiktelig systemet er, desto mer skremmende kan det være å innføre ny funksjonalitet.

Utviklere kan bli redde for å innføre nye feil – enten i selve koden de leverer, eller i form av følgefeil som kan dukke opp helt andre steder. Frykten kan gå utover leveransefart og lyst til utprøving av nye ting som kan øke kvaliteten.

Endringsvillighet

Utviklingsprosjekter kan lande i en situasjon hvor testing av ny funksjonalitet tar for lang tid.  Konkurransedyktighet innenfor programvareutvikling handler om å raskt kunne tilpasse seg endringer. Forretningsmuligheter kan forsvinne fordi man ikke klarer å levere raskt nok.

Innenfor programvareutvikling er testing av løsningen prosjektets sikkerhetsutstyr. Sikkerhetsutstyret bør være i orden og enkelt og bruke for at de som gjennomfører prosjektet skal kunne yte maksimalt.

Tester kan gjennomføres både manuelt og automatisk. Egenskapene til en test avgjør om den egner seg for automatisering. Mulighetene er flere enn det mange tror. Felles for automatiserte tester er at et klokt oppsett av slike tester gir rask tilbakemelding om at innføring av ny funksjonalitet ikke har endret oppførselen til eksisterende kode.

Enhetstesting

Enhetstester er en type tester som egner seg godt til automatisering. I moderne programvareutvikling har denne typen testing blitt svært vanlig. Enhetstester handler å lage tester som tester små individuelle biter av funksjonalitet. Det fokuseres på at det som kodes gjøres riktig- “Do the thing right”. Automatiserte enhetstester skal kunne kjøres igjen og igjen, potensielt flere ganger i timen, uten at dette belaster utviklerens tid. Dette gir fordeler som rask tilbakemelding på feil tidlig i utviklingsløpet. Utvikleren føler seg trygg og kan levere fra seg nyutviklet funksjonalitet i god fart.

Funksjonell testing fokuserer ikke på hvordan løsningen har blitt implementert, men at den løser det som er planlagt – “Do the right thing”. Slik testing har tradisjonelt vært manuelt arbeid. Dedikerte testere undersøker om programvaren virker som det skal. For utforskende testing er dette absolutt det beste. Men mange funksjonelle tester kan automatiseres.

Automatisering av tester

Automatisering egner seg svært godt for funksjonelle tester som repeteres ofte. Dette frigjør tid til å lage nye tester og gjennomføre annen type testing. Ved å automatisere en funksjonell test kan du garantere at den gjennomføres likt fra gang til gang og ikke minst at kjøringen av dem vil gå raskere enn hvis man skulle gjort dem for hånd. Alt dette er med på å øke kvaliteten og farten på testingen og gir dermed større trygghet for at løsningen man lager er av god kvalitet.

Mange utviklere skriver enhetstester av vane og det er heller ikke uvanlig at utviklere tar initiativ til å prøve ut verktøy for automatisering av funksjonelle tester. Men dessverre nedprioriteres denne typen aktivitet når tiden i prosjektet ikke strekker til. Man tror at man  kan man klare seg uten fordi det allikevel er allokert manuelle testere til prosjektet.

Forankring hos ledelsen

Vi ser at for å nå fjelltoppen må automatisert testing forankres hos prosjektledelsen. En prosjektledelse som ikke gjennomfører en god strategi for automatisert testing kan sammenlignes med den franske klatreren, Alain Robert (Edderkoppen). Denne kjente klatreren klatrer på bygninger uten sikring. Alain vet at den minste lille feil han gjør kan føre til  katastrofen.

Har man en god kombinasjon av automatiserte enhetstester og funksjonelle tester er man godt rustet for å nå fjelltoppen. Feil blir raskt fanget opp, akkurat som tauet redder klatreren fra å falle i bakken. Derfor kan man tørre å utforske og implementere nye ting som kan gjøre løsningen bedre.

2 Comments

  1. Bra artikkel.., jeg liker sammenligningen med fjellklarting.

    Jeg vil derimot advare mot at man forventer å få forankret bruk av automatiserte tester i prosjektledelsen. Profesjonelle utviklere tar selv ansvar for å bruke enhetstesting, det bør være en naturlig del av det å utvikle software, ikke noe man må få tillatelse til å drive med. Selvsagt er det bra om ledelsen har forståelse for dette, men det er som regel utviklerne som må gi dem denne forståelsen.

    Og om de ikke har det så er det heller ikke noe de burde blande seg opp i. Vi bør se på det å ikke bruke automatisert testing som uforsvarlig utvikling.., ikke noe vi som profesjonelle utviklere bør være oss bekjent av.

    • Jeg ser poenget ditt. Gode utviklere har automatisert testing som en naturlig del av sitt håndverk. Vårt poeng er egentlig at dette ikke er tilstrekkelig, sett fra organisasjonens ståsted. Et eksempel er utviklere som ikke skriver automatiserte tester. Her bør ledelsen inn med opplæring og oppfølging. Et annet eksempel på manglende forankring er ledelse som ber utviklerne kutte automatiserte tester, av hensyn til kortsiktige besparelser.

      Ledelse og utviklere må spille på lag. Dyktige ledere forstår hvorfor utviklerne følger sine praksiser, og de ser hvilke gevinster dette gir.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s