Så kom softwaretest endelig på bloggen

Et talerør – et hørerør – en blog! Om softwaretest! Hvad mere kan man ønske sig, når man som jeg gerne vil tale med alle om softwaretest?

Så - Velkommen til Anne Mettes blog om alt, der bare har det mindste med softwaretest at gøre.

Jeg betragter mig selv som professionel softwaretester. Ikke på den måde, at jeg har en statsanerkendt uddannelse i SW test; det kan man nemlig ikke få i Danmark. Heller ikke på den måde, at jeg er medlem af en anerkendt fagforbund for SW testere; sådan en findes nemlig heller ikke. Men på den måde at jeg tager mit arbejde som SW tester meget alvorligt og er stolt af det; at jeg hele tiden arbejder på at blive bedre; og at jeg ved, at jeg tilfører værdi ikraft af det, jeg gør og kan.

Måske kan man engang i fremtiden blive 'rigtig' professionel sw tester - det mangler da bare, hvis vi vil kalde os 'den bedste IT nation i verden'.

Gennem de seneste 10-15 år har jeg set sw test-professionen modnes - men jeg kan også se, at der er langt igen inden den får den anerkendelse i swbranchen, som der er belæg for. Og der er mange ting, jeg gerne vil være med til at ændre.

En af dem er forskellen på 'hvis' og 'når'. I alt for mange beskrivelser af testarbejdet i både private og offentlige organisationer står der noget i retning af: '...hvis der findes fejl under testen .." Det viser en holdning til test om, at "test ikke er helt nødvendigt, for det er jo ikke sikkert, vi finder fejl; sandsynligvis finder vi ikke nogen, det her er jo et super-projekt og de involverede har virkelig gjort deres bedste, så test er bare en unødvendig udgift." Det er helt forkert. Der ER fejl i alle IT produkter! Simpelthen fordi det er et vilkår, at mennesker begår fejltagelser, uanset hvor dygtige vi er, hvor meget vi gør sig umage, og hvor gunstige betingelser vi har. Når de ansvarlige for IT produkter har haft modet til at indse det, vil sw test være på vej til at blive anerkendt på linie med at designe og skrive kode.

Test er ikke en unødvendig udgift - det er en absolut nødvendig profession, der skal være repræsenteret i alle sw udviklings- og vedligeholdelsesopgaver fra dag 1!

Så lad os komme i gang med samtalen!

Det første, vi kan tale om, er definitionen på test. Hvad vil det sige, at teste? I den kommende ISO 29119 Standard for Software Testing bliver definitionen formentlig noget i retning af: "de aktiviteter, der skal til for at sammenligne, hvad man har fået, med det de fremtidige brugere forventede".

Der er i alt fald to interessante aspekter i den definition: 1) test er mere end bare afvikling af testcases (det kan vi tale om ved en senere lejlighed); og 2) uden beskrivelse af, hvad "de fremtidige brugere" forventer, kan vi ikke teste!

De fremtidige brugere er alle, der efter produktets frigivelse kommer i kontakt med det. Det kan være testerne er fremtidige brugere, men det er langt fra givet - og der er mange andre fremtidige brugere, der ved mere om, hvad de har brug for, end testerne gør. Det har allerede været sagt og (måske?) accepteret i lang tid, at man ikke kan teste kvalitet ind i et produkt; kvalitet skal arbejdes ind hele vejen under udviklingen - alligevel er der stadig mange, der arbejder ud fra den ide, at testerne på en eller anden måde kan tilføje kvalitet. Det kan vi ikke! Vi kan i princippet kun udtale os om, i hvilken grad forventningerne er opfyldt.

Lad mig give et eksempel på, hvad jeg mener: Inden for det offentlige findes to standardkontrakter for anskaffelse af IT-produkter, K01 for mindre projekter og K02 for større projekter.Hver af disse har et antal bilag, f.eks. har K01 et kravbilag og et prøvebilag (det, vi andre ville kalde et testbilag, men det er en anden historie). Der er ingen forslag (modelbilag) til kravene, og det er OK; de anhænger jo af det aktelle produkt, der skal anskaffes.. I forslag (modelbilag) til test står der derimod: "I forbindelse med overtagelsesprøvens gennemførelse fremprovokeres en række fejlsituationer, som systemet skal reagere på med fejlmeddelelser, der gør det muligt for brugeren at fortsætte på et veldefineret grundlag.". Jeg spørger for det første mig selv om, hvorfor dette 'skal holdes hemmeligt' for udviklerne, dvs. ikke optræde i kravene, men kun i forbindelse med testen? Og hvordan skal testerne kunne vide, hvilke fejlsituationer, der er relevante, og hvilke fejlmeddelelser, der gør det muligt for brugerne at fortsætte? Og hvordan kan testerne vide, hvad et veldefineret grundlag er? Kære K01 - det er IKKE godt nok!

Hvis vi skal gøre os håb om at få bedre IT-produkter på markedet til en fornuftig pris og inden for en fornuftig tidsramme, skal alle forventninger ud af testen! Om de så kommer imd i en kravspecifikation eller i en product back.log eller fastholdes på en tredie måde er sådan set ligegyldigt; de skal bare være på plads, FØR udviklingen begynder og FØR testarbejdet begynder.

AM

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Morten Andersen

Hej Anne Mette

Velkommen til version2-bloggen og tak for dit indlæg :) Jeg er i princippet enig, men erfaringsmæssigt er det ikke muligt at have alle forventninger o.s.v. klar "up front". Brugerne ved simpelthen ikke nok om hvad de vil have. Selvom man kan sige at det er deres ansvar eller deres egen skyld, holdet ikke i praksis. Det er et faktum man er nødt til at forholde sig til da projektet ellers med garanti bliver en fiasko -- i hvert fald med mindre det er noget relativt simpelt/velkendt man har med at gøre.

Et andet problem ved at insistere for meget på at alle krav skal være veldefinerede up front er flg som ofte ses i offentlige udbud: Fordi udbyderen (den offentlige institution) ønsker at have veldefinerede krav, så hyrer projektlederen eller den indkøbsansvarlige inden udbudet et dyrt konsulentfirma til at indhente og samle alle disse krav fra alle tænkelige interessenter, høj som lav. Dette på et tidspunkt hvor systemet er helt 'teoretisk'. Men alle de pot. interessenter giver gerne deres besyv med. Det er jo deres arbejder og hvorfor stå tilbage for de andre der sender krav ind. Det resulterer i mange krav.

Ofte kan denne proces tage halve og hele år, koste mange mio. af kroner og resulterer i en liste af krav der kan fylde adskillige hundreder af sider. Det er så denne monstrøsitet af en kravliste der danner basis for udbudet.

Ofte er kravene indbyrdes modstridende, uhensigtsmæssige, umulige at realisere og for 90% vedkommende af "you ain't gonna need it" typen. Andre krav er selvindlysende o.s.v. Men hele fremgangsmåden fører til en enorm fordyring af processen. Bare det at skulle gå igennem, estimere, implementere, teste o.s.v. så mange krav er garant for systemet bliver enormt dyrt og at der lægges masser af energi i dele der ikke er strengt nødvendige.

Dette er opskriven på hvordan man får f.eks. et lønsystem til at koste 800 kr. (i år 2000 kr.). Men jeg kan give mange eksempler, også fra nyere udbud.

  • 1
  • 0
#5 Benny Tordrup

Ofte er kravene indbyrdes modstridende, uhensigtsmæssige, umulige at realisere og for 90% vedkommende af "you ain't gonna need it" typen.

Morten, hvis du ender i en sådan situation, så har konsulentfirmaet IMO ikke forstået opgaven.

Meningen med at gennemføre en analyse og lave en kravspecifikation er efter min opfattelse, at alle krav skal være veldefinerede, entydige og målbare, når de er kogt ned til funktionelle og tekniske krav.

De(n), som gennemfører analysen skal have nok indsigt i området til at gennemskue og opdage modstridende krav - og gøre opmærksom på disse. Derefter er det nødvendigt at afgøre hvordan denne krav-konflikt skal løses - hvilket krav, der skal slækkes på eller hvad man gør.

  • 0
  • 0
#6 Anne Mette Hass

Hej og tak for velkomsten. Det gik lige som jeg havde håbet - interessen drejet fra test til krav! Det er sådan, det skal være. Og, ja, hvis kravene ikke er gode nok, har konsulenthuset ikke gjort deres arbejde ordentligt.

Lad iøvrigt mærke til, at jeg skrev, at kravene skulle være på plads "FØR udviklingen begynder", ikke 'up front'. "FØR udviklingen begynder", gælder også i hvert sprint i agile udvikling - ready, ready! AM

  • 0
  • 0
#7 Nikolaj Brinch Jørgensen
  • 1
  • 0
#8 Nikolaj Brinch Jørgensen

Lad iøvrigt mærke til, at jeg skrev, at kravene skulle være på plads "FØR udviklingen begynder", ikke 'up front'. "FØR udviklingen begynder", gælder også i hvert sprint i agile udvikling - ready, ready! AM

Men det er du nok nødt til at være mere explicit omkring, for det fremgår ikke specielt tydeligt af din tekst. Jeg læste det som Morten, men efter du påpeger det, er jeg enig i din egen fortolkning. Ja kravene skal være på plads (og helst en stak acceptance tests også) inden Sprintet eller fasen, eller hvad vi nu vælger at kalde det, afhængigt af hvilken metode-religion projektet hænger på.

  • 1
  • 0
#9 Morten Marquard

Der ER fejl i alle IT produkter! Simpelthen fordi det er et vilkår, at mennesker begår fejltagelser, uanset hvor dygtige vi er, hvor meget vi gør sig umage, og hvor gunstige betingelser vi har.

Jeg er meget enig. Udfordringen er imidlertid at der også er fejl i de kravbeskrivelser og specifikationer der udarbejdes. Jeg vil endda gå så langt at hævde at der er flere fejl i beskrivelserne end i løsningerne - af den simple årsag at løsningerne kan udføres på en maskine mens beskrivelserne er uformelle og kan tolkes på mange forskellige måder.

Det centrale spørgsmål bliver derfor: Hvordan kan vi lave en formel specifikation af systemet som kan udføres af en maskine og som brugerne umiddelbart kan forholde sig til? Dvs en semantisk beskrivelse af systemet som ikke skal fortolkes af mennersker. Hvis det er en sådan specifikation der er tale om så er jeg helt enig. Start ikke implementationen før den er på plads. Af den simple årsag at der ikke er nogen implementation efterfølgende.

Vi arbejder netop med formelle teknikker til at lave sådanne specifikationer og har et system som kan omsætte dem uden menneskehånd til færdige løsninger. Jeg kalder det nogen gange Web 3.0.

Hvis vi skal gøre os håb om at få bedre IT-produkter på markedet til en fornuftig pris og inden for en fornuftig tidsramme

så skal vi arbejde mere agilt med formelle specifikationer i et semantisk web. Og stille krav om realiseringsprocesser, fra beslutning til implementation og ibrugtagning på uger - fremfor år.

  • 0
  • 0
#10 Anne Mette Hass

Interessant at dialogen handler om krav! Der er ingen tvivl om, at krav er forfærdelig svære at lave, men det betyder vel ikke, at man ikke skal gøre sig umage. Desværre er det min erfaring, at alt for mange virksomheder - både offentlige og private - ikke tager kravene alvorligt, eller måske snarere ikke forstår, hvor meget de egentlig betyder. Konsulenthuse bliver hyret til at udarbejde krav, fordi de har ekspertise i at skrive krav, men ikke fordi de har fagekspertise; det glemmer kunderne, og de har alt for ofte 'ikke tid' til at bidrage med deres fagekspertise. Hvorfor? Jeg må tilstå, at jeg faktisk ikke forstår det. Brüel og Kjær lavede for mange år siden en udersøgelse, der viste, at over 50% af de fejl, der blev fundet i et IT-produkts levetid, stammede fra fejl i kravene. IBM har fundet lignende tal. Jeg er - desværre - ret sikker på, at vi ville finde det samme billede, hvis vi lavede tilsvarende undersøgelser i dag. Så, testere - hvad gør vi? Siger NEJ til at arbejde med dårlige krav? Hjælper kravstillere med f.eks. at bruge testteknikker til at formulere krav med? Andre ideer?

  • 0
  • 0
#11 Morten Marquard

Hvis fejlene primært stammer fra kravene så er udfordringen at finde en model at lave gode krav på.

Hvordan gør man så det bedst? Noget tyden på at mange års erfaringer med at hyre konsulenthuse ikke sikrer success. Men hvad gør man så?

Vores bud er: 1) Få styr på de overordnede forretningsmæssige mål - hvad vil vi opnå 2) Start et agilt projekt med en udbyder som på 3-8 uger kan understøtte jeres unikke forretningsobjekter og forretningsgange uden programmering (dvs vha et semantisk web, web 3.0). 3) Kom i mål indenfor tidsplanen - det sender et vigtigt signal til organisationen. Juster scope hvis det kniber så tidsplanen overholdes 4) Sæt ressourcer af til opfølgning - og implementer justeringer løbende - gerne hver uge 5) Konstant forandring sikres ved, at brugere i organisationen får et mindre budget til selv at gennemføre mindre ændringer. Det sikrer stort ejerskab - og det er vores erfaring at brugerne passer rigtigt godt på pengene

  • 0
  • 0
#12 Sebastian Strandberg-Hansen

Når jeg som testleder kommer på et projekt i analysefasen er det første jeg gør at teste kravene og løsningsbeskrivelsen.

Det hele bliver gennemgået og på den måde sikre jeg at formuleringerne er helt klare og at alle karve er testbare. Dette foregår i et tæt samarbejde med forretningsarkitekten og kunderne.

Når vi er på det stadie hvor alle andre end testerne har godkendt løsningen - og man er klar til at give det videre til udviklerne - indkalder jeg kunderne til test af kravene. De får at vide at vi ikke genåbner kravsfasen, og de derfor ikke kan komme med ændringsønsker.

Sammen med kunderne vender jeg løsningen på hovedet og vi konstatere om alle har forstået alle løsningen enkeltdele på samme måde. Det tydeliggøres også hvad der ikke er med i løsnignen.

Processen foregår via usecases og papkort.

Der bliver altid fundet mange designfejl, og da kunderne jo har godkendt løsningen er vi i en ændringsfase, hvor ændringer koster penge…. Derfor er det kun de vigtigste ændringer og præciseringer som bliver implementeret.

Min erfaring viser at min test af kravene gør testfasen hurtigere og at vi ikke får så mange alvorlige fejl som normalt. Det er også stor øjenåbner for både kunderne og arkitekten, som bliver bedre og bedre til at definere kravene og løsningsbeskrivelsen.

  • 0
  • 0
Log ind eller Opret konto for at kommentere