Testledelse i endring

Vi mennesker utvikler oss kontinuerlig og det påvirker måten vi løser oppgaver og utfordringer på over tid. Vi leter stadig etter bedre måter å utvikle produkter på, og å opprettholde eller forbedre tjenester. Men hvordan vet vi om noe er bra nok? Hvordan vet vi om noe kan bli enda bedre? Eller enda mer presist: Hvordan vet vi om et produkt imøtekommer sin kravspesifikasjon eller sitt brukerbehov? Svaret er nok ganske innlysende for de fleste: Vi må teste.

Test har eksistert i ulike former til alle tider, fordi det rett og slett er en grunnleggende nødvendighet. Ville du blitt med på tur i et fly du visste ikke har blitt testet? IT-bransjen er intet unntak. Siden tidens første pc så dagens lys, har omfattende testing vært en grunnleggende faktor for suksess. Men som alt annet har også testing og testmetodikker i seg selv utviklet seg i takt med industrien ellers. Nye modeller og ny metodikk for prosjektgjennomføring bærer med seg endringer også i hvordan vi tenker test, og det gjelder å henge med i svingene.

Vi i bspoke sverger til veletablerte rammeverk og metodikker, og vi er nøye på å til enhver tid ha testledere som er oppdaterte og sertifiserte i faget sitt. Det vi også er genuint opptatte av er å ta lærdom av erfaring. Mindre av det som ikke fungerer så bra, og mer av det som fungerer godt. Derfor lager vi vårt eget «Beste praksis»-rammeverk som ivaretar essensen i de mer etablerte rammeverkene, men som også tar i bruk og nyttiggjør den kompetansen og erfaringen som bspoke innehar internt. Sammen blir dette dynamitt. Det gjør oss smidige, dynamiske, fleksible og konsekvente. Det gir oss et håndfast utgangspunkt som kundene våre nyter godt av. Det er også gull verdt for nye testledere som er på vei inn til oss og skal gjennom vårt onboarding-program.

Den gode, gamle fossefallsmetodikken er fremdeles en høyaktuell, nyttig og nødvendig metode for prosjekter som ved start har klare krav til leveransen. Sluttbrukerbehovet er klart, og kravene til produktet er klare. Designdokumenter må lages, utvikling skal gjøres, testing skal planlegges og gjennomføres. Beviset på god nok testing: En sluttrapport som dokumenterer tilfredsstillende testdekning og et tilfredsstillende resultat sett opp mot kravspesifikasjonen. Men, og dette er et ganske stort «men», dagens sluttbrukere forventer raskere leveranser, mer tilpasset funksjonalitet og et til enhver tid oppdatert produkt. Hvor enkelt er det når en komplett leveranse fort kan ta fra 6 måneder og mer å gjennomføre? Det sier seg selv at det er for sakte. Fossefall favner fort de store og rigide prosjektene, og er lite egnet for raske leveranser. Dette behovet har produsert nye metoder som legger opp til en smidigere og mer agil tilnærming til både utviklingen, testingen og leveransesettingen. Design, utvikling, test og prodsetting går i kortere iterasjoner med mindre omfang. Det igjen kan gjøre det endelige målbildet mer uklart, men veien dit er bredere og mer tilpasningsdyktig.

Så, er den ene metoden bedre enn den andre? Må det være enten eller når det kommer til valg av metode? Er det mulig å kombinere disse metodene? Fossefall med en smidig tilnærming? Det kommer helt an på prosjektet og hva som faktisk skal leveres. Om veien til mål er bredere, har den kanskje også noen ekstra fallgruver. Når målbildet ikke er klart definert, kan det være vanskelig med forutsigbarhet. Lav forutsigbarhet vanskeliggjør estimeringer for både total tidsbruk og kostnader, og det kan være vanskelig å sette en måldato – når er prosjektet ferdig? Uten dette klare målbildet er det også fare for at sluttproduktet ikke blir helhetlig nok. Mange kokker, flere mindre leveranser, uklar styring og et diffust målbilde kan fort ende opp med et sluttprodukt som ikke ivaretar helheten, og rett og slett blir for fragmentert.

Hva har alt dette med test og testledelse å gjøre spør du? Veldig mye, svarer jeg da. Selv om metoder for prosjektgjennomføring endrer seg, er det grunnleggende målet for test stadig det samme: Sørge for et kvalitetssikret sluttprodukt som imøtekommer krav og kundebehov. I et smidig løp vil testing være noe som typisk gjennomføres i alle deler av en iterasjon, og således vil testleder ha et ansvar for at helheten ivaretas. Det som er verdt å merke seg er at smidige metoder stiller krav til høyere teknisk kompetanse hos testleder enn tidligere. Det stiller høyere krav til regresjonstesting grunnet mange endringer i produktet underveis, og med det melder behovet for testautomatisering seg også i større grad mens prosjektet løper. I smidige prosjekter er ikke lenger testleders jobb å planlegge og forberede en dedikert periode for akseptansetesting, men å planlegge, tilrettelegge og koordinere test gjennom alle fasene og iterasjonene i prosjektet. Da handler det ikke hovedsakelig kun om høy testdekning og stor andel av automatisering, men det handler om å tilpasse testingen og gjøre også denne delen mer smart og smidig. Smidig testing kan summeres opp med følgende punkter:

• Software testing
  1. Risikobasert testplanlegging
  2. Sprinttestplanlegging
  3. Regresjonstesting
  4. Utforskende testing (feilgjetting)
  5. Akseptansetesting
  6. Release planlegging

Grunnlaget for testing legges med risikobasert testplanlegging. Legg til rette for treffsikker og effektiv testing med begrenset testtid. Sprinttestplanlegging med utvikling av test caser, regresjonstesting, utforskende testing og planlegging av produksjonssetting kommer etter hvert som produktet eller tjenesten utvikles.

• Utvikling og automatisering
  1. Praktisere Test Driven Development (TDD), Behaviour Driven Development (BDD) eller Acceptance Test Driven Development (ATDD)
  2. Kodekvalitet som er basert på testnivåene (testpyramiden)
  3. Visuell presentasjon av kodekvalitet
  4. Kontinuerlig integrasjon

Her legges grunnlaget for å forhindre feil. En stabil og godt kvalitetssikret løsning er og forblir en kritisk suksessfaktor. For å lykkes med dette punktet er man helt avhengig av at utvikler tester sin egen kode og ikke legger alt ansvar for test på testeren alene. Koden som utvikles skal automatiseres for test i henhold til risikoanalysen og teststrategien. Testautomatisering muliggjør effektiv testing i alle deler av et system på en systematisk og komplett måte. Testautomatisering er også viktig for å kunne håndtere teknisk gjeld.

• Team praksis
  1. Kodegjennomgang og bra enhetstestdekning
  2. Praktisere Definition Of Done
  3. Test tidlig, test ofte og test nok
  4. «Stop the line»-mentalitet
  5. Praktisere teknisk gjeld – jobbe kontinuerlig med teknisk gjeld

Det er viktig for ethvert prosjekt å bygge gode og effektive team. Et godt utgangspunkt kan være å basere seg på smidig testing manifesto, og praktisere punktene over for å etablere et bra testregime og god testkultur i prosjektet.

Smidig testing manifesto kan oppsummeres med følgende tankesett:

Smidig testing manifesto går hånd i hånd med smidig utvikling manifesto:

Monitorering og overvåking skjer gjennom alle faser og gir løpende informasjon om produktet eller tjenesten. Her kan man få viktige tilbakemeldinger om produktet som må håndteres videre.

En helhetlig tilnærming er det viktigste

For å ikke miste helheten når vi arbeider smidig er det med andre ord viktig at vi også tester smidig. Når det testes i alle ledd, er det også alles ansvar å ivareta kvaliteten. Dette er en måte å tenke og jobbe på som kan være krevende for mange, men et team som forstår og mestrer metoden vil også være tryggere på en leveranse som ivaretar kravene til kvalitet og helhet. Det være seg i prosjekter som benytter fossefallsmetoden, prosjekter som baserer seg på en smidig tilnærming eller i prosjekter som har elementer av begge deler i sin strategiske tilnærming.