Testning

Nå, du ønsker ikke åpenbare bugs. Å slippe ut hurtig betyr ikke at vi må slippe ut ting som ødelegger applikasjonen eller ser dårlig ut.

Å teste noe før utgivelse er en god idé. Testing er som med alt annet – et stort tema, og det finnes ulike skoler på hvordan man gjør det. Vi snakker selvfølgelig ikke om en "testingfase" her, i stil med gammeldags prosjektstyring.

Å vente med testing til slutten av et prosjekt kan virke morsomt i dag, men det var en vanlig praksis og er det fortsatt i mange vannfallsprosjekter. Heldigvis har de fleste flyttet seg videre. Ved å vente med testing og utviklerne har flyttet seg videre og glemt det, blir det nesten et nytt prosjekt for å fikse alle de små tingene.

I dag bruker selskaper kontinuerlig testing, som må skje i en testingmiljø før billetten/storyen/fixen går til produksjon (slippes ut).

På denne måten kan vi kode funksjoner, teste dem, gi tilbakemelding, kode igjen og fortsette testing til vi er fornøyde med resultatet. Vi kan slippe ut når som helst det er klart på en funksjonsbasert måte.

I mange utviklingsprosesser koder utvikleren noe, så tester de litt på deres lokale datamaskin og så committerer de koden og lager en Pull Request for kollegarevisjon (i beste fall). Deretter er det i testingmiljøet.

Her liker noen å gi det videre til en QA ("Quality assurance")-team som tar over testingansvaret og "sikrer" at det har "riktig kvalitet". Dette ser bra ut på papiret. Gjør det ikke! I hvert fall ikke på den måten.

Les mer i "CTO Playbook" tilgjengelig på Amazon/Kindle.