Kender du det? Systemet er bygget, det kan i grove træk det, det skal kunne, men undervejs glippede det med kvaliteten og der er alt for mange (kritiske) fejl.
Det kan der være flere årsager til, f.eks.:
- Tidspres
- Manglende teststrategi
- Dårligt kravgrundlag
- Ufuldstændig dokumentation
- Dårlig eller ingen sporbarhed, der fører til mangelfuld testdækning
- En af de agile faldgruber; fokus er udelukkende på den enkelte user story og aldrig på produktet i sin helhed.
Særligt sidstnævnte kan være resultatet af, at vi laver et komplekst produkt med leverancer fra flere teams, der hver især har ansvar for deres eget delområde.
Når vi går på kompromis med kvaliteten, begrænser vi potentielt den værdi, produktet egentlig skulle give. Vi risikerer at ende med et produkt, der er besværligt at bruge og i stedet skaber irritation – det kan overskygge det, der i princippet fungerer.
Dårlig kvalitet er uholdbart – særligt når der fortsat skal udvikles og vedligeholdes på systemet.
Vedligeholdbarhed
Når vi går på kompromis med kvaliteten, medfører det typisk teknisk gæld, fordi midlertidige eller forhastede løsninger hober sig op. Det kan have konsekvenser for, hvor let systemet er at vedligeholde efterfølgende, blandt andet fordi det bliver svært at undgå fejl, når der tilføjes ny funktionalitet – særligt hvis der ikke findes tests til at fange de fejl, der måske introduceres.
Manglende eller dårlig dokumentation kan også påvirke vedligeholdbarheden af systemet og kan være resultatet af, at viden primært ligger hos nøglepersoner. Det gør det vanskeligt for nyansatte at danne sig et overblik over det produkt, de arbejder på, hvilket yderligere gør det vanskeligt at skulle foretage ændringer eller fejlrettelser, hvis de ikke i tilstrækkelig grad forstår omfanget af ændringen.
Sporbarhed
En af vores fornemste opgaver som testfaglige er at kunne give information om kvaliteten af et produkt. Jo bedre sporbarhed vi har at arbejde med, jo mere detaljeret og konkret kan den information blive. Derudover giver det os et overblik over vores testdækning og ikke mindst kan vi mere effektivt vurdere, hvad der potentielt kan være påvirket efter en ændring, når vi ved præcist, hvad det er, vi tester og hvordan det hænger sammen med andre funktioner/komponenter.
Tunnelsyn
Når vi arbejder i agile teams, risikerer vi at arbejde i siloer, hvor fokus primært er på de enkelte user stories fremfor på den feature, de tilsammen udgør – og produktet som helhed. Vi ender vi med et fragmenteret produkt med inkonsistente brugeroplevelser, hvis hvert team blot fokuserer på, at deres del fungerer, og ikke forholder sig til, hvordan den del skal indgå i systemet eller hvilke afhængigheder, der måtte være på tværs af teams.
Hvad kan vi gøre ved det?
Helt grundlæggende skal der forankres et supplerende fokus på produktet. Det kan virke som en forholdsvis uoverskuelig opgave, men hvordan er det nu, man spiser en elefant?
Produktperspektivet skal indføres på flere forskellige parametre – én bid ad gangen.
Der bør etableres et testteam på produktniveau. Er dette ikke en mulighed, kan et alternativ være at placere ansvaret for test på produktniveau hos en repræsentant fra hvert team.
Derudover skal den, der har produktansvaret – enten forretnings- eller IT-mæssigt – have ansvaret for at skabe et overblik over (og ikke mindst dokumentere) alle produktets funktioner samt hvilke processer/arbejdsgange, det understøtter – gerne med support fra test.
Herefter kan vi:
- mappe funktionerne til systemets komponenter
- lave en produktrisikoanalyse (PRA) på funktionsområderne
- etablere regressionstest på produktet i prioriteret rækkefølge efter risikoklasse.
Når vi har et dokumenteret overblik over alle funktionsområder, skal de mappes til systemets komponenter – det vil være en opgave for arkitekter/lead developers.
Denne dokumenterede sammenhæng vil ikke mindst give værdi til (nye) udviklere, der nemmere kan få overblik over produktet og dermed nemmere forstå den kontekst det, de arbejder med, skal indgå i.
Næste skridt bør være at lave en PRA på funktionsområderne. Det vil give værdi til alle, der er involveret i udviklingen, da det vil synliggøre hvilke dele af produktet, der er kritiske. For testteamet vil det særligt give værdi i forbindelse med etablering af regressionstest på funktionsområderne med dertilhørende processer/arbejdsgange og senere i forbindelse med udvælgelse af, hvilke tests der skal afvikles når en ny feature og/eller release introduceres.
PRA’en vil derudover give input til, i hvor høj grad de forskellige funktionsområder skal dækkes med test, dermed være input til, hvilke testdesignteknikker der skal benyttes i testanalysen.
Hvordan skal vi arbejde fremadrettet?
Når vi har dokumenteret produktets funktioner, dokumenteret sammenhængen mellem dem og komponenter, lavet en PRA på dem og påbegyndt etablering af regressionstest på produktet, skal vi til at kigge fremad.
Vi skal begynde at:
- arbejde aktivt med sporbarhed mellem feature, user story, komponent og funktionsområde.
- arbejde aktivt med sporbarhed fra krav/feature til test til testresultat til bug.
- bruge testdesignteknikker tidligt.
Sporbarheden til komponenter og funktionsområder kan helt lavpraktisk implementeres som tags eller felter i opgavestyringssystemet. På den måde vil vi på enhver feature eller user story kunne se, hvilke(t) funktionsområde(r) der måtte blive påvirket af den – og planlægge vores test ud fra det.
Sporbarheden skal implementeres på alt nyt, så vi ved, hvilket krav eller hvilken feature der bliver påvirket, når vi finder en bug. Så vi ved, om vi har dækket det, vi skal.
For at vi fremadrettet og på en struktureret måde kan illustrere, hvad en feature eller et krav egentlig indeholder, skal vi begynde at bruge testdesignteknikker, inden vi begynder at udvikle. Indeholder kravet/featuren processer, vil det for eksempel være oplagt at bruge teknikken procescyklustest, når det drejer sig om arbejdsgange, eller tilstandsovergangstest, hvis det omhandler en tilstandsmaskine. Handler det om forretningsregler, vil det være en fordel at lave en beslutningstabel. Tidlig brug af testdesignteknikker vil fange fejl tidligt og bidrage til at tydeliggøre, hvad der skal bygges.
Teknikkerne giver input til test på flere niveauer – også produktniveau. Vi skal huske at jo højere niveau vi tester på, desto mere bør testen afspejle det reelle brug af systemet. Vi skal ikke genbruge de testcases, der blev udviklet for den enkelte user story – medmindre den har fokus på systemet som helhed.
Sidst men ikke mindst – drop de dårlige vaner – hellere sent end aldrig
Stop starting, start finishing – husk at prioritere fejlrettelser undervejs – hvis de konstant parkeres til fordel for nyudvikling, ophober den tekniske gæld sig, og det går ud over den grundlæggende kvalitet af systemet. Vi kan ikke forvente at skabe værdi med nye features hvis de skal eksistere i et system, der grundlæggende er af dårlig kvalitet.
Skal vi hjælpe?
Vil du høre mere om, hvordan vi kan hjælpe med at bygge kvalitet ind i jeres system fra starten af? Så kontakt chefrådgiver og områdeleder for kompetencer og viden, Gitte Ottosen, på gitte@key2quality.dk eller 4940 8552.