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)