Mitt nyttårsønske: Bedre spesifikasjon!
Jeg har jobbet på forskjellige prosjekter i en årrekke som alle følger en eller annen form for smidig metodikk med høyt fokus på kvalitet (i hvert fall på papiret). Til tross for oppstartsmøter, kodegjennomganger, testdrevet utvikling og andre triks, oppdager jeg likevel feil i funksjonaliteten som leveres. Feil som ofte er av en slik art at jeg blir ganske satt ut eller overrasket. Nå er jeg heldigvis en person som er ganske optimist av natur, men jeg har sett mye rart.
Hvorfor finner jeg feil?
Svaret på dette kan bli en hel bok, men jeg liker å fatte meg i korthet. I 95% av tilfellene skyldtes det ene og alene spesifikasjonsansvarlige! Til tross for at mange vet at man ikke skal skrive én linjes kravspesifikasjoner på ny funksjonalitet eller ved endring av eksisterende funksjonalitet, så er det ofte det som faktisk skjer. Man har ikke tid, man har ikke nok kunnskap på det tidspunktet, man skal sjekke med noen osv. Unnskyldningene kan være mange. En annen årsak kan være at man skriver for mye spesifikasjon, og utvikleren nesten drukner i informasjonsstrømmen. Den typen spesifikasjon vil jeg også kalle mangelfull. Selv om mye er skrevet ned mangler det ofte konkret informasjon om hva som er tenkt laget, samt hva det skal gi av verdi og akseptansekriterier.
I prosjektene jeg er i har jeg ofte stilt spørsmål om hvorfor dette skjer. Ofte kan det skape en del misnøye fordi mange tolker det til at jeg mangler forståelse for deres hektiske arbeidshverdag (eller at de får dårlig samvittighet). Jeg ønsker ikke å skape dårlig stemning, men belyse at noe må gjøres for at alle skal få en bedre jobbhverdag. Men før vi er der…
Hvorfor godtar vi en mangelfull spesifikasjon?
Dette spørsmålet har jeg ofte stilt til utviklerne. Hvorfor sender de bare ikke oppgaven tilbake? Av og til er vi nok bare utrygge i vår rolle — og later som vi har skjønt noe vi rett og slett ikke forstår. Og av og til er det lagt opp til at utviklingsfasen skal bestå av at utviklerne selv skal få klarhet i hva som er nødvendig å få på plass (skal utviklerne se inn i krystallkulen og finne ut hvordan løsningen skal bli i fremtiden?). Vi er jo så smidige, hehehe 😉
De dyktigste utviklerne, som ofte har vært på et sted lenge nok, kjenner folk de kan spørre. Er du heldig kan du få en noenlunde god forklaring som kan gi en mulig løsning. Her vil jeg be mine venner på utvikling om å brette opp ermene og legge inn en god spesifikasjon på funksjonalitet de jobber med. Hvis ikke dette blir gjort står vi på test ovenfor et nytt spørsmål…
Hvordan skal vi teste dette?
La oss si at vi får en sak til test sammen med en linje eller to, eller et langt dokument for hva som skal gjøres. Er tanken da at vi skal bruke en halv dag (eller mer) på å lese oss opp i alt som står i dokumentet? For så å trekke ut akseptansekriterier og verifisere at saken er implementert korrekt? Skal jeg ta en runde bakover og høre med alle involverte? Hva om jeg er av den litt usikre og forsiktige typen som ikke vil fremstå som en som ikke forstår? Frustrasjonen fra utvikling har nå flyttet seg over på den som skal teste. Før saken havner hos test, har den vært til kodegjennomgang. Ofte har også de som er ansvarlig for kodegjennomgangen også hatt utfordringer knyttet til dårlig eller manglende spesifikasjon. Av og til ender det med at saken godkjennes og sendes videre til test på feil grunnlag…
Vi i test pleier å gå helt tilbake til brukeren som opprinnelig ønsket funksjonaliteten og tar en prat om hva som var ønsket i første omgang. Ofte finner vi ut at det har oppstått misforståelser som må rapporteres inn som feil. Saken sendes så tilbake til utvikleren som igjen må ta en diskusjon med bestiller. Allerede nå har vi brukt x antall timer unødig… minner meg litt om et foredrag jeg holdt om “Hvordan unngå at kravspesifiserering blir en hviskelek i dag og i fremtiden” på Software2017, og vi er vel ikke blitt noe bedre siden da?!
Hvordan forbedre spesifikasjonen?
Én løsning kan være å involvere flere roller inn mot kvalitetssikring av spesifikasjonen FØR denne overleveres til utvikling. Her er det veldig viktig at dette ikke innføres på en ufornuftig måte. For eksempel hvis du skal spesifisere en enkel endring av et felt eller en regel, så trengs det ofte ikke en kvalitetssikringsrunde.
Men det finnes unntak. La oss se for oss et eksempel hvor ett enkelt felt skal endres. Den som ønsker endringen (spesifikasjonsansvarlig), oppretter et endringsønske i for eksempel Jira. Men la oss si at vedkommende kun legger inn en setning i Jira-saken. Ofte inneholder den ene setningen kun en referanse til et større dokument med mye annen informasjon — som kommer i tillegg til informasjonen på hva som ønskes endret i det aktuelle feltet.
Når denne Jira-saken sendes videre til de som skal implementere endringen, må disse tørre å sende den tilbake slik at spesifikasjonsansvarlig kan legge inn nødvendig informasjon i klartekst i Jira-saken. Dette for at alle som senere skal jobbe med Jira-saken skal unngå å måtte lete opp informasjonen fra det store dokumentet som refereres til. I dette eksempelet vil det være nok å legge inn en setning om hvilke felt/regel som skal endres med “fra verdi” og “til verdi”. Ta gjerne med hvorfor endringen ble utført, sammen med en skjermdump av hvor feltet ligger. Hold beskrivelsen og bakgrunnen til endringen kort og konsis. Legg inn akseptansekriterier som testressursene kan ta en avsjekk mot. Denne jobben bør ikke ta mer enn 15 min.
Ta en sjekk på at dere belyser følgende spørsmål:
· Hvorfor skal vi ha denne endringen?
· Hva går endringen ut på?
· Hvilke brukere/grupper påvirkes av endringen?
· Hvilke kriterier må sjekkes før endringen aksepteres?
Mange av oss jobber med Jira eller tilsvarende systemer. Jeg anbefaler å ha regler knyttet til hvor lang teksten i beskrivelsesfeltet skal være. Bruk vedleggs-funksjonalitet og legg ved figurer. Ha obligatoriske felter for akseptansekriterier — i hvert fall på endring eller ny funksjonalitet. Et felt for å skrive inn bakgrunn/formål for ønsket funksjonalitet er også nyttig. Er funksjonaliteten stor, kan det være nyttig å dele det opp i flere mindre saker og legge inn detaljert informasjon i de nye sakene.
Men alt jeg nevner over vil jo ikke gå hvis du ikke gjør noe med tidsklemmen du føler du er i…
Hvordan få bedre tid?
For et par uker siden automatiserte jeg 95% av funksjonaliteten i en webapplikasjon for et av mine prosjekter. Betyr det da at vi ikke trenger å teste noe manuelt? Ja nesten…Når vi nå får en endring i applikasjonen kjører vi bare de automatiske testene fra Jira og har resultatet på endringen i løpet av 12–15 min. Tidligere har vi måttet teste i flere dager før vi kunne verifisere at eksisterende funksjonalitet fortsatt fungerte som forventet.
Hva gjør vi da? Vi har jo spart opp en del tid. De som tidligere brukte flere dager på å teste kan nå bruke tiden til å kvalitetssikre spesifikasjon knyttet til nye endringer og behov. Dette fører til at utvikleren sparer tiden som vedkommende hadde brukt på å gruble og grave for å få ut en mer eller mindre korrekt løsning. Test vil også vite eksakt hva som kreves og kan planlegge nye automatiske tester ved behov, eller vurdere endringer i eksisterende. Vi vil mest sannsynlig ikke få noen overraskelser knyttet til feilprodusert funksjonalitet.
For år 2023 er mitt råd til utviklerne der ute: skjønner du det ikke, send det tilbake. Oppdager du noe som påvirker endringen eller at man forstår den bedre, skriv det ned i saken og tagg den som ønsket endringen i første omgang. Da gjør du både deg selv og de som kommer etter deg i løypen en tjeneste. God jul og godt nyttår 😊
PS: ønsker du nye utfordringer i 2023, klikk her og ta en titt på hvilke muligheter du har i Systek
