Påvirk fremtidens test

Siden 2007 har en arbejdsgruppe under ISO arbejdet på at skrive en komplet standard for softwaretest. Jeg har været så priviligeret at få lov til at deltage i det arbejde, og det er spændende og meget hårdt.
Standarden, som vil gå under navnet ISO 29119, Standard for Software Testing, er delt i 4 dele:

1) Concepts and Vocabulary

2) Test Processes

3) Test Documentation

4) Test Design techniques

Det bliver første gang, softwaretestere får én sammenhængende standard, der både omfatter processen (det har vi ikke haft før), dokumentation (nogenlunde dækket af IEEE 829) og teknikker (delvis dækket af BS 7925). Standarden dækker hele testarbejdet fra det organisatoriske niveau i form af udarbejdelse af testpolitik og teststtrategier, over testplanlægning og monitorering, til detaljeret testdesign, testeksekvering og testrapportering.

Del 2 og del 3 er i øjeblikket ude i den endelige afstemningsfase; dvs. alle kan komme med kommentarer, og de enkelte lande, der er tilknyttet ISO, kan stemme om endelig godkendelse. Det er derfor nu, DU kan påvirke fremtidens test! Kontakt Dansk Standard og bed om en kopi af delene og en kommentarformular - og giv din uforbeholdne mening til kende.

Standarden kan umiddelbart tages i brug; selv om den ikke er endelig godkendt endnu. Jeg synes, i al beskedenhed, at den er rigtig god. Den fortæller i detaljer, hvilke aktiviteter, der indgår i god test, og hvordan testen kan dokumenteres. Standarden er ikke ment som en spændetrøje, men som inspiration og som en samling af god praksis.

Som sagt har det været et kæmpearbejde at udarbejde standarden - det er ikke så ligetil at få 25-30 eksperter fra mere end 15 lande spredt over hele kloden til at blive enige om, hvordan man tester; men det er faktisk lykkedes til de flestes tilfredshed. Diskussionerne har været mange og af og til meget intense; men resultatet har været det hele værd!

Når del 2 og 3 er endelig godkendt, går vi videre med at færdiggøre del 1 og 4, og om ca. 1 år regner vi med at være færdige!

Færdige - med den første udgave; en standard hverken kan eller skal ikke være den endelig sandhed, så vi er selvøflgelig nødt til at følge udviklingen indenfor test og tilstødende procesområder - der er ingen ende på at blive bedre og klogere :-)

Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mogens Hansen

Alle tiders, vil straks rekvirere delene og en kommentar formular. Håber du skriver igen, når del 4 er klar - det er helt klart her, jeg fornemmer at mange falder igennem når det for alvor går løs.

  • 0
  • 0
Jan Hansen

<rant>Ligner en totalt nyttesløs standard, opfundet af oldsager fra det industrielle paradigme, forsøgt overført på en IT branche som adskiller sig i en sådan grad at det er dømt til at fejle.
Vil vædde på at det kun er et spørgsmål om tid før det her crap bliver en obligatorisk del det offentliges udbud af IT projekter og vi alligevel om 5-10 år vil se et endnu fejlet CSC/KMD projekt, som på papiret lever op til denne standard.
Hvornår kan vi der har forstand på systemudvikling blive fri for at talentløse tabere skal overdænge os med beurakrati for vi kan få privilegiet at slæbe rundt på deres dødvægt til skade for vores virksomheder og vores samfund?</rant>

  • 3
  • 3
Anne Mette Hass

Hold da op, Jan; du har da vist 'a chip on your shoulder' - det må ikke være rart.

Jeg opfatter ikke mig selv som hverken en oldsag eller talentløs eller taber. Og sådan opfatter jeg heller ikke de andre i arbejdsgruppen - tværtimod! Vi er om ikke unge, så i vores bedste aldre, meget erfarne, og alle med (i al beskedenhed) ret fantastiske karrierer inden for IT.

Måske skulle du bidrage med din erfaring, så du kan få en lidt bedre fornemmelse af, hvordan sådan et arbejde forløber.

Jeg ville ønske, standarden blev om ikke obligatorisk så i alt fald vejledende, både for det offentlig og det private, så alt for mange ikke skal bruge tid på at opfinde mere eller mindre underlige dybe tallerkner igen og igen.

  • 1
  • 2
Jan Hansen

Jeg indrømmer min kommentar var for skinger. Se bort fra de negativt ladede adjektiver. Jeg står dog inde for substansen dvs. jeg betviler stadig at denne standard i vil bidrage med noget som helst positivt. Jeg anser selvstændige test og testere som symptombehandling af en syg udviklingsprocess der har mere fundamentale problemer. Jeg betragter selvstændig test og testere som et forsøg på at overføre QA funktionen i en industri virksomhed til softwareudvikling, det er i bedste fald nyttesløst, i værste fald skadeligt. Det beror på en total misforståelse og uvidenhed om softwareudviklingsprocessens natur. Jeg betragter løsrevet test og testere på samme måde som en evolutionær biolog betragter et præst fra indre mission med speciale i skabelsen. Jeres udgangspunkt er forfejlet, I kan ikke bidrage med noget.

  • 1
  • 2
Mogens Hansen

Jeg betragter løsrevet test og testere på samme måde som en ...


Prøv lige at tage en dyb indånding, inden du skyder folk mere i skoene. Anne Mette er om nogen fortaler for, at afprøvninger skal integreres i udviklingsprocessen og ikke være en hverken selvstændig eller løsrevet disciplin. Det forhindre ikke at afprøvning beskrives separat.

  • 2
  • 0
Anne Mette Hass

Hej Jan,

Du må meget gerne uddybe, hvad du mener med "softwareudviklingsprocessens natur". Jeg indrømmer, at jeg efter mere end 30 år i branchen ikke ved, hvad du mener.

Min holdning er, at test altid er nødvendigt - ligegyldigt, hvad vi mennesker foretager os - fordi vi ikker er perfekte, men begår fejl selv om vi gør os umage og har de bedste betingelser. Det er der ikke noget at gøre ved; vi må tage det til efterretning og tage vores forholdsregler, så så få fejl som muligt kommer ud til brugerne.

Tak for støtten, Mogens og Fredrik!

  • 0
  • 1
Jan Hansen

Du må meget gerne uddybe, hvad du mener med "softwareudviklingsprocessens natur". Jeg indrømmer, at jeg efter mere end 30 år i branchen ikke ved, hvad du mener.


Det skal jeg gerne forklare. Først lidt kontekst, jeg har gentagne gange påstået at software testere udfører den stikprøve kontrol som QA afdelingen på en fabrik der fremstiller møntrikker laver. CMMI, vandfaldsmodeller, estimater og lignende er et udtryk for samme misforståelse - at software produceres ligesom alle andre prdukter.
Det er forkert. Software produceres kun i det tidsrum der går fra der trykkes build til systemet svarer Build complete! Resten af tiden i et software projekt er design.
Test af design er videntungt og omkostningstungt (tænk vindtunnelforsøg og ingeniørberegninger). Den tilsvarende ekspertviden er typisk ikke til stede i en typisk software testafdeling og omkostningerne der i andre design processer retfærdiggøres af at omkostningerne ved at fremstille produktet er meget højere, kan ikke retfærdiggøres i forbindelse med software, da produktion (kompilering) af software er gratis.
Vi tester ikke en færdig bro, vi tester designet og kun fordi det er billigere end at bygge broen om og om igen.
Vi har brug for tests. Vi har bare ikke brug for testere og vi har ikke brug for standarder for tests, som det offentlige kan se sig blinde på når de skal vælge leverandører.

  • 2
  • 2
Thomas Petersen

Standarder kan man bruge når processen og udfaldet er velkendt. Når scopet er overkommeligt og til at overskue. Det var fint op til omkring halvfemserne.

Men de systemer der laves idag indgår i så komplekse sammenhæng at det ikke giver mening at lave standarder i den forstand. Der findes allerede standard systemer der kan løse meget af det der bedes om fra det offentlige idag. Men det er klart at så laver de gamle software huse ikke lige så mange penge.

Hvad der skal til er en forståelse af at software systemer er mere organisk end det er mekanisk og at offentlige projekter burde implementeres i små itterative skridt snarere end som de store løsniger vi ser idag. Selv dem der faktisk bliver færdige er forfærdlige.

Brug standard systemer istedet for at spilde tiden på at skabe standarder der ingen hjælper.

  • 2
  • 0
Deleted User

Ser du det ikke lidt meget som om der kun testes på det færdige produkt? Jeg vil da tro at de fleste designer del mængder af det samlede design og laver spikes på de områder som er lidt uklare. Hvorefter der buildes og bliver sendt videre til en eller anden form for accept. Jeg ser ikke denne accept som stikprøvekontrol. Men som en kvalitetstjek af det leverede holdt op imod det forventede. Hvordan vil du have det skal være? Kan du komme med nogle konkrete eksempler? Det vil i det mindste skabe mere værdi for denne debat, end at du bare lukker galde ud.
Jeg selv har stor respekt for folk som går op i dette aspekt. I mine øjne er det disse ekstra steps der gør at det ikke bare er den "korsliggende-jeg-ved-hvordan-hele-verden-ser-ud"-menige udvikler som får frie tøjler og lov at bestemme.

  • 0
  • 0
Thomas Petersen

Nu vil jeg ikke mene at jeg lukker gjalde ud. Men jeg skal gerne prøve igen :)

Problemet er ikke tests. Tests virker fint i den udstrækning de bliver brugt idag.

Men du kan ikke teste for grundproblemet. For det er at scopet af projektet er for stort og de indbyggede problemstillinger for komplekse til at kunne forudsige hvor lang tid det vil tage at løse dem.

Det er ikke noget problem når man har at gøre med en virksomhed der laver et stykke software og er lønnet normalt. Men det er straks noget andet når man hyrer et software hus til at udviklet et system der indgår i et system der er alt for komplekst til at kunne forudsige hvilke problemer man støder på.

Derfor giver det mere mening at købe standard systemer der allerede findes derude, hvis man endelig vælger at gå den vej. Det er vist også derfor at svenskerne har kunnet gøre det forholdsvist enkelt. Out of the box løsninger.

  • 0
  • 0
Chris Bagge

Dokumenterne er også ude til ballot hos IEEE, alle fire dele. De ligger her på bordet.
Part 1 som ISO/IED Committee Draft, CD
Part 2 som ISO/IEC Draft International Standard, DIS
Part 3 som ISO/IEC Draft International Standard, DIS,
Part 4 som ISO/IEC Committee Draft, CD

Som Anne Mette skriver, så er dette, lige som de fleste IEEE standarder ikke udarbejdet i et elfenbenstårn, men praktisk anvendelige dokumenter. Det er f.eks. en rigtigt god ting, når der nu kommer fælles begreber for de forskellige ting.

  • 0
  • 0
Thomas Petersen

Hvordan kan I vide hvordan forskellige virksomheder arbejder? Jeg er ikke i tvivl om at CSC vil sørge for at følge disse hvis det blev påkrævet. Men jeg kan garantere for at det ikke vil ændre noget som helst ved deres evne til at levere ordentlige løsninger.

Jeg har svært ved at se hvordan det ikke kan være udarbejdet i et elfenbenstårn. For hvis det havde været lavet ude hos rigtigt mange nyere software huse så ville man hurtigt indse at det ikke giver megen mening.

  • 1
  • 0
Anne Mette Hass

Hej Lucas,

Flere af deltagerne i ISO arbejdsgruppen har også deltaget i ISTQB arbejde, og de kender selvfølgelig ISTQB vældig godt. Der er i nogen grad taget udgangspunkt i ISTQB, bl.a. ordlisten. Herudover har alle, også ISTQB-folk haft rig lejlighed til at kommentere udkastene undervejs, og det har de også gjort.

ISO gruppen har aftalt med ISTQB, at de kunne sende en deltager til gruppen, men der er nu ikke kommet nogen. ISTQB har dog sagt, at de vil rette ISTQB mod ISO-standarden, når den kommer.

AM

  • 0
  • 0
Chris Bagge

Til Thomas
For det første er jeg ret sikker på, at CSC ikke har fulgt de retningslinjer der er i (de kommende) standarder. Standarderne er ikke en kogebog for at du gør sådan, og sådan og sådan, og krydser af der og der. De beskriver de ting der bør gøres og hvornår. Det er så op til den enkelte virksomhed at indføre det på en fornuftig måde. Her hopper kæden ofte af, når der kommer en paragrafrytter ind. De mennesker der har arbejdet med at udvikle disse (kommende) standarder har masser af praktisk erfaring. Jeg har f.eks. selv siddet sammen med Anne Mette og testet på et nødlidende projekt, da vi er gamle kollegaer. Hun har i aller højeste grad praktisk erfaring med som ballast.

Det at indføre en fornuftig testkultur tager rigtig lang tid. Disse standarder leverer det ikke. Hertil kræves der meget ofte en holdningsændring i virksomhederne. Det er nemt nok at teste meget. Det svære et at teste effektivt.

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