Testing

Vel, du vil ikke ha åpenbare feil. Å slippe raskt betyr ikke at vi må slippe noe som bryter applikasjonen eller ser dårlig ut.

Å teste noe før utgivelse er en god ide. Testing er som med alt annet – et stort tema, og det finnes forskjellige skoler om hvordan man gjør det. Vi snakker tydeligvis ikke om en "testing-fase" her, som i gammeldags prosjektstyring.

Å vente med testing til slutten av et prosjekt kan virke latterlig i dag, men det var en vanlig praksis og er det fortsatt i mange Waterfall-prosjekter. Heldigvis har de fleste gått videre. Å vente med testing og utviklerne har gått videre og glemt det, og det er nesten et nytt prosjekt å fikse alle småtingene.

I dag bruker selskaper kontinuerlig testing, som må skje i en testingmiljø før billet/story/fix går til produksjon (slippes).

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

I mange utviklingsprosesser koder utvikleren noe, tester litt på sin lokale datamaskin og så committerer koden og lager et Pull Request for peer review (i beste fall). Da er det i testingmiljøet.

Her liker noen utviklere å overlate til en QA (Quality assurance)-team som tar over testingansvaret og "sørger" for at det har "riktig kvalitet". Dette ser bra ut på papiret. Ikke gjør det! I det minste ikke på den måten.

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