Der er håb for de offentlige projekter!

Af 5

Denne gang er min blog en rapport fra en fladmast (lidt for meget arbejde), men glad tester! Jeg har i den forgangne månedstid arbejdet i 2 store offentlige it-projekter, hvor der skulle tages store beslutninger. De beslutninger er nu taget, og det er virkelig spændende.

På det ene projekt blev den officielle test udsat, fordi testspecifikationen ikke var god nok. Det er vist nok aldrig sket før for en offentlig kunde. En meget modig beslutning taget af en enig styregruppe. Men styregruppen havde også et godt beslutningsgrundlag.

I de fleste offentlig projekter med eksterne leverandører er det leverandøren, der står for alle de formelle tests; dog således at kunden skal godkende testspecifikationerne og overvåge testafviklingen. I dette projekt er der over 550 krav i kontrakten, og der står ydermere i kontrakten, at alle krav skal testes i den formelle test.

En første, hurtig gennemgang af den testspecifikation, leverandøren fremsendte, gav fornemmelsen af, at der var for få testcases. Vi bad om en sporingsliste, så vi kunne se, hvilke krav testspecifikationen dækkede. Den fik vi, men den så lidt underlig ud; den viste umiddelbart bare, at alle testcases kunne spores til et krav. Men hvad med den anden vej? En bearbejdning viste, at kun 48 % af kravene var dækket af testcases! 48 %. Dvs. at leverandøren undlod at teste over halvdelen af den ønskede funktionalitet.
For et system af den type, der er tale om her, ville det ikke være acceptabelt med en dækning under 70 % og man burde have en dækning over 80 %. I samtale med leverandøren lovede de at give et bud på, om de kunne nå at skrive testspecifikationer nok til opnå 60 % dækning i tide. Jeg skal spare jer for detaljerne; men resultatet blev en udsættelse af testen, så leverandøren kunne nå at forbedre deres testspecifikation til et mere acceptabelt niveau.

Det, der er interessant ved denne sag, er, at det efter sigende er første gang, en leverandør er blevet holdt op på kravet om, at de skal teste ’alle’ krav i den formelle test. Bl.a. derfor valgte man i projektet ikke at stå fast på en fuldt acceptabel dækning, men trods det var en udsættelse uundgåelig.

Hvis dette skaber præcedens, er der måske håb om, at antallet af skandaler i form af systemer, der er fulde af trivielle fejl, når de tages i brug, kan falde.

På det andet projekt er der blevet bevilget penge til, at en med megen viden og erfaring i udarbejdelse af krav (mig) kan støtte den offentlige kundes egne medarbejdere under kravarbejdet på et meget stort kommende system.

Se det er virkelig interessant!

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Niels Holst-Nielsen

"I de fleste offentlig projekter med eksterne leverandører er det leverandøren, der står for alle de formelle tests; dog således at kunden skal godkende testspecifikationerne og overvåge testafviklingen".

Har du nogen som helst dokumentation for denne påstand? Den reflekterer overhovedet ikke min erfaring fra hverken den private eller offentlige sektor.

"Det, der er interessant ved denne sag, er, at det efter sigende er første gang, en leverandør er blevet holdt op på kravet om, at de skal teste ’alle’ krav i den formelle test. Bl.a. derfor valgte man i projektet ikke at stå fast på en fuldt acceptabel dækning, men trods det var en udsættelse uundgåelig."

Det er helt normalt, at man i aftalegrundlaget forlanger alle krav aftestede.

Derefter starter en analysefase, og den vil i praksis afsløre risici i forbindelse med f.eks. transaktioner mod grænsefladesystemer eller kræve urealistisk produktion af testdata. Det er ofte heller ikke muligt at financiere testmiljøer der til fulde replikerer produktionsmiljøet.

Derfor slækkes på testkravene efter overenskomst.

"Se det er virkelig interessant!"

Nej, ikke rigtig.

  • 5
  • 2
#2 Tom Høg Sørensen

Der er ingen tvivl om, at har man styr på sin test (herunder ikke mindst "hvad" der skal testes og "hvorfor") giver det bedre kvalitet. Vælger man agile metoder med fokus på testdreven udvikling, er risikoen for at få en "hovsa"-oplevelse sent i forløbet langt mindre. Ved godt, at standardkontrakterne (K01 og K02) ikke direkte understøtter dette. Som jeg ser det, bliver forudsætnngen for kvaliteten af både kravene og testen bedre, når K03 er på plads.

  • 0
  • 0
#4 Kenneth Holm Nielsen

"I dette projekt er der over 550 krav i kontrakten" Hvordan skal 550 krav vurderes som et højt antal? Er der et veldefineret niveau for krav?

"man burde have en dækning over 80 %" i lige det her projekt pga. nogle forhold der gør sig gældende her, eller er det en generel tommelfingerregel?

"En bearbejdning viste, at kun 48 % af kravene var dækket af testcases!" Hvordan relateres krav til test? Jeg ved at i gængse test værktøjer, så relateres test og krav direkte, stilles der nogen krav til levereandøren om at lave dette arbejde?

Det kan umiddelbart være en større opgave, men hvis ikke leverandøren i kontrakten bliver gjort klar over at kunden har en forventning om dokumenteret coverage, så kan det vel ikke kræves?

hilsen en offentlig leverandør der er lidt nysgerrig på forløbet :)

  • 1
  • 0
#5 Anne Mette Hass

Hej Kenneth Holm Nielsen!

Dejligt med en nysgerrig læser. Jeg skal med glæde forsøge at svare på dine spørgsmål.

550 krav er hverken meget eller lidt. Jeg har set projekter med 30 krav og projekter med over 1000. Det var bare for at give en størrelsesorden. I de offentlige udbud er kravene nummereret helt klart, så på den måde er det let at se, hvad der er et krav. Underliggende er der dog ofte det problem, at kravene ikke er atomare, dvs. at der i virkeligheden kan være mange krav under et nummer. En tommelfinderregel for at tælle er, at der er tale om ét krav, hvis man kan besvare om kravet er opfyldt med ÉT ja eller ÈT nej.

Jeg må ikke røbe for meget om projektet, men det er et ret forretningskritisk system forstået på den måde, at det almindelige daglige arbejde ikke vil kunne udføres for de over 5000 direkte brugere, hvis systemet ikke virker. Med op mod 1 mill. mennesker, der er mere eller mindre afhængige af, at disse brugere kan udføre deres arbejde, er konsekvensen af, at systemet ikke virker, alvorlig. I kontrakten står der faktisk at alle krav skal testes, så en håndhævet dækning på 80% skulle ikke vælte leverandøren af pinden.

Man kan spore mellem test og krav på mange måder. I dette projekt er der brugt Excel, og det virker nogenlunde. Det er ret nemt at udføre denne sporing, når man sidder og skriver testcases udfra kravene - og det er jo det, man skal gøre. Leverandøren bliver (i alt fald i dette projekt) udtrykkeligt bedt om at levere en sporingsliste i kontrakten, så det skulle helst ikke komme som en overraskelse (der er ikke krav om hvordan). Desværre er der ikke så mange hverken leverandører eller kunder, der ved hvad en sporingsliste er, så det er sjældent, at dette bliver håndhævet og checket.

Jeg håber, dette kaster lidt lys over sagen, og at brugen af sporing vil brede sig som en steppebrand hos kunderne. Det er et ret nemt og meget stærkt værktøj til at få information om leverandørens modenhed og generelle kvalitetsniveau.

Mange hilsner Anne Mette

  • 0
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen