jesper a. frederiksen bloghoved

Hvis du er i tvivl... så test!

Projektets testfase(r) - det så absolut springende punkt for ethvert IT-projekt. Tidspunktet, hvor man stress-tester, at det design og at konfigurationen af de komponenter, som der er valgt, også rent faktisk virker efter hensigten i IT-brugerens virkelige verden. Den sidste mulighed for at tilpasse miljøet inden det sendes i produktion blandt hele brugermassen. Det er papirskitsen med alle dens smårettelser, der bliver vendt og drejet, før tatovøren sætter nålen på huden. 

Illustration: Privatfoto

Og sørme så, om det ikke er en fase, som i den grad bliver brugt som tidsbuffer for selve projektet som helhed. Hvis jeg havde en frossen ært, for hver gang man har set en en testfase blive afkortet, nedprioriteret eller i grelle tilfælde helt aflyst, så ville jeg have til en hel pose af de ekstra fine af slagsen fra Irma…

Det er ikke fordi, jeg er ude i et pege-fingre ærinde her - mit ønske er simpelthen at forstå den projektmekanik, hvor målet - eller deadlinen - for projektet bliver så bestemmende for om et projekt vurderes som en succes eller ej, at man tænker, at man “da ikke lige behøver at teste om tingene virker helt rigtigt” før man sætter streg under resultatet og sætter skibet i søen. Nu kan det godt være, at det kommer som en overraskelse for nogen; men de fejl eller uhensigtsmæssigheder, som man ville være stødt på i en testbrugerfase, de forsvinder altså ikke af, at  man springer testfasen over… Så dukker de bare op for ALLE brugere i produktionsmiljøet i stedet for.

En klog herre har tidligere fået mig til at prøve at forstå de finere nuancer af IT-budgetternes verden, hvor man kan spare lidt på projektets budget og så lade det “gå ud over” driftsbudgettet bagefter - lade det stå for at få tingene rettet op, for nu er miljøet jo i produktion… Og her må jeg ganske enkelt kaste håndklædet i ringen. Så må der simpelthen skabes noget bedre kommunikation mellem projekt- og driftsorganisationen i virksomheden - også omkring økonomi. Basta! Den slags organisatorisk dysfunktionalitet skal man ganske enkelt til livs. Ét er at bede en håndfuld eller 20 testbrugere om at bruge tid på at melde eventuelle fejl ind; men at udsætte hele organisationen for det er direkte respektløst for disse sagesløse IT-brugerers tid og arbejde. For slet ikke at tale om risikoen for en markant tabt effektivitet.

Eller det er måske mig - min alder og erfaring til trods - der er tilpas naiv til at tro, at et af formålene med at iværksætte et nyt IT-projekt i en organisation er, at det så også skal virke efter hensigten, når det er i leveret i produktion…

Så hvis du sidder derude med en idé om, hvorfor det er, at projekttestfaserne ikke får den opmærksomhed de bør - eller hvis verden ser helt anderledes ud og observationerne oven for er helt skudt ved siden af; så råb endeligt højt og giv dit besyv med… Jeg har altid fået indprentet, at lidt sved i klargøringen altid er at foretrække fremfor blod i selve gennemførelsen; men jeg kunne jo tage fejl…

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup

Vi har ikke en stor tastfase til sidst. Inden vi overhodedet går i gang med at programmere, har UX testet de vigtigste brugerflows med mockups.

Problemet bliver også mindre grelt da vi arbejder agilt og releaser hver 14. dag, nogle gange oftere.

Vi har et flow hvor QA løbende tester del-opgaver der bliver meldt færdige (styret via Jira)

Når vi releaser oftere, kan vi også hurtigt lave on korrigering, hvis vi alligevel har forregnet os og brugerne ikke kan lide hvad vi har lavet. Nøglen er at reagere hurtigt, i stedet for at tro at vi kan regne det hel ud før vi releaser.

En sjælden gang i mellem når vi har en feature der har strukket sig over flere sprint (28 dage+), laver vi en bugbash, hvor hele teamet at QA'ere og udviklere i et par timer tester applikationen og rapporterer alt hvad der er "mærkeligt" ind.

Dertil kommer at flere (ikke-programmør) personer i virksomheden, løbende sidder af afprøver det seneste vi har lavet og giver feedback, inden det releases.

  • 2
  • 0
Jens Rasmussen

At man først tester foer man 'smider det over hækken' er en opskrift på forsinkede eller dårlige resultater.

Forestil dig at NASA først testede raketter før de skulle i produktion. Det ville være dyrt at skulle begynde forfra hver gang. For software er resultaterne mindre åbenlyse, men det giver stadig problemer.

Naar man så ovenikøbet afkorter testfasen, saa kan det kun gå galt.

  • 1
  • 0
Jesper A. Frederiksen

Super relevant - kunne være, at vi systemkonsulenthuse skal lære (endnu) mere af de metodikker, som I anvender inden for softwareudvikling. I hvert fald at få indlejret testforløb og ufravigeligheden af disse i højere grad, end det sker i dag.

Men der ligger også en opgave i at forventningsafstemme blandt alle i projektorganisationen, helt præcist HVOR vigtigt det er. Tror det er lettere for folk generelt at forstå, at et decideret produkt skal testes ordentlig af inden det sættes i produktion - den forståelse oplever jeg ikke er lige så naturlig, når vi taler system implementeringer.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize