Hvordan bør man kommunisere med forelesere når man tester et program som er i en tidlig fase?

Det viktigste rådet her er å kommunisere tydelig til foreleseren at programmet er i en supertidlig fase, og at det kan slutte å fungere av tilfeldige årsaker – dette er en helt naturlig del av testprosessen. Grunnen til at dette er så viktig, er forventningsstyring. Når dere ærlig forteller hvilken modenhet løsningen har, oppfatter ikke foreleseren feil og krasj som inkompetanse, men som forventet oppførsel i en eksperimentell fase. Det bevarer både tilliten og foreleserens velvilje til å fortsette å teste for dere.

La oss sette dette i sammenheng. Det dere driver med er brukertesting: dere lar reelle brukere prøve produktet for å oppdage feil og forstå hva som fungerer. En tidlig versjon kalles ofte en prototype eller MVP (Minimum Viable Product – den enkleste fungerende versjonen som likevel gir nok verdi til at noen kan teste den). I denne fasen er feil og krasj ikke et nederlag, men selve poenget: hver feil dere finner nå, er en feil sluttkundene slipper å oppleve senere.

Konkret kan dere kommunisere slik: 1) Si tydelig før testen starter at dette er en veldig tidlig versjon og at ting kan krasje. 2) Forklar at nettopp derfor er tilbakemeldingene deres uvurderlige. 3) Gjør det enkelt å rapportere feil – be foreleseren beskrive hva de gjorde rett før noe gikk galt, og gjerne ta en skjermdump. 4) Følg opp med en takk og fortell gjerne hva dere fikser basert på innspillene; det gjør folk villige til å teste igjen. En vanlig fallgruve er å overselge løsningen som mer ferdig enn den er – da blir testeren skuffet ved første krasj. Vær heller ydmyk og ærlig; det skaper tryggere testere og bedre tilbakemeldinger.