Dette indlæg er alene udtryk for skribentens egen holdning.

Store huller i testen - hvad er problemet?

28. marts 2012 kl. 11:279
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Problemet er, at alt for mange systemer når ud til slutbrugerne i en alt for ringe kvalitet! Det er til gene for både slutbrugere og andre interessenter, og det koster en frygtelig masse penge. Penge, der kunne være sparet med en bedre test.

Dette blog-indlæg kunne også hedde noget i retning af: hvad er din dækning?!

Dækning er traditionelt noget, man forbinder med forsikringer; men det er også relevant for test. Dækning er et mål for, hvor meget af et system, en given test har berørt. Nogle kender til kodedækning; men det er faktisk ikke det, der er mest interessant: det, der er virkelig interessant, er, hvor stor dækning ens test har i forhold til kravene.

Det kan måles på 2 måder: dels bare en optælling af, hvilke krav der overhovedet bliver berørt af testen; dels en opgørelse af, hvor stor en del af kompleksiteten i kraven, der bliver berørt.

Artiklen fortsætter efter annoncen

Jeg tør, efter mere end 30 år i branchen, vove den påstand, at grunden til, at der leveres så mange systemer, der er fulde af fejl, er, at testdækningen for fleste systemer er alt for lav. Ofte ved hverken leverandør eller kunde, hvor stor en del af systemet, der er blevet testet, og så er acceptkriterier i stil med: "0 kendte fejl af alvorlighedsgrad 1" fuldstænding ligegyldige. Før testen overhovedet er startet, er antallet af kendte fejl formodentlig 0 - og så er det acceptkriterum jo i princippet opfyldt!

Alle, der skal acceptere et it-system bør forholde sig til, hvilken dækning, de ønsker. Skal 60 - 70 - 80 eller 90 % af kravene dækkes af testen. Det er sjældent muligt (rentabelt) at teste alt; men hvis man ved, hvor stor dækningen er, ved man også noget om, hvilken risiko man løber ved at acceptere systemet og sætte det i drift. Ydermere bør man forholde sig til, hvordan komplekse krav skal dækkes. Specielt hvis kravene er udtrykt som usecases, kan kompleksiteten være høj. Det, man kan tælle, er de såkaldte testbetingelser, altså alle de tilfælde hvor man vil kunne sige 'Ja - er opfyldt', eller 'Nej - det er ikke opfyldt'. Det er ikke usædvanligt, at antallet af testbetingerser i en usecase er 2-3 gange så stort som antallet af trin i usecasen.

Lad os, som gode tester, komme i gang med at tælle og med at fortælle, hvad vores dækningsgrad er, så modtagerne kan tage stilling til, hvad det betyder, at der er '0 kendte fejl' i det system, vi har testet.

9 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
7
30. marts 2012 kl. 11:30

Ja, det har jeg. Og du har ret i dine 2 første påstande: emnet for min blog er test, derfor handler indlæggene om det, jeg oplever i forbindelse med test.

Test er vigtigt for mig; det er derfor jeg blogger om det. Test kan bære al den vigtighed, det skal være. Men jeg anerkender selvfølgelig, at test ikke er lige vigtigt for alle.

Man kan sagtens arbejde med at få en god brugeroplevelse inden man slipper et system løs; der er en del teknikker til at vurdere om et bud på en brugergrænseflade er godt i forhold til brugernes behov. Det kan gøres med simple prototyper, hvilket burde være en del af ethvert kravarbejde, og meget billigere end at kode noget, sende det ud, og få det tilbage i hovedet igen. AM

9
13. juni 2013 kl. 08:42

Man kan sige meget om eksempler/analogier, men de er nemmere at huske og kan (!) skærpe pointen, men desværre også det modsatte. Jeg vover her.

Målet for dette indlæg er om I har kender til faglitteratur der i PRAKSIS gør krav testbare. Altså enten at forretningsarkitekter danner testbare krav eller test design teknikker til at teste krav (det kunne være review, men hvad skal der så reviewes efter?)

Min påstand 1 Ifl. http://ordnet.dk er ”test” en ……undersøgelse….. , men hvad betyder det egentligt? Hvad skal undersøges, hvornår, med hvor stor usikkerhed, …. (hvad vil du med denne ”påstand”?)

Min påstand 2 Hvis ikke der er reguleringsmekanismer, arver efterfølgende led direkte. Både det gode og det dårlige, så jo tidligere i fødekæden jo større effekt.

Min påstand 3 Som eksempel; bygnings håndværkere og IT håndværkeres arbejde ligner på en række områder hinanden. • Kontrakter /aftaler er beskrivelse af hvad kunden ønsker og leverandøren agter at levere • Projekter er måden at styre hen mod resultatet. Ændringer/forhindringer i projektet er en naturlig del af et projekt • Ordentlig kommunikation er bare vigtigt • Håndværksmæssige kundskaber er en væsentlig faktor for succes Motivation - jobbeskrivelse I ”ikke-IT verdenen” er der ret mange mennesker ansat til at kontrollere. Det kan være parkeringsvagter, Bilsyn, godkendere af husbyggeri og mange andre. Fælles for disse funktioner er, at menneskers PERSONLIGE skøn vægtes lavt ift. de regler, skøn og standarder der er på området, er opsamlet gennem årene og gjort konkrete i f.eks. love (erfaringsopsamling). Analogien i IT-verdenen er testere – vi er kontrollanter :-)

Motivation – udgangspunktet Starten på mange projekter er kontrakten, der i mange tilfælde (det er en påstand) baseres på hvad kunden ønsker ”dingenoten” skal kunne. F.eks. hvis du vil have lavet et hus, så er det ret smart, hvis leverandøren ved hvad du vil have – men GRUNDLÆGGENDE er krav til IT-systemer og specifikation af et hus det samme.

I byggebranchen er der en mangeårig erfaring i hvad der kan lade sig gøre. Jo mere der afviges fra hvad man plejer at gøre, jo mere risiko. Der er så også ret meget lovgivning om hvad man må. Pointen er, at der er mange flere frihedsgrader i IT end der er i f.eks. byggebranchen. Frihedsgrader ……..frihed  godt ! (??) er i hvert fald den tankerække jeg får, men der er så også en konsekvens af det. I denne sammenhæng betyder det i hvert fald præcisering. Alle de løse ender er frihedsgrader og en eller anden skal jo tage stilling til hvad svaret på disse skal være.

Når du har præcise krav ved alle interessenter hvad meningen er. Men hvordan ved du om dine krav er præcise nok INDEN du begynder på opgaven? (bagefter kan man måle det på skænderierne og det er ikke så relevant)

Motivation – processen Vidensoverdragelse fra den taknemmelige ”Word-verden” til den konkrete ”implementerings-verden” foregår på mange måder, men sker det ikke, laver fingrene noget andet end hovedet gerne vil have. Analogien til at bygge et hus, kunne være at elektrikeren sidder med forældede tegninger og sætter el-kontakterne et andet sted end komfuret skal stå.

Spørgsmål Er kravene mangelfulde i projekter med mange frihedsgrader, hvordan ved vi så om vi har leveret varen? Udvikleren ved ikke hvad der skal udvikles og testeren ved ikke hvad der skal testes, så hvad bliver resultatet? Det kan blive til mange personlige skøn om hvad resultatet skal være – vi mangler en facitliste. Hey – net: Hvem har skrevet noget fornuftigt og KONKRET om det her? Er vi der hvor vi skal have hjælp fra andre grene af videnskaben end vi traditionelt bruger? Anvendt filosofi for at finde ud af hvad vi egentligt mener med vores ord? Eller mangler jeg bare at læse: ______________________________________?

5
29. marts 2012 kl. 15:36

Jeg synes, det er tankevækkende, at stort set alle mine indlæg om test lynhurtigt drejer over i diskussioner om krav!

Hvis vi nu antog, at kravene var udtryk for brugernes behov - hvordan skulle man så forholde sig til test?

AM

6
29. marts 2012 kl. 15:58

Har du overvejet at det er fordi alle dine indlæg.

  1. Handler om det samme
  2. Primært er propaganda for dit felt
  3. Postulerer vigtigheden af test i en grad den ikke kan bære.

Men for at svare på dit spørgsmål

Kravene som udtryk for brugerens behov vil være at launche finde ud af hvad der er problemet og så rette til efterfølgende.

Du kan nemlig ikke teste dig til en god brugeroplevelse uden at få det ud i virkligheden.

Med andre ord, continues deployment er vejen frem for det offentlige og så løbende test af disse deployments.

8
31. marts 2012 kl. 11:28

@Thomas Pedersen

Kravene som udtryk for brugerens behov vil være at launche finde ud af hvad der er problemet og så rette til efterfølgende.</p>
<p>Du kan nemlig ikke teste dig til en god brugeroplevelse uden at få det ud i virkligheden.</p>
<p>Med andre ord, continues deployment er vejen frem for det offentlige og så løbende test af disse deployments.

Dét du snakker om lyder mere som en udviklingsmodel end en test-metode/strategi. Taler du ikke i stedet om en inkrementel bruger-involveret udviklingsmodel àla UX? Temaet for bloggen er test, og Anne Mette har efter min mening påpeget sporbarhed gennem krav og test af disse, og ikke andet. Du afsporer debatten.

@Gert Olsen

Jeg har været igennem 1.000-vis af jobannoncer og har aldrig set ”Sund fornuft” som et krav eller en ønsket personlig kvalitet.

Du ser også sjældent "ædruelig" eller "ikke-voldelig" som ønskede personlige kvaliteter ;) Jeg synes nu tit der står floskler i retning af "team-player", "analytisk/velovervejet", "kan bevare overblikket i pressede situationer" osv. Er du ikke stødt på mange af dem når du har læst opslag?

4
28. marts 2012 kl. 15:40

Jeg mener det er vigtigt at der i ”kæden” af ansvarlige i projekter er nogle som er i besiddelse af erfaring og ikke mindst sund fornuft. Der fokuseres tit alene på teoretisk højtuddannede medarbejdere når der oprettes projekter. Jeg har været igennem 1.000-vis af jobannoncer og har aldrig set ”Sund fornuft” som et krav eller en ønsket personlig kvalitet. Det er vigtigt at nogen sætter sig ind i hvad produktet rent faktisk skal bruges til. Som også kan sætte sig i ”helikopter” og se hvad der sker hvis brugeren benytter programmet på en anden måde end udvikleren/arkitekten har tænkt. Og ikke mindst bekymrer sig om brugervenlighed. Brugeren skal ikke rende rundt med en manual i lommen for at benytte programmet korrekt.

2
28. marts 2012 kl. 15:02

Hvad mener du med lovkrav?

3
28. marts 2012 kl. 15:26

Jeg mener den måde udbudene udformes på.

1
28. marts 2012 kl. 12:55

Testdækning fixer ikke grundlæggende problem; forfejlede projekter/projekt-scoping og dårlig usability bla. grundet lovkrav.

Det er det egentlige problem og test issues kommer meget meget meget langt ned på listen.