Indhold Forord................................................ 11 1 Indledning.......................................... 13 1.1 Definitioner........................................ 15 1.2 Formålet med test................................... 20 1.3 0-fejl udvikling...................................... 23 1.4 Tidlig gentagbar og evig tekst.......................... 24 1.5 Nytten af registreringer.............................. 25 1.6 Nyudvikling eller systemvorvaltning.................... 26 1.7 Kvikstart........................................... 26 2 Testens faser........................................ 27 2.1 Indledning......................................... 29 2.2 Komponenttest...................................... 34 2.3 Integrationstest..................................... 49 2.4 Systemtest.......................................... 63 2.5 Brugertest.......................................... 81 2.6 Alfatest............................................ 101 2.7 Betatest........................................... 102 2.8 Accepttest.......................................... 102 2.9 De grundlæggende teststrategier....................... 103 2.10 Kvikstart.......................................... 109 3 Testen i de tidlige faser............................. 111 3.1 Hvad er tidlig test?................................... 113 3.2 Test af foranalysen................................... 114 3.3 Test af analysen..................................... 118 3.4 Test af design....................................... 124 3.5 Test af konstruktion.................................. 130 3.6 Modelbaseret test.................................... 134 3.7 UML (Unified Modeling Language)..................... 137 3.8 Klassediagram...................................... 140 3.9 Use case-model..................................... 143 3.10 Den enkelte use case (brugsmønster).................. 145 indhold 5
3.11 Sekvensdiagram.................................... 148 3.12 Kollaborationsdiagram.............................. 151 3.13 Aktivitetsdiagram................................... 153 3.14 Tilstandsdiagrammer................................ 155 3.15 Opsummering på UML.............................. 157 3.16 Kvikstart.......................................... 158 4 Systemegenskaber................................. 159 4.1 Indledning......................................... 161 4.2 Et færdigt sæt egenskaber............................ 162 4.2.1 Komplethed.................................... 164 4.2.2 Nøjagtighed.................................... 166 4.2.3 Robusthed..................................... 169 4.2.4 Ensartethed.................................... 172 4.2.5 Brugervenlighed................................ 174 4.2.6 Testbarhed..................................... 177 4.2.7 Forvaltningsegnethed.......................... 179 4.2.8 Genbrugsmulighed.............................. 180 4.2.9 Ydeevne....................................... 182 4.2.10 Sikkerhed.................................... 185 4.2.11 Flytbarhed.................................... 187 4.3 Hvornår defineres målet for en egenskab............... 188 4.4 Hvornår testes en egenskab........................... 189 4.5 Kvikstart........................................... 189 5 Testteknikker..................................... 191 5.1 Indledning......................................... 193 5.2 Formålet med testteknikker........................... 194 5.3 Whitebox-teknikker.................................. 194 5.3.1 Test af programkode............................ 195 5.3.2 Dækningstyperne.............................. 197 5.3.3 Metrics........................................ 204 5.3.4 Maskinel støtte til whitebox-test.................. 207 5.3.5 Kvalitetsstyring af den fysiske kode............... 207 5.3.6 Whitebox-test på andet end kode.................. 208 5.4 Blackbox-teknikker.................................. 211 5.4.1 Dækning...................................... 211 5.4.2 Datadrevet..................................... 215 6 indhold
5.4.3 Drevet af forventninger.......................... 229 5.4.4 Scenarier som testenhed......................... 232 5.4.5 Hændelser som testenhed........................ 234 5.4.6 Funktioner som testenhed....................... 235 5.4.7 Transaktioner som testenhed..................... 237 5.4.8. Drevet af risici................................. 239 5.4.9 Tilstande som testenhed......................... 240 5.4.10 Entiteter som testenhed........................ 242 5.4.11 Klasser som testenhed.......................... 244 5.4.12 I/O som testenhed............................. 245 5.4.13 Lede lister drevet af skepsis.................. 245 5.4.14 Use cases..................................... 248 5.4.15 Krav til testenheden............................ 252 5.5 Greybox-teknikker.................................. 255 5.5.1 Hvad er det.................................... 255 5.5.2 Greybox bringer folk sammen.................... 257 5.5.3 Hvornår kan det betale sig....................... 257 5.6 Opsummering på testteknikker........................ 258 5.7 Kvikstart........................................... 260 6 Reviews............................................ 261 6.1 Indledning......................................... 263 6.2 Walk-through....................................... 267 6.3 Play-through....................................... 271 6.4 Fortolkende review.................................. 272 6.5 Inspektion.......................................... 276 6.6 Godkendende review................................. 283 6.7 Review af underleverancer............................ 287 6.8 Kritiske succesfaktorer............................... 290 6.9 Afledte fordele ved reviews........................... 293 6.10 Kvikstart.......................................... 295 7 Planlægning og styring............................. 297 7.1 Behovet............................................ 299 7.2 IEEE-modellen...................................... 302 7.3 Specifikationen..................................... 305 7.4 Grovplanen......................................... 309 7.5 Testaktiviteter....................................... 313 indhold 7
7.6 Detailplanen........................................ 317 7.7 Testcases........................................... 319 7.8 Drejebog........................................... 323 7.9 Estimater........................................... 325 7.10 Planlægningsseminar............................... 328 7.11 Gennemførelse af testen............................. 332 7.12 Opfølgning på testen................................ 335 7.13 Kriterier for at stoppe testen......................... 339 7.14 Udviklingsstrategiens betydning...................... 344 7.15 Kvikstart.......................................... 350 8 Organisation........................................ 351 8.1 Det menneskelige testmiljø.......................... 353 8.2 Kritiske succesfaktorer............................... 354 8.3 Opgaver, ansvar og kompetence........................ 355 8.4 Projekt eller løbende forvaltning?...................... 356 8.5 Testere i forskellige testfaser.......................... 356 8.6 Kvikstart........................................... 358 9 Portaler og websider................................. 359 9.1 Indledning......................................... 361 9.2 Kategoriseringer.................................... 365 9.3 Testområder........................................ 367 9.4 Testfaserne......................................... 375 9.5 Reviews og inspektioner.............................. 386 9.6 Værktøjer.......................................... 387 9.7 Checklister......................................... 388 9.8 Kvikstart........................................... 390 10 Exploratory testing udforskende test............... 391 10.1 Indledning, definition............................... 393 10.2 Elementerne i en udforskende test.................... 394 10.3 Typer af udforskende test............................ 400 10.4 Grundlaget........................................ 401 10.5 Fordele og risici ved udforskende test.................. 402 10.6 Udforskende test kontra planlagt test.................. 403 10.7 Processen......................................... 404 10.8 Exploratory testing og agile processer................. 406 8
10.9 Afsluttende bemærkninger........................... 406 10.10 Kvikstart......................................... 407 11 Agile Testing....................................... 409 11.1 Indledning........................................ 411 11.2 Karakteristika for Agile Testing....................... 411 11.3 Marick s matrix..................................... 421 11.4 Eksempel: Handelssystemet.......................... 425 11.5 Testerrollen........................................ 429 11.6 Kvikstart.......................................... 430 Links og litteratur..................................... 437 Register.............................................. 441 indhold 9
10 kapitel 6
Forord Test som aktivitet Test er en omfattende aktivitet, målt i tid, og det gælder både når der nyudvikles i et projekt og videreudvikles i releases. Test dækker ofte 20-30 % af det samlede tidsforbrug. Der er derfor brug for at strukturere testen for at få det optimale udbytte af timerne. Teststrategi og testplaner er midlet til den gode strukturering. Test er dermed vokset fra at være spontan og uplanlagt, til at være styret og organiseret. Testens nødvendighed Accepten af fejl i software har været støt nedadgående de sidste mange år. Der accepteres i dag ikke alvorlige fejl. De kritiske og daglige funktioner skal fungere fra første færd, og kun mindre betydende fejl kan accepteres. Kendte fejl skal være dokumenterede, sammen med forslag til hvordan systemet skal bruges med skyldig hensyntagen til fejlen. En voksende del af ny software bruges direkte af kunder. Både når det er webapplikationer, betjening via telefon, eller en af de utallige andre måder, hvor den endelige bruger af systemet forudsætter, at det fungerer uden ubehagelige konsekvenser. I sådanne situationer har virksomheden, der stiller systemet til rådighed, en særlig interesse i at det fungerer uden væsentlige fejl. Dels fordi brugeren bedømmer virksomheden i forhold til systemet, men også fordi fejl kan skade virksomheden selv. Testens resultat En god test sørger for at levere et system uden væsentlige fejl, og som er velegnet til sit formål. Omkostningerne, der er forudsætningen for at nå dertil, er som oftest mindre end ved at rette fejl efter levering. Og i de tilfælde hvor det viser sig, at systemet ikke er velegnet til sit formål, er regnestykket klart til fordel for det gode testforløb. Nye kapitler denne udgave Der er kommet nye kapitler i denne udgave. Det er kapitel 9 om portaler, der er en udvidelse og erstatning af det tidligere appendiks om webtest, der var tilgængeligt på www.vrpartners.dk. Desuden kapitel 10 om Exploratory Testing og kapitel 11 om test i forbindelse med extreme Pro- forord 11
gramming. Kapitel 3 er desuden udvidet betydeligt med modelbaseret test baseret på UML. Certificering Efter at ISEB certificering har været mulig i nogle år, men kun på engelsk, er den nu tilgængelig på danske. Det er muligt at blive certificeret gennem Dansk IT. Det er en tilfredsstillende udvikling. Kvikstart Hvert kapitel slutter med nogle linier om, hvordan man kan komme hurtigt i gang med emnet i praksis. De kan bruges, når handling er vigtigere end diskussion. Henvisninger En stor del af informationen om, hvad der rører sig i testverdenen, skal findes via nettet. Brug derfor venligst www.softwaretest.dk Den indeholder links, referencer til seminarer, artikler om test, omtale af erfagrupper, m.v. Supplerende materiale Supplerende materiale til denne bog er tilgængeligt på www.vrpartners.dk, ved at vælge Mine bøger på forsiden og bruge de links der står umiddelbart til højre for bogens forside. Med venlig hilsen Poul Staal Vinje www.vrpartners.dk 12 forord
INDLEDNING 1 1.1 Definitioner 15 1.2 Formålet med test 20 1.3 0-fejl udvikling 23 1.4 Tidlig gentagbar og evig test 24 1.5 Nytten af registreringer 25 1.6 Nyudvikling eller systemvorvaltning 26 1.7 Kvikstart 26 13
14 k a p i t e l 1
1.1 Definitioner Bogen bruger ofte begreberne test, fejl, rettelser, verifikation og validering. Der er ingen grund til at føje nye begreber til rækken, så vi vil i stedet se på deres historiske udvikling. Denne udvikling illustrerer samtidig nogle forskellige holdninger til test. Hvad er test Definitionen af begrebet test er ikke triviel. Den har betydning for, hvordan testen planlægges og gennemføres, og dermed har den også afgørende betydning for resultatet. En test er en proces til at sandsynliggøre, at et program eller et system fungerer korrekt. William Hetzel En test er en proces til at finde fejl. Glen Myers En test er en proces til at vurdere et program eller systems egenskaber og formåen, så det kan afgøres, om det giver et forventet resultat. William Hetzel En test er en proces til manuelt eller maskinelt at vurdere et system for at afgøre, om det opfylder specifikationerne, og hvis ikke, til at identificere differencen mellem det forventede og det aktuelle resultat. IEEE ordbog, med den gældende definition Myers definition afslører flere fejl end den første af Hetzel. Det skyldes, at mennesker normalt forsøger at løse den opgave, de bliver stillet. Ved at bruge Hetzels første definition, vil testeren kun teste systemet ud fra en specifikation over systemets forventede indhold. Testen er afsluttet, når alle dele er fundet, og det kan påvises, at de virker i henhold til specifikationen. Ved i stedet at følge Myers definition søger testeren at finde eksempler, der viser, at systemet indeholder fejl. Testen fortsætter, så længe testerne har fantasi til at påvise flere fejl. Myers påstand er, at man får, hvad man beder om. Han mener også, at holdninger er så vigtige for resultatet, at de skal bruges aktivt. Et testforløb, der ikke har i n d l e d n i n g 15
afsløret fejl, skal man derfor betragte som en fiasko. Når en test afslører fejl, er det glædeligt, og en tester, der finder fejl, skal belønnes. I dag ser man stadigvæk, at Hetzels første definition bliver anvendt, specielt i store og forsinkede projekter, hvor det til sidst blot handler om at påvise en given funktionalitet. Det sker ganske uanset, at der let kan påvises fejl ved at bevæge sig lidt uden for den slagne vej med hensyn til funktionalitet, ved at bruge skæve testdata eller blot trylle lidt med rækkefølgen. IEEE s formulering har sin styrke i, at den er bredere. Den taler både om specifikationer, manuel og maskinel test, og om at identificere forskelle. IEEE s definition lægger op til, at systemets indhold og egenskaber er aftalt forud for testen. Arbejdet med at klarlægge forventningerne og planlægningen af, hvordan opfyldelsen af dem testes, bliver dermed en vigtig del af specifikationen. Et godt eksempel på dette er test af brugervenlighed, hvor kriterierne for at godkende eller forkaste brugervenligheden i et system bliver en vigtig del af systemspecifikationen. Hvad er en fejl Også på dette område kan der være forskellige holdninger. Tag blot den ældste definition: En fejl er en afvigelse fra specifikationen. William Hetzel Det lyder måske umiddelbart meget fornuftigt, men overvej så denne definition: Der optræder en fejl, når software ikke opfører sig på en måde, som en bruger med rimelighed kan forvente. Glen Myers Myers åbner dermed mulighed for, at specifikationen kan være forkert ved at tage højde for brugerens forventninger. Det giver i øvrigt en naturlig anledning til at involvere brugere aktivt i testen. Det er muligt at påvise fejlfrihed, hvis et givet resultat tilsvarende kan påvises at være enten rigtigt eller forkert. Det kan for eksempel være en beregning, som skal give et bestemt resultat eller data, der skal registreres et givet sted i en tabel. På andre områder er det imidlertid 16 k a p i t e l 1
vanskeligere at beskrive en objektivt sand løsning. Har et skærmbillede for eksempel kun ét rigtigt udseende? Er en hjælpetekst formuleret korrekt? I disse tilfælde skal forventningerne specificeres og testen baseres på, at der er mange løsninger, som kan være rigtige set ud fra det at opfylde forventningerne. To fejl Den rette indstilling til at teste, kommer til udtryk i begrebet to fejl. Formuleringen hentyder til, at en fejl opdaget hos brugeren i virkeligheden er resultatet af to fejl. Disse kan være vidt forskellige i deres oprindelse/årsag, i omkostningerne ved at fjerne dem, og i beskrivelsen af det faktuelle indhold. Den ene fejl er den, der konkret er begået, uanset om det er en banal programmeringsfejl eller en omfattende analysefejl. Den anden fejl er, at fejlen overhovedet er sluppet ud til brugeren. Årsagerne er typisk vidt forskellige. En banal programmeringsfejl kan skyldes, at en uerfaren programmør har misforstået en detalje i programmeringssproget, og en sådan fejl kan undgås fremover ved passende undervisning. Den anden type fejl kan skyldes manglende ressourcer, eller at alle muligheder ikke er tænkt igennem. Man kan komme ud for, at den sidste type fejl i testen betegnes som en brist, snarere end som en fejl. Hvad man end vælger at kalde dem, kan fejlene kun undgås ved at gøre det bedre næste gang. De to slags fejl bør i øvrigt registreres på hver sin fejlrapport og analyseres særskilt i et eventuelt efterfølgende Post Mortem. Hvad er en rettelse En rettelse er en reparation, altså en udbedring af en skade eller mangel. Man kan vælge at være glad, hvis det er muligt at udbedre skaden ved blot at tilføje en manglende del. I de tilfælde, hvor det ikke er muligt at udføre reparationen perfekt, men hvor der bliver tale om en lap eller noget andet uholdbart, er der imidlertid grund til at være utilfreds. Denne slags reparationer forringer systemet ved at forøge kompleksiteten og dermed forhøje risikoen for nye fejl. I sidste ende forkorter det levetiden og dermed nytteværdien af investeringen. Rettelser har forskellig konsekvens afhængig af tidspunktet i forløbet. Tidlige rettelser kan ofte udføres med et vist held; men undervejs i forløbet bliver de stadigt vanskeligere at udføre elegant, og rettelser efter idriftsættelsen bliver naturligt nok påvirket både af tidspresset og i n d l e d n i n g 17
måske yderligere af et behov for at reparere data. Der bør altså fra alle sider udvises stor opmærksomhed for at få rettet fejl så tidligt som muligt, og det forudsætter en tilsvarende tidlig iværksættelse af test. Verifikation og validering Lad os afslutte definitionerne med de to begreber verifikation og validering, som til dagligt forkortes V&V. Verifikation er en proces til at afgøre, om en given fases produkter opfylder de krav, der er defineret i den foregående fase, om de overholder gældende standarder, og at produkterne er fremstillet på den rigtige måde. Validering er en proces til at vurdere om en given software er i overensstemmelse med kravspecifikationen. V&V anvendes hånd i hånd for at sikre, at det rigtige produkt bliver fremstillet på den rigtige måde. Det er imidlertid værd at skelne mellem de to begreber for at sikre sig, at begge dele tænkes ordentligt igennem. Eksempler på verifikation Kontrakten eller kravspecifikationen skal verificeres med hensyn til struktur og følge vedtagne standarder. Verifikationen omfatter også kontrol af, at de forretningsmæssige mål er 100 % forstået af udviklerne, og at projektlederen kontrollerer, at målene kan opfyldes inden for budgettet. Hvis man vil have en opskrift på, hvordan det gøres, kan man bruge et kontraktreview med det indhold, der er defineret i standarden ISO 9000-3. En testspecifikation kan verificeres med hensyn til sin struktur og med, at indholdet af hvert afsnit er helt og fuldt forstået. Funktions- og datamodeller skal verificeres med hensyn til, om de fuldstændig afspejler kravspecifikationen. Designerne skal kunne afgøre, om der mangler eller er tilføjet noget. Desuden skal verifikationen benyttes til at afgøre, om modellerne er opbygget efter gældende standarder, for eksempel at datamodeller er korrekte som datamodeller betragtet. Konstruktører og designere skal verificere, at koden er en korrekt afbildning af design og specifikationer, og at koden er skrevet efter gældende standarder. Skærmbilleder skal verificeres imod en standard. Verifikation er ganske enkelt vigtig hele vejen igennem. Det er afgørende både at få en teknisk korrekt objektmodel og at få fremstillet de 18 k a p i t e l 1
fysiske komponenter i en kvalitet, der gør dem lette at vedligeholde. Eksempler på validering Brugere og/eller opdragsgivere skal validere, at kravspecifikationen omfatter de rigtige forretningsmæssige mål. Det er samtidig en god mulighed for at involvere brugere tidligt i processen. Senere valideres de funktioner og data, der er resultatet af systemanalysen. Frem til dette punkt i et testforløb går valideringen dog som regel ret smertefrit, fordi både brugere og købere kan læse og forstå de produkter, som de validerer. Prototyper har til formål at validere specifikationen og analysen, før designet begynder. Det er af mindre betydning for testeren, om prototyperne derefter kan bruges i det videre arbejde eller blot skal smides væk. Den store gevinst ligger i, at systemet allerede på et tidligt tidspunkt er valideret. Validering er specielt vigtig i begyndelsen af et forløb. Hvis valideringen er vellykket dér, betyder det, at systemet er grundlæggende rigtigt, og at det bliver let at rette op på småfejl senere. Validering af designet kan give problemer. Det kan være svært at afgøre, om moduldesign og databaser giver den funktionalitet, som er aftalt. Valideringen foregår ofte indirekte ved at brugere opstiller nogle eksempler på forretningsmæssig brug, og at disse eksempler tænkes igennem sammen med designerne som en walk-through på overordnet niveau. Valideringen af det færdige fysiske system kan have forskellig sværhedsgrad. Skærmbilleder kan for eksempel blot valideres for, om de indeholder de rette data og giver den forventede funktionalitet. Validering af det færdige system sker som en traditionel sluttest med en maskinel system- og brugertest. Fælder Det er let at falde i den fælde kun at sørge for de lette dele i et V&V-forløb. Det er derfor nødvendigt i sin testplanlægning at afgøre hvilke dele, der er nødvendige. Hvis nogle dele er besværligere at gennemføre end andre, må man starte med den detaljerede planlægning af netop dem. Når man taler om en tidlig test, er det som regel validering, man ønsker, men det kan let ende med, at det er en verifikation, der bliver gennemført. F.eks. er en datamodel ikke valideret, blot fordi den er reviewet af IT-folk. Hvis det er brugere, der udfører valideringen, kan man argumentere for at den er foretaget, hvis de til fulde kan afgøre, om da- i n d l e d n i n g 19
tamodellen opfylder kontrakten og kravspecifikationen. Validering af datamodeller er dog ofte tidkrævende og problematisk. Man må ikke springe over verifikation af konstruktionen. Programmerne skal leve op til den vedtagne standard. Det kan afgøres af andre konstruktører, eller ved hjælp af et værktøj. Det kan ikke ske ved hjælp af brugere, som validerer ved hjælp af walk-throughs. 1.2 Formålet med test Det overordnede mål er at levere et fejlfrit system til kunden til de lavest mulige omkostninger, herunder med færrest mulige reparationer, fordi reparationer påvirker de samlede levetidsomkostninger. Et velplanlagt testforløb har dog flere mål og søger at opnå flere fordele. Her er nogle af de væsentligste. 1. Fejl begås ikke/færre fejl. 2. Fejl opdages og korrigeres så tidligt som muligt. 3. Risici, omkostninger og tidsfrister er som forventet. 4. Systemets kvalitet og pålidelighed er optimal. 5. Ledelsen får bedre mulighed for at følge arbejdet. 6. Konsekvensen af ændringsønsker kan hurtigt vurderes. 7. Forvaltningsomkostningerne reduceres. De fleste af målene er hentet fra IEEE s standarder for test, men listen kan let udvides. Andre mål kunne for eksempel være, at udviklerne selv fik bedre styr på processen, og at vedtagne standarder i virksomheden blev overholdt. Men først lidt mere om de enkelte punkter. 1. Fejl begås ikke/færre fejl Hvis dette mål kan realiseres, er der selvsagt opnået meget. Det er enklest, hvis man helt kan undgå fejl. For at opnå dette mål er der brug for at teste, og det kræver testere, der har dette som deres eneste opgave. I praksis kan det opnås ad mange forskellige veje, hvoraf nogle tilmed er gratis. En af vejene er at fremrykke det tidspunkt, hvor man skriver testdata. Hvis vi antager, at brugerne skriver testdata til en brugertest før designet, eller i det mindste før konstruktionen, er disse testdata tilgængelige for udviklerne, hvilket giver færre fejl og hurtigere udvikling. Det 20 k a p i t e l 1
er ikke en mirakelmedicin; men det er et eksempel på, at der med samme indsats af ressourcer kan opnås bedre resultater. 2. Fejl opdages og korrigeres så tidligt som muligt Omkostningerne til test er direkte afledt af den tid der går, mellem en fejl begås, og til den findes og rettes. Hvis en fejl begås i analysefasen, men først opdages og rettes i designfasen, er de samlede omkostninger omtrent dobbelt så store, som hvis fejlen var blevet fundet og rettet i analysefasen. Hvis en fejl, der begås i analysefasen, ikke findes og rettes før modultesten, er de samlede omkostninger omkring ti gange så store, som hvis fejlen var blevet fundet med det samme. 3. Risici, omkostninger og tidsfrister er som forventet Der kan være mange grunde til, at udviklingsarbejde forsinkes og fordyres i forhold til det forventede. En meget almindelig grund er, at der ikke er afsat tilstrækkelig tid og ressourcer til test. Gennemførelse af testen vil da i sig selv opleves som en forsinkelse. Værre bliver det, hvis man ser på den tid, der afsættes til fejlretning og fornyet test. Det kan ofte virke, som om man planlægger ud fra den forudsætning, at systemerne fra begyndelsen er fejlfri - eller i det mindste 98 % i orden. Det kan dog være tilfældet, hvis der er aktiviteter, som sikrer 0-fejl udvikling. Et ordentligt planlagt og velgennemført testforløb kan bidrage til, at det samlede udviklingsforløb kan afsluttes til tiden, og med det forventede resultat - både med hensyn til kvalitet og pris. 4. Systemets kvalitet og pålidelighed er optimal Testen skal medvirke til at opnå både kvalitet og pålidelighed. Hvis de penge, der afsættes til test, alene bruges på at rette fejl og/eller til at justere det færdige produkt, er testen ikke med til at skabe merværdi. Bedre systemer er en markant sidegevinst ved at teste bedre. For at opnå testbare systemer skal systemerne opbygges bedre, enklere og mere pålideligt. Alene dét, at der arbejdes aktivt med test gennem hele udviklingsforløbet, gør udviklerne mere opmærksomme på kvaliteten af både deres egen arbejdsindsats og af deres produkter. 5. Ledelsen får bedre mulighed for at følge arbejdet Der er behov for at følge op både på udviklingsarbejdets fremdrift og på dets færdiggørelsesgrad. Så længe et produkt ikke er testet, kan man i n d l e d n i n g 21
kun følge op på hvor langt udviklingen er nået. Først når testen er gennemført, kan man måle en egentlig færdiggørelsesgrad. Testen sørger for, at man ikke alene kan måle, hvor meget der er produceret, men også hvor godt det er. Hvis ledelsen skal have mulighed for at gribe ind med produktivitetsfremmende foranstaltninger, kan man derfor ikke nøjes med en traditionel test ved afslutningen af projektet. Råderum og reaktionsmuligheder er blevet for små på dette tidspunkt. Man kan dog diskutere, om testen skal bruges til ledelsesformål. Nogle vil hævde, at det er at misbruge i stedet for at bruge testen, og at der er tale om kontrol i negativ betydning. Imidlertid er systemer ikke udviklernes private ejendom. Derfor bør testen også anvendes til at få kendsgerningerne på bordet, så man kan få et objektivt grundlag at lede ud fra. 6. Konsekvensen af ændringsønsker kan hurtigt vurderes Hvis det er et krav, at der skal tages hensyn til ændringer, stiger behovet for at gentage tidligere test. Der bliver også behov for at estimere hvor megen test, der vil være nødvendig at gentage. Det er mest indlysende, hvis opgaven allerede er nået til konstruktionsfasen. Efter gennemførelse af en ændring er der behov for at teste, om resten af systemet stadigvæk opfører sig korrekt, eller om ændringen har givet uventede konsekvenser eller bivirkninger. Der er imidlertid et lige så stort behov for test af ændringer, hvis de optræder i de andre faser, selv hvis arbejdet kun er nået til foranalyse- eller analysestadiet. Et færdigt design, der ændres, skal helt eller delvist gennemgå en ny test. Forudsætningen for, at man let og pålideligt kan estimere de testmæssige konsekvenser af en ændring, er, at der findes en formel testplan. Jo bedre testen er planlagt, jo hurtigere vil konsekvenserne kunne beregnes. 7. Forvaltningsomkostningerne reduceres Systemet bliver lettere at vedligeholde, hvis det er testbart og forvaltningsegnet. De forhold, der gør det muligt at teste et system, er de samme, som gør det lettere at vedligeholde i løbet af dets levetid. Produktiviteten ved vedligeholdelse udtrykkes som mængden af Function Points, der kan vedligeholdes løbende per år per hele forvaltningsressource. Testbare systemer og et fuldstændigt testmiljø øger produktiviteten for vedligeholdelse. Der opnås en gevinst hver gang systemet skal ændres, og det er realistisk at regne med en gennemsnitlig reduktion af de samlede forvaltningsomkostninger i løbet af levetiden på op til 30 %. 22 k a p i t e l 1
1.3 0-fejl udvikling Mon ikke alle kan enes om, at det ville være rart med fejlfri produkter og få en fast procedure for udvikling af produkter uden fejl, såkaldt zero-defect development. Den almindelige holdning er vel, at det godt vil kunne lade sig gøre men at det også skal stå mål med omkostningerne og dermed underforstået, at det er dyrt at undgå fejl. Det er imidlertid helt forkert. Det er langt dyrere at finde og reparere fejl, end det er at undgå dem, men det er svært at diskutere emnet generelt, så hver enkelt virksomhed må undersøge de opståede fejl og vurdere, om det ikke ville have været billigere at undgå end udbedre. Det skal så søges gjort fremover, fordi det at gentage fejl, som ville være billigere helt at undgå, er en fejl på et mere overordnet niveau. Det er nemlig en fejl i organisationens måde at lære på. Men hvad er så 0-fejl udvikling? Og hvad vil det sige at levere et fejlfrit produkt? Er de to ting det samme? Nej, de er ikke det samme. Lad os tage et eksempel med et mødereferat, som vil være et fejlfrit produkt, hvis alle modtagere er enige i indholdet, og der ikke er stavefejl. Alligevel kan der godt være begået fejl undervejs. Der kan være tastet og stavet forkert, men det er blot blevet rettet. Nogle rettelser er blevet udført med det samme af den, der har tastet, mens andre er blevet rettet ved en efterfølgende korrekturlæsning. Der kan for eksempel være mailet et udkast til mødelederen eller til en af deltagerne for at kontrollere, om indholdet kan accepteres. Alt i alt kan der altså være foretaget mange rettelser og brugt megen tid på at få referatet fejlfrit. Der kan tilmed være brugt mere tid, end det er økonomisk forsvarligt, for at få det fejlfrit. Men det er fejlfrit. Den anden mulighed er at benytte sig af 0-fejl udvikling, hvor det handler om at få det rigtigt første gang. For eksempel ved at spørge, hvis der er noget, man er usikker på; ved at referenten skriver referatet under mødet; ved at konkludere åbent, før der sættes noget på prent og ved at lade deltagerne høre det foreløbige resultat, før mødet afsluttes. I efterproduktionen kan der også gøres meget. Hele referatet kan disponeres, før detaljerne kommer på plads og sætninger kan formuleres færdigt i hovedet, før de skrives. Alt sammen sker det for at undgå at begå fejl, og hvis man er utålmodig, synes man formentlig, at denne fremgangsmåde tager for lang tid. Men spørgsmålet er faktisk, om det er tidsspilde. i n d l e d n i n g 23
Det er let at fremstille fejlfri produkter, for det er kun et spørgsmål om at bruge den nødvendige tid og tilstrækkeligt mange penge. Det er ulige sværere at undgå fejl. Begrebet test i denne bog omfatter altså både at finde fejl, og helt at undgå at begå dem. I eksemplet med mødereferatet blev slutresultatet det samme, nemlig et fejlfrit produkt; men man skal bestemme sig på forhånd, hvis det skal ske i en fejlfri proces. Specielt skal man være sikker på, at der er tid til at rette fejl, hvis det er blevet strategien, så der ikke bliver tale om her-og-nu reparationer. Hvis der ikke er tid til at undgå fejl, er der vel ret beset heller ikke tid til at rette dem. 1.4 Tidlig, gentagbar og evig test Disse begreber kan ikke defineres entydigt. Det er mere tale om strategier, der benyttes for at opnå succes sammenlignet med investeringen. Normalt forstår man det, som fremgår af det følgende, når man benytter dem. Tidlig test udføres på projektets mellemresultater. Desuden omfatter begrebet tidlig planlægning af den maskinelle test, og fremstilling af testmateriale. For kodningens vedkommende er der bred enighed om, at testdata bør skrives før de programmer, som de skal teste. Det samme synspunkt er ved at vinde frem for andre produkters vedkommende. Tidlig test kræver ofte en revision af den udviklingsmodel, som organisationen anvender. En svaghed ved mange af de eksisterende modeller er nemlig, at test beskrives som en afgrænset fase, der er placeret sidst i forløbet. Testen af et produkt kan starte samtidig med udviklingen ved at være aktiv allerede i specifikationsfasen, mens man endnu diskuterer, hvad systemet skal kunne. Testen kræver planlægning, og det er en vigtig del af den præventive test, at testdata udarbejdes før udviklingen af dét, der skal testes med dem. Derfor må vi allerede nu kundgøre vores tro på, at: En test, der begynder direkte på maskinen, er som at programmere uden forudgående analyse og design. Gentagbar test er også en fornuftig metode. En god test er en test, der kan gentages 100 %. Det er en hjælp i udviklingsprojekterne, og er des- 24 k a p i t e l 1
uden på det nærmeste en kritisk faktor for succes i forvaltningsarbejdet. Det forudsætter værktøjer, der kan køre alle test automatisk med maskinel sammenligning af uddata, skærmbilleder og så videre. Evig test er vejen frem til stabile systemer. Det indebærer, at et system testes jævnligt i hele sin levetid. Ganske uanset om der er ændret i programmerne eller ej, kan omverdenen og de øvrige systemer have forandret sig. Forhold, der måske ikke var kritiske, da systemet blev sat i drift, kan være blevet afgørende senere. Ved jævnlig test, hvor man anvender både de oprindelige testcases og tilføjer nye på kritiske områder, kan man forebygge mange fejl og undgå megen brandslukning. 1.5 Nytten af registreringer Naturligvis er det primære formål med at finde fejl, at de bliver rettet. Men ved desuden at registrere det, der sker undervejs, kan der opnås flere fordele. Her er eksempler på nogle få faktorer. Det akkumulerede antal fundne fejl i et projektforløb kan registreres og afbildes i forhold til antallet af gennemførte testcases eller i forhold til den tid, der bruges på test. Kurven skal meget gerne flade markant ud som tegn på, at der efterhånden findes færre fejl. Sker det ikke, er det tegn på, at systemet er alvorlig sygt - og det vil ikke hjælpe bare at teste videre. Det er også en vigtig oplysning hvor fejlene optræder. Den samlede mængde fejl vil sjældent være jævnt fordelt. Størsteparten vil samles omkring design holes det vil sige moduler eller dele af systemet, der ikke er tænkt 100 % til bunds i løbet af udviklingsarbejdet. Indsatsen kan optimeres ved at identificere design holes tidligt, og det vil ofte bedst kunne betale sig at udvikle de berørte dele forfra. Det er ligeledes formålstjenligt at foretage registrering af First Passes, altså at testeren beregner hvor stor en del af testdata, der går rigtigt igennem i første forsøg. Områder med lav First-Pass godkendelsesrate er ensbetydende med mange rettelser og øger sandsynligheden for flere fejl senere. Omvendt vil områder med høj»first Pass«give færrest problemer senere. En analyse og registrering af fejlkilder kan bruges både i det aktu- i n d l e d n i n g 25
elle testforløb og af organisationen generelt. Når en fejlkilde er identificeret, bliver det nemmere at finde samme type fejl i andre systemer. 1.6 Nyudvikling eller systemforvaltning Uanset hvor lille en opgave er, vil der altid være brug for at overveje alle aspekter af test. Men jo mindre opgaven er, jo mere skal der vælges fra. Det drejer sig ikke om bestemte dele, så man kan ikke bygge sig en lille generel testmodel for små opgaver, og en udvidet model for større. Alle aspekter skal overvejes og vælge fra eller til for hver opgave. Et nyt udviklingsprojekt indebærer mange aspekter af test, mens billedet er mere broget for forvaltningsopgaver. Opgaven kan både være lettere og sværere, fordi man er meget afhængig af, hvad der er sket tidligere. Hvis principperne for aktiv systemforvaltning har været overholdt, vil der findes et testsystem. Hvis der kun har været udført passiv vedligeholdelse, kan der være dele af testen, som må falde bort, fordi en enkelt opgave ikke tidsmæssigt og økonomisk kan bære at etablere det manglende testsystem. Derfor er det bedst at samle et antal mindre opgaver sammen og etablere testfaciliteter som en del af opgaven. 1.7 Kvikstart Vedtag at test er en investering og ikke blot en omkostning. Beslut formålet med testen, offentliggør det, og mål løbende under testforløbene hvordan det går. 26 k a p i t e l 1
TESTENS FASER 2 2.1 Indledning 29 2.2 Komponenttest 34 2.3 Integrationstest 49 2.4 Systemtest 63 2.5 Brugertest 81 2.6 Alfatest 101 2.7 Betatest 102 2.8 Accepttest 102 2.9 De grundlæggende teststrategier 103 2.10 Kvikstart 109 t e s t e n s f a s e r 27
28 k a p i t e l 1
2.1 Indledning Et testforløb bygger på disse testfaser: Komponenttest Integrationstest Systemtest (funktionstest) Brugertest Alfatest Betatest Accepttest Komponenttesten finder fejl i de enkelte programmer; men kan imidlertid ikke finde alle tværgående fejl, fordi den tester hver komponent for sig. Alle programmeringsfejl kan imidlertid findes og rettes. Integrationstesten finder fejl i grænsefladerne mellem komponenterne og i grænsefladerne til andre systemer. Systemtesten skal vise, at hver funktion er til stede og fungerer. Systemtest går også under navnet funktionstest. Brugertesten tester, hvordan systemet opfører sig, når det bruges i forhold til scenarier og brugsrelevante hændelsesforløb. Alfatesten viser, hvordan systemet opfører sig i virkeligt brug. Et udvalg af virkelighedens scenarier afprøves i stabilt testmiljø, ofte i leverandørens organisation og driftsmiljø. Betatesten viser, hvordan systemet opfører sig i virkelig brug. Nogle udvalgte brugere anvender systemet i deres daglige arbejde. Accepttesten er en endelig godkendelse af systemet til generelt brug. I et udviklingsprojekt vil alle testfaser blive brugt. I et integrationsprojekt er det måske kun integrations- og accepttest, der er brug for, og også for andre typer af opgaver kan man vælge de testfaser, der er brug for. Ved køb af et standardsystem vil testen begynde med en brugertest, t e s t e n s f a s e r 29
fulgt op med en omfattende og længerevarende alfatest, og til sidst en omfattende og længerevarende betatest. Teststrategier Dette kapitel gennemgår indholdet af testfaserne uden at tage stilling til teststrategien. Den kan være et traditionelt forløb med testen placeret sidst, en mere offensiv V-model med tidlig planlægning, eller endda en radikal 0-fejl model med både tidlig planlægning og gennemførelse. Hvis dette kapitel læses uden særlige tanker om strategien, kan det virke, som om der lægges op til et traditionelt forløb. Det skal imidlertid ikke forstås anderledes, end at faserne beskrives i den rækkefølge, der er mest kendt, og med planlægning og gennemførelse umiddelbart efter hinanden. Sidst i kapitlet beskrives de tre hovedstrategier. Figur 2.1 viser et traditionelt testforløb. I hver udviklingsfase fremstilles nogle produkter, der er grundlag for den næste fase. I testfaserne fremstilles der ligeledes et produkt i form af et stedse mere testet system. Hver testfase skal planlægges og gennemføres. Planlægning betyder med jævne ord blot, at testen skrives ned, før den udføres. Man beskriver det ønskede forløb, og man dokumenterer de testdata, der skal bruges. I dagligdags testforløb kan man lægge mere eller mindre vægt på planlægning i forhold til gennemførelse. Ambitionsniveauet i hver af disse to hovedaktiviteter varierer ligeledes. Hvis testen overhovedet ikke planlægges, men kun gennemføres, betyder det, at testeren skal hitte på relevante testforløb og -data undervejs ved gennemførelsen. Hvis alt derimod planlægges og dokumenteres (inklusive alle testdata), er der ikke behov for testere til gennemførelsen som andet end ressourcer til at udføre det planlagte, og sammenligne med det dokumenteret forventede resultat. Testens dækning En testfase afsluttes, når den ønskede dækning er nået. Dækningen defineres forskelligt for hver testfase. I komponenttesten skal der dækkes en fastsat mængde af de mulige veje i komponenten. Integrationstesten skal opnå den fastsatte dækning af kald og variationerne i kald. I systemtesten skal der opnås en givet dækning af funktioner. Brugertesten skal dække brugssituationer, og accepttesten skal dække alle de definerede kriterier for accept. 30 k a p i t e l 2
Processen Produktet der udvikles Testprocessen Foranalyse Kravspecifi kation Analyse Løsning: Data og funktioner Design Udformning af systemets data, programmer og udseende Konstruktion Kode i programmer og skærmbilleder Komponenttest Dækning af kode i programmer og skærmbilleder Integrationstest Test af grænsefl ader Systemtest System Test af funktioner og data Brugertest System Test af scenarier og brugsrelevante forløb Alfa- og betatest System Test med virkelige scenarier og/eller virkelig brug Accepttest System Godkendelse til igangsætning Figur 2.1: Testfaserne t e s t e n s f a s e r 31
I tilfælde hvor der ikke er tid til at dække alt, eller i tilfælde som brugertesten, hvor der i princippet er et uendeligt antal mulige test, skal der suppleres med, at det er den kritiske dækning, der skal opnås. En dækning på 60 % kan være i orden, hvis det er netop de 60 % der betyder, at der ikke kan ske fejl af betydning. Et testforløb kan ende med en godkendt dækning som denne: Komponenttesten: 70 % af vejene Integrationstesten: 100 % af grænsefladerne og 80 % af de mulige dataværdier i kaldene Systemtesten: 100 % af funktionerne Brugertesten: 100 % af de scenarier, der omfatter kritiske funktioner, og 60 % af de øvrige Testens effektivitet Man kan betragte en testfase som et filter. Hver fase opfanger flere eller færre fejl, afhængigt af hvor meget der gøres ud af testen. Man skal gøre sig klart, at en given testfase kun finder bestemte typer fejl. For eksempel finder integrationstesten fejl i grænseflader, men ikke i funktionaliteten som en systemtest til gengæld gør. En fases effektivitet måles som den procentdel af fejlene, den finder. Det kendes i testverdenen som test efficiency, og hvis målet er 70 % betyder det, at man ønsker at finde 70 % af de fejl, der er i produktet, når testfasen starter. Ved at lade hver testfase finde 70 % af de fejl der er tilbage, nås frem til, at der kan releases med kun få resterende fejl. Man kan selvsagt ikke måle hvor mange af den samlede mængde fejl, man har fundet. Man kender først de resterende fejl efter idriftsættelse, men der skal alligevel arbejdes med procesforbedring på dette grundlag, selvom resultatet påvises med en vis forsinkelse. Aktiviteterne i planlægning og gennemførelse De to hovedaktiviteter, planlægning og gennemførelse af test, kan deles op i mindre aktiviteter. Planlægning af en testfase: Udpeg testere til planlægning af testfasen Opstil mål for dækningen Opdel testfasen i testaktiviteter, og beskriv hver aktivitet 32 k a p i t e l 2
Opstil detailplan for fasen ved hjælp af testaktiviteterne Udarbejd testcases for hver testaktivitet Gennemførelse af en testfase: Udpeg testere til gennemførelse af testfasen Vælg fra detailplanen hvad der kan og skal testes Gruppér eventuelt flere testaktiviteter til en testsession Opsæt testmiljøet Fremfind testcases til den eller de valgte testaktiviteter Gennemfør testcases, det vil sige indtastning eller igangsætning af job Sammenlign med det forventede resultat Skriv nye fejlrapporter Opdater de gamle fejlrapporter, der indgår i testsessionen Opdater fejlloggen/testloggen Skriv en samlet statusrapport med aftalte mellemrum Metoder, værktøjer og teknikker Testen kan i høj grad have nytte af værktøjer. Før man påbegynder en fase, skal der tages stilling til både metoder, værktøjer og teknikker. I den følgende gennemgang af hver testfase nævnes de væsentligste muligheder. Dokumentationsstandarden Bogens kapitel Planlægning og styring indeholder beskrivelser af de dokumenter, der refereres til i dette kapitel. Det gælder for eksempel detailplan, testaktivitet, testlog og så videre. Der er eksempler på brugen af dem i dette kapitel. Niveauer i prioritering Når der i teksten refereres til kritiske funktioner eller kritiske systemer, er der tænkt på denne opdeling i niveauer efter vigtighed: Niveau 1: Life-critical systemer Kan skade mennesker i betydelig grad i tilfælde af fejl. Niveau 2: Mission-Critical systemer Styrer irreversible processer, for eksempel produktionen på en fabrik, t e s t e n s f a s e r 33
der i sagens natur ikke kan gøres om. Niveau 3: MIS (Management Information Systems) Eller på jævnt dansk administrative systemer, hvor der i princippet kan rettes op på resultatet af brugen ved at foretage en omkørsel til en billig, eller i hvert fald acceptabel, pris. Niveau 4: List systemer Producerer information på serviceniveau, hvor fejlen ikke går videre i andre systemer. Risikoprofil og risikopoint I stedet for niveauer kan man anvende en formel model for risikoanalyse. Resultatet af analysen er en række mulige risici, der hver får point for sandsynlighed og konsekvens. Sandsynligheden defineres ofte således: 1= Der vil sandsynligvis ikke opstå problemer, men det er dog muligt 2= Det er lige så sandsynligt, at det sker, som at det ikke gør 3= Der vil sandsynligvis opstå problemer Konsekvens defineres ofte således: 1 = Konsekvensen kan opsuges med planens nuværende aktiviteter 3 = Der skal gøres noget for at afbøde konsekvensen 10 = Planen skrider, hvis dette sker Risikopointene kan nu regnes ud som sandsynlighed gange konsekvens. Se mere i Projektledelse af systemudvikling, jf. litteraturlisten. Det højeste antal point er således 30; men det er fornuftigt med en regel om at interessere sig for tocifrede risikopoint. 2.2 Komponenttest Formål Formålet er at teste hver komponent. Komponenten skal dækkes så grundigt i testen, at den både opfører sig som forventet, og er stabil i de efterfølgende testfaser. 34 k a p i t e l 2
Det handler om koden i programmer på mainframe og servere. Der kan desuden ligge kode i skærmbillederne på en eventuel klient. Det sidste er ofte tilfældet, når der udvikles med Visual C++, C# og Visual Basic i.net komponenter, Delphi, eller lignende. Komponenterne består primært af kode; men data testes også i en komponenttest, da brugen af dem indgår i hver test. I figur 2.1 er komponenterne resultatet af udviklernes arbejde i konstruktionsfasen. Tidligere kaldtes komponenttesten for programtest, og den blev som oftest udført ved at lade programmørerne selv teste. Komponenttesten var dermed en integreret og underforstået del af udviklingsarbejdet. I et moderne testforløb tages der mere bevidst stilling til, hvor formelt komponenttesten skal planlægges og gennemføres. Der tages også bevidst stilling til, hvem der skal være den ansvarlige tester. Komponenter med indhold, der er life critical eller mission critical, skal testes af andre end konstruktøren. Figur 2.2 (se næste side) viser elementerne i komponenttesten. Figuren viser en række komponenter, der indgår i testen; men det skal forstås, som at det typisk sker for en enkelt eller nogle få komponenter ad gangen. Komponenttesten skal sørge for, at koden prøves af. Det handler om at opnå en høj dækning af de fysiske veje i komponenterne. Jo flere veje i koden, jo mere omfattende bliver komponenttesten. Komponenttestens mulige omfang måles altså ikke i funktioner, men i veje (stier). En varieret komponenttest øger til stadighed dækningen af vejene. Kært barn har i øvrigt mange navne: programtest, modultest, unittest, komponenttest - det er alt sammen betegnelser for det samme. Planlægning af komponenttesten Udpeg testere til planlægning af komponenttesten Lad os slå fast med det samme: det er ikke en naturlov, at komponenttestens indhold planlægges af udvikleren selv, således som det har været reglen før i tiden. Der er brug for en mere nuanceret opfattelse. Rent teknisk-fagligt er der intet i vejen for, at planlægningen kan foretages af andre end konstruktøren. Hvis den skal planlægges som en whitebox-test, med krav om at nå en specifik dækning af veje, skal testeren blot have tilsvarende tekniske færdigheder. Der er brug for en konstruktør, der kan læse koden. Hvis testen planlægges som en blackboxtest, hvor der blot er krav om, at programmet i sin helhed opfører sig t e s t e n s f a s e r 35
Testere med teknisk indsigt Krav til komponenten Detailplan Fx. Gantt-skema Teknikker: Whitebox Værktøjer: statisk analyse dynamisk analyse Testaktivitet pr komponent Komponenter med kode Testcases Kode Komponenttest testmiljø Fejlrapporert Fejllog Testrapport med dækning af koden Figur 2.2: Elementerne i en komponenttest 36 k a p i t e l 2