Modeller og testtyper
Herunder findes uddybende beskrivelse af de to udviklingsmodeller vi arbejder med. Desuden en beskrivelse af testtyper og testroller.
Demand/supply modellen (hybrid)
Demand/supply modellen ganske kort
- Der er mindst to parter involveret: Forretningen/kunden og leverandøren.
- Det er en kombination af vandfald (forretningen) og Scrum (leverandøren)
- Rollerne projektleder, Test Manager, Product Owner, Scrum Master og udvikler er besatte
- Der er en iboende konflik mellem projektets slut-dato og sprint-længde og -antal.
- Der skal etableres klare og målbare acceptkriterier på forhånd for at kunne overføre krav fra forretning til leverandør.
Demand/supply modellen lidt mere i dybden
Demand-/supply-modellen er hybrid af V-modellen og Scrum og refererer til ansvarsfordelingen mellem kunde (eller som oftest italesat: forretningen) på den ene side og leverandøren på den anden side. Forretningen anvender typisk en sekventiel, faseinddelt tilgang, som også ses i udformningen af kontrakten og de tilhørende prøver. Leverandøren (og AU IT) anvender derimod en agil tilgang i form af Scrum.
Leverandøren kan i modellen både være en intern IT-afdeligen og en ekstern leverandør. På AU er dette ofte tilfældet, hvor AU IT leverer integrationer ind i det samlede projekt, som typisk har en ekstern leverandør af et standardsystem.
Modellen er således et udtryk for, at der kan laves et skel mellem kunde, bruger, ledelse og drift på den ene side, og systemudvikler og leverandøren på den anden side. Skellet er på tegningen til højre markeret med den stiblede linje. Hvor linjen præcist skal gå, vil variere fra projekt til projekt. Nogle gange udarbejdes user stories og acceptkriterier af kunden/forretningen, andre gange af leverandøren. I nogle tilfælde er det kunden, der er ansvarlig for UAT´en, i andre tilfælde er det leverandøren. Når et projekt startes og teststrategien udarbejdes, kan det således være en fordel at tegne projektets stiblede linje, så ansvarsfordeligen er klar og tydelig, og så der er enighed om, hvem, der tester hvad og hvornår - og hvem der accepterer systemet (og godkender kvaliteten).
Tegningen indikerer, at systemtesten ligger på leverandør-/AU ITs side. Det er oftest korrekt, men det skal bemærkes, at forretningens domæneviden og datakendskab ofte vil være både værdifuld og nødvendig at inddrage i testdesign og testafvikling for at sikre den bedste test.
Der kan ligge nogle implicitte konflikter i modellen. Forretningens projektleder vil typisk have en slut-dato for hele projektet, mens Scrum teamet beslutter, hvad der leveres sprint for sprint. Det betyder, at der er forskel på deres mål:
- Forretningen sætter kravene og validerer, at de faktisk er blevet leveret, og at den forventede forretningsværdi faktisk nås.
- Leverandøren leverer IT-systemet/integrationerne og demonstrerer, at det, der er aftalt, faktisk er blevet leveret.
Dvs. at der er to klare kvalitetsgates: En, hvor forretningen overleverer deres krav til leverandøren og en, hvor leverandøren overleverer IT-leverancen til forretningen. Ofte er der dog tale om et samarbejde, både i forhold til formulering af krav og i forhold til accepttesten. De to gates illustreres der, hvor den stiblede linje krydser V-modellens kurve.
Som Test Manger bør følgende overvejes, når der arbejdes efter denne model:
- Definer den forventede kvalitet
- Hvad er den forventede kvalitet af IT-systemet, som leveres af leverandøren? Test Manager skal sammen med forretningen indtænke dette fra start af, og dette skal formidles videre til leverandøren så tidligt som muligt.
- Definer ekstra test
- Hvad er allerede testet af leverandren og med hvilken dækning?
-
En moden leverandør vil kunne fremvise leverandørens teststrategi og testrapporter. Dermed kan test manageren etablere en accepttest teststrategi, som dækker de risici, som ikke allerede er dækket af leverandøren.
- En mindre moden leverandør, som ikke kan/vil fremvise deres testdokumentation betyder, at test manageren må anvende en anden tilgang til at få afdækket kvaliteten i leverancen. Det kunne eksempelvis være i form af en modtage-test (eventuelt udforskende) for at få en hurtig vurdering af kvaliteten - og på den baggrund beslutte, hvordan den øvrige test skal planlægges. Hvis modtagetesten påviser kritiske eller mange fejl, er det sandsynligvis nødvendigt at foretage ekstra systemtest, selvom det egentligt er leverandørens ansvar.
-
- Hvad er allerede testet af leverandren og med hvilken dækning?
V-modellen
Vi tager udgangspunkt i V-modellen, når vi tilrettelægger den samlede test i et udviklingsforløb. V-modellen er med til at synliggøre, at test ikke er en aktivitet, som vi gennemfører isoleret i halen af et udviklingsforløb, hvor tilbageløb og rettelser er svære, dyre og tidspressede. I stedet er test en stribe integrerede aktiviteter, som starter allerede ved projektstart/opgavestart.
Det er vigtigt at være opmærksom på testprogrammets forankring i, at alle udviklings- og testforløb vil være præget af tilbageløb (man bliver hele tiden klogere), gensidig påvirkning mellem udvikling og test (det ene åbner for perspektiver på det andet), og den præmis, at scope kan ændre sig undervejs (både creep og reduction). Dette er vist i V-modellen som pile, der peger i begge retninger (både frem og tilbage).
Det primære formål med V-modellen er at skabe sammenhæng mellem udvikling og test.
V’et i V-modellen kan betyde både Validering og Verifikation.
- Validering er de aktiviteter, der beskæftiger sig med at afgøre, om det er det rigtige system/software vi bygger
- Verifikation drejer sig om at tjekke, om vi har bygget tingene rigtigt. Eller sagt på en anden måde: Svarer det udviklede software til det, vi forventede?
V-modellen findes i et utal af varianter, der hver især fokuserer på forskellige aspekter af sammenhængen mellem udvikling og test.
I forhold til at anvende V-modellen, er det vigtigt at være opmærksom på, at V-modellen er meget åben for fortolkning. Projektdeltagere, der tidligere har arbejdet med V-modellen i andre projekter, forstår ikke nødvendigvis modellen på samme måde.
De orange kasser er aktiviteter, hvor opgavestiller har et stort ansvar ('Forretningen').
De blå kasser er aktiviteter, hvor hovedansvaret ligger hos AU IT.
De testrelaterede aktiviteter
De testrelaterede aktiviteter er i mange modeller af v-modellen beskrevet som værende "test case design", men i virkeligheden er "testplan design" mere korrekt. For hvert niveau i venstre-benet forberedes højre-benets tilsvarende testniveau. I praksis betyder det:
- Testniveauet afdækkes i forhold til relevante testtyper, der ønskes udført.
- Der foretages testanalyse og testdesign til hver testtype
- Der udarbejdes en testplan (evt. en plan pr. testtype), herunder:
- Nødvendig testdata identificeres (og klargøres allerede nu, hvis muligt)
- Nødvendigt testmiljø(er) identificeres, bookes jf. AU ITs booking-proces (og klargøres allerede nu, hvis muligt)
- Aftaler i forhold til bemanding af testafviklingen sikres
- Der sikres løbende fremdrift på og overvågning af de igangværende aktiviteter.
Der vil være aktiviteter relatereret til ét niveau, som først kan afklares på et senere tidspunkt i processen. Den fulde planlægning og forberedelse vil således være en iterativ proces, som beskrevet ovenfor og som illustreret i modellen ved pile, der peger både frem og tilbage (og op og ned mellem niveauerne).
Checkliste til testniveauer - udarbejdet i kursussammenhæng
Nedenstående checkliste er udarbejdet som en øvelse i forbindelse med ISTQB-kurset 'Advanced test manager'. Listen er tilføjet som en opmærksomhedsskaber - og til inspiration.
Testtyper
Kortlægningen af og overblikket over de testtyper, AU anvender, er helt essentielt for implementeringen af struktureret test. På nedenstående links findes en beskrivelse af hver af de testtyper, som AU som udgangspunkt anvender.
Simmuleret systemintegrationstest (SSIT)
Testroller
Nedenstående beskriver roller og nødvendige kompetencer i fbm test i projekter og forvaltningsopgaver.
Roller ifbm. AU ITs test af egne leverancer | Ansvar - ifbm. projekter | Ansvar ifbm. den enkelte udviklingsopgaver i forvaltning |
Test Manager | I forbindelse med det samlede projekt: Sikre, at fyldestgørende og tilstrækkelig test planlægges, designes og gennemføres. Overordnet er det test managers opgave at planlægge, overvåge og kontrollere det samlede projekts test og testaktiviteter. Dette indbefatter følgende:
I større projekter kan rollen med fordel varetages af to forskellige personer med ansvar for hhv. AU ITs test og forretningens test. | I forbindelse med den samlede udviklingsopgave i forvaltningen: Sikring af, at der, med udgangspunkt i den generiske teststrategi for forvaltningsopgaver:
NB: I forvaltningen har testkoordinator oftest ovenstående ansvar |
Test koordinator | I forbindelse med den enkelte test: Styring og koordinering af de enkelte test gennemløb. Koordinering mellem involverede parter i den konkrete test (opgavestillers organisation, leverandør, afdelinger i AU IT, testere). Sikring af, at testere er godt forberedt på opgaven. Sikring af, at testdata er til rådighed. Sikring af, at testmiljøer er reserveret. Sikring af og opfølgning på fremdriften i de enkelte test gennemløb. Opsamling, screening og kommunikation af testobservationer. | I forbindelse med den enkelte test: Styring og koordinering af de enkelte test gennemløb. Koordinering mellem involverede parter i den konkrete test (opgavestillers organisation, leverandør, afdelinger i AU IT, testere). Sikring af, at testere er godt forberedt på opgaven. Sikring af, at testdata er til rådighed. Sikring af, at testmiljøer er reserveret. Sikring af og opfølgning på fremdriften i de enkelte test gennemløb. Opsamling, screening og kommunikation af testobservationer. |
Tester | I forbindelse med den enkelte test: Laver analyse af testgrundlag. Laver test case design og skriver testcases. Angiver krav til testdata (typer og mængde). Afvikler tests, evaluerer resultater og laver hændelsesrapporter. Reviewer testcases, der er udviklet af andre. | I forbindelse med den enkelte test: Laver analyse af testgrundlag. Laver test case design og skriver testcases. Angiver krav til testdata (typer og mængde). Afvikler tests, evaluerer resultater og laver hændelsesrapporter. Reviewer testcases, der er udviklet af andre. |
Teknisk Tester | I forbindelse med den enkelte test: Samme opgaver som Tester. Testautomatisering. | I forbindelse med den enkelte test: Samme opgaver som Tester. Testautomatisering. |
Forretningstester | I forbindelse med den enkelte test: Dataekspert Domæneekspert Indgår i verificirering af migrerede data og andre tests, som kræver højt data- og/eller domænekendskab. | I forbindelse med den enkelte test: Dataekspert Domæneekspert Indgår i verificirering af migrerede data og andre tests, som kræver højt data- og/eller domænekendskab. |
Styregruppe | I forbindelse med det samlede projekt: Godkendelse af teststrategi. Godkendelse af acceptkriterier for godkendelsen af det kommende produkts kvalitet. Godkendelse af / iværksættelse af korrigerende handlinger på baggrund af testrapporteringer. Godkendelse til produktion af det kommende produkt. | n/a |
Projektejer | I forbindelse med det samlede projekt: Sikring af, at behovs-/kravspecfikationen er review'et og godkendt af projektets interessenter. Sikring af, at behovs-/kravspecfikationen er testbar og med definerede acceptkriterier. Sikring af ressourcer til forretningsafklaringer og reviews af løsningsspecifikationer samt dynamisk test på alle testniveauer. | I forbindelse med den samlede udviklingsopgave i forvaltningen: Tilsvarer tilnærmelsesvis rollen "Systemejer": Sikre prioritering af funktionelle såvel som non funktionelle forvaltningsopgave. Sikre, at der etableres en teststrategi ind i systemets forvaltningsaftale, som skal sætte rammerne for udviklingsopgavers test fremadrettet. |
Projektleder | I forbindelse med det samlede projekt: Projektlederen leder projektet og har derfor også ansvaret for at sikre test management i projektet. Sikring af acceptkriterier for godkendelsen af det kommende produkts kvalitet. Sikring af ressourcer til rollebesættelsen af testprocessens aktiviteter gennem projektforløbet. Sikring af kommunikationskanaler i projektet. Håndtering af problemer indenfor og udenfor projektet, som konstateres i forbindelse med testen, og som har afhængigheder til og indflydelse på testen (eksempelvis andre systemer eller processer). Sikre rapportering af test fremdrift, status, indstillinger og fejl til projektejer og styregruppe. | n/a |
Product Owner | I forbindelse med det samlede projekt/i sprint: Definition af, hvilke krav der skal opfyldes for at opnå produktets ønskede kvalitet, typisk i form af formulering af acceptkriterier for hvert PBI (product backlog item). Hjælpe med at prioritere testopgaverne ved at deltage i risikovurderingen af hvert enkelt PBI og med særligt fokus på den forretningsmæssige risiko. Besvare spørgsmål og sikre afklaringer fra Scrum teamet (herunder testeren), både under Backlog Refinement og undervejs i sprints. | I forbindelse med den samlede udviklingsopgave i forvaltningen: Tilsvarer tilnærmelsesvis rollen "systemforvalter": Sikrer nødvendige brugertest af systemet og dets integrationer og varetager kommunikation med systemejer og sikrer nødvendige godkendelser fra denne. Systemejer skal til gengæld sikre prioritering af funktionelle såvel som non funktionelle forvaltningsopgaver. |
Scrum Master | I forbindelse med sprint: Fjerne forhindringer - Scrum Master skal hjælpe med at fjerne eventuelle forhindringer, der kan hindre Scrum teamet (inkl. testeren) i at udføre deres testopgaver effektivt, herunder sørge for, at de har de nødvendige ressourcer og adgang til det nødvendige udstyr og software. Sikring af, at test og eventuelt tester (såfremt denne rolle er tilknyttet Scrum-teamet) er involveret i backlog refinement, sprint planning, sprint review og retrospektivmøder. | n/a |
Scrum Team | I forbindelse med sprint: Ansvarlig for at sikre, at softwareproduktet opfylder de krav, der er defineret af Product Owner, og for at produktet leveres til tiden og med den ønskede kvalitet. Planlægning af testaktiviteter i sprintet og identifikation af de vigtigste testscenarier. Testafvikling og rapportering på testresultaterne - manuel test, automatiseret test eller en kombination. | n/a |
Værktøjer til testmanagement og testautomatisering
Generelt set findes der et hav af testautomatiseringsværktøjer i markedet. Ligesom de forskellige testtyper har forskellige formål, de forskellige testteknikker finder forskellige typer fejl, lige sådan forholder det sig med værktøjer til testautomatisering. Der findes værktøjer, der er egnede til eksempelvis API-test, til performancetest, til svartidsmålinger osv. Tilsvarende findes der forskellige værktøjer til testafvikling og til test management.
Det er derfor essentielt at vide, hvad det helt konkrete behov er, inden der vælges et værktøj. Derudover er der en række parametre, som kan have betydning for valg af værktøj:
- Formål med værktøjet?
- Hvilke behov og krav skal værktøjet kunne opfylde?
- Økonomi - pris, licensomkostninger? Open Source?
- Teknologiunderstøttelse - hvilke teknologier skal værktøjet kunne understøtte? Nu og på sigt?
- Hvilke værktøjer er allerede tilgængelige i AU?
- Hvem skal forvalte et nyt værktøj?
- Er der nogen, der allerede har kendskab til værktøjet? Kræver det undervisning at komme i gang? Hvor stejl læringskurve forventes?
- Hvad kræver det at vedligeholde værktøjet?
- Kan værktøjet "spille sammen med" øvrige værktøjer? Kan testresultater fra automatiske tests eksempelvis opsamles i test management-værktøjet - og understøttes sporbarhed?
- Sker der løbende udvikling af værktøjet eller har det ligget stille over længere tid? Hvor mange gange om året kommer der eksempelvis releases?
- Hvem skal anvende værktøjet? Skal det kunne benyttes af alle, eller er det ok at det kun er til udviklerne?
- Ydes der support på værktøjet? Er der hjælp at hente, hvis der er behov for det?
- Kan der indhentes referencer? Enten fra andre enheder i AU, der anvender værktøjet, eller eksternt?
- Skal værktøjet kunne anvendes på tværs af projekter/forvaltning?
Listen med gode spørgsmål er ikke udtømmende, men den indikerer, at et værktøjsvalg aldrig kan stå alene - det skal altid holdes op imod den kontekst, det skal indgå i og det konkrete behov.