Test management Archives - Key2Quality

Rikke kombinerer sine kompetencer som testmanager med rollen som Scrum Master

Trine Zachariassen — Thu, 19 Jun 2025 05:54:09 +0000

Hos Key2Quality tror vi på, at stærke resultater starter med stærke profiler – og dem finder vi ofte i krydsfeltet mellem roller. Rikke Volff Svendsen er et godt eksempel: Hun forener testmanagerens skarpe blik for kvalitet med Scrum Masterens evne til at skabe flow og samarbejde.

Når Rikke kombinerer de to perspektiver, løfter det både kvaliteten i løsningen – og dynamikken i teamet.

Vi har spurgt hende, hvordan hendes testfaglige baggrund differentierer hende som Scrum Master – og hvilken værdi det skaber for kunderne.

Hvordan bruger du dine kompetencer som testmanager i rollen som Scrum Master?

Som Scrum Master er det min opgave hele tiden at få teamet til at yde deres bedste, og her er det en stor styrke at have test manager-værktøjskassen med:

Stakeholder management, samarbejde, risikovurdering og struktur er eksempler på testmanager-kompetencer, som jeg bruger rigtig meget i mit arbejde som Scrum Master.

Min forståelse for kodesprog giver mig desuden mulighed for at stille de rigtige spørgsmål – spørgsmål, der kan afdække teknisk gæld eller risici i løsninger og testscenarier.

Struktur er et nøgleelement. Jeg hjælper teamet med at arbejde fokuseret og prioriteret – ofte med udgangspunkt i risikovurderinger, så vi bruger tiden på det, der betyder mest for projektets succes.

Hvordan oplever du, at din baggrund som testmanager skaber værdi i din rolle som Scrum Master?

Jeg ser ofte, at teams mangler modenhed, når det kommer til kvalitetssikring. Her er mine testkompetencer en klar fordel. Jeg bringer fokus på kvalitet fra start – allerede i idéfasen – så vi undgår ubehagelige overraskelser senere i processen.

Når vi tænker kvalitet ind tidligt, får vi ikke bare bedre løsninger – vi får også en mere rolig og forudsigelig udviklingsproces.

Kan du give et konkret eksempel på, hvordan dine testkompetencer har gjort en forskel i et agilt team?

I et team med nyuddannede udviklere fik vi tidligt etableret testautomatisering med fokus på de vigtigste scenarier. Jeg hjalp teamet med at risikovurdere og undgik, at vi brugte unødvendige ressourcer på at automatisere alt.

Et andet eksempel er, da jeg i et projekt insisterede på performance test – trods ledelsens oprindelige fravalg. Testen afslørede kritiske problemer i kodestrukturen, som vi ellers ikke ville have opdaget. Den indsats førte til, at performance test blev en fast del af Definition of Done i teamet.

Hvordan påvirker din testfaglighed teamets tilgang til kvalitet og leverancer?

For mig er det helt naturligt at tænke i test og kvalitet – og det smitter af på teamet. Jeg sørger for, at vores Definition of Done afspejler kvalitetssikring, og jeg hjælper teamet med at forstå, hvad god kvalitet indebærer.

Jeg følger også op efter leverancer med dashboards og rapportering på kodekvalitet og fejl – og faciliterer root cause analyser, som bliver brugt som input til vores retrospectives og kontinuerlige forbedringer.

I hvilke situationer har det været en fordel, at du både forstår de agile processer og teststrategiske overvejelser?

Især når vi arbejder med MVP’er (Minimum Viable Products), er det vigtigt med en balance mellem udvikling og kvalitet. Her fungerer jeg som brobygger mellem forretning, udvikling og test – og hjælper med at sikre, at vi hele tiden har styr på kvaliteten.

Min forståelse for test i agile teams er også vigtig, når det handler om at tage små, men vigtige skridt mod bedre kvalitet. Det kræver erfaring at kunne guide et team gennem den rejse.

Hvordan balancerer du de to “hatte” – facilitering som Scrum Master og det mere detaljerede fokus som testmanager?

Jeg gør det klart for teamet, hvornår jeg taler som Scrum Master – og hvornår jeg træder i karakter som testmanager. Det giver transparens og tydelige rammer.

Detaljefokusset fra testrollen er noget, jeg også bringer med ind i Scrum Master-opgaverne. Det skaber nærvær og en mere ligeværdig relation i teamet, fordi jeg er en del af udviklingsarbejdet – blot med en anden faglighed.

Hvor adskiller du dig, efter din mening, fra andre Scrum Masters, der ikke har samme testbaggrund?

Min testfaglighed gør, at jeg er mere detaljeorienteret og stiller andre typer spørgsmål – særligt om risici og kvalitet.

Som Scrum Master arbejder jeg med teaching, mentoring, coaching og facilitering. Min erfaring gør, at jeg især kan løfte teamet gennem mentoring og teaching i kvalitetssikring – uden at tage opgaverne fra dem.

Jeg taler både forretningens og udviklernes sprog – og kan oversætte teori til praksis i det tempo, der passer til teamet. Det gør en forskel.

Hvordan bruger du din testviden til at støtte Product Owneren i backlog refinement og prioritering?

Jeg har løbende dialoger med Product Owneren, hvor jeg hjælper med at identificere og tydeliggøre risici – fx i forhold til performance, sikkerhed eller non-funktionelle krav, der let bliver overset.

Min viden om testteknikker og flowdiagrammer gør det lettere at visualisere opgaver og hjælpe med at oversætte krav til udviklernes verden.

Samarbejdet med Product Owneren er alfa omega i, at teamet performer.

Ser du, at din erfaring påvirker måden, du stiller spørgsmål på i retrospectives eller daglige standups?

Helt sikkert. Jeg stiller ofte spørgsmål, der går på, hvordan vi har testet – og hvad vi kunne gøre anderledes næste gang.

I retrospectives bruger jeg gerne værktøjer som root cause analysis til at grave et spadestik dybere og sikre, at vi lærer af vores erfaringer på et struktureret grundlag.

Hvordan bidrager dine kompetencer til at skabe et mere proaktivt fokus på risici og teknisk gæld i teamet?

Min styrke ligger i at samle trådene mellem team og Product Owner – og sørge for, at risici bliver synlige i tide.

Ved at være med fra starten af udviklingsprocessen kan jeg stille de spørgsmål, der gør forskellen – og sikre, at vi ikke ignorerer teknisk gæld eller skjulte udfordringer.

Har du oplevet, at dit kvalitetsfokus har ændret teamets kultur eller mindset? I så fald – hvordan?

Ja, mange gange. Når jeg introducerer testdesign og synliggør, hvordan det hjælper både udvikling og test, så begynder teamet selv at tage det til sig.

En udvikler begyndte eksempelvis selv at bruge testteknikker i sin kode efter at have set, hvordan det hjalp. Det var fantastisk at opleve.

Jeg plejer at sige: “Hvis du ikke ved, hvad du skal teste – hvordan ved du så, hvad du skal udvikle?” Det skaber en fælles forståelse i teamet – fx når vi laver cyklustest eller beslutningstabeller tidligt i processen.

Det er her, jeg virkelig ser værdien i at kombinere testmanager- og Scrum Master-rollen – det styrker både kvalitet og effektivitet.

Rikkes spidskompetencer

Fokus på kvalitet fra første sprint
Spotter risici, før de bliver til problemer
Gør test forståelig og operationel for hele teamet
Skaber fremdrift og ro i komplekse projekter

The post Rikke kombinerer sine kompetencer som testmanager med rollen som Scrum Master appeared first on Key2Quality.

Mød en konsulent: Alberte Sørensen

Trine Zachariassen — Thu, 12 Jun 2025 04:50:59 +0000

Hos Key2Quality er vi så privilegerede at huse nogle fantastisk dygtige konsulenter. Konsulenter, som alle skaber værdi for vores kunder med deres kompetencer inden for softwaretest, IT-kvalitet og IT-projektledelse. En af dem er Alberte Sørensen – en engageret og grundig testkonsulent, der med sit skarpe blik for detaljen og sin analytiske tilgang bidrager til at løfte både kvalitet og samarbejde i de projekter, hun indgår i.

Som testkonsulent hos Key2Quality har Alberte oparbejdet solid erfaring med testanalyse, testdækning, udarbejdelse og forbedring af testcases samt test management. Hendes evne til at strukturere, koordinere og skabe overblik gør hende til en stærk ressource i komplekse projekter.

Tidligere kunder beskriver hende som “meget opsøgende, proaktiv og ikke bange for at udfordre – hun siger til, hvis der er noget, man skal være opmærksom på.” Det er netop denne kombination af faglighed og integritet, der gør hende til en værdsat kollega og konsulent.

Alberte er også en vigtig del af holdet internt i Key2Quality, hvor hun fungerer som mentor for vores aspiranter og bidrager til at løfte det faglige niveau i organisationen.

Hun er uddannet cand.it. i Informationsvidenskab fra Aarhus Universitet (2021) og har en stor faglig nysgerrighed, som afspejler sig i hendes tilgang til læring. Alberte elsker at lære nyt – og går gerne til eksamen. Trods sine kun 30 år har hun derfor allerede opnået certificeringer i hele fem anerkendte kurser inden for ISTQB og TMAP. Men som hun selv siger med et glimt i øjet:

“Jeg må nok hellere vente med at tage ‘ISTQB Expert Test Manager’, til jeg har lidt flere års erfaring.”

Hvad kan du godt lide ved at arbejde som konsulent?

Jeg trives med variationen og muligheden for at dykke ned i forskellige typer IT-projekter og organisationer. Det giver mig en bredere forståelse og udfordrer mig fagligt. Jeg nyder processen med at identificere potentielle problemer og bidrage til at finde løsninger, da det styrker min testfaglighed i forskellige kontekster.

Hvordan hjælper du vores kunder med at skabe værdi? Hvordan gør du en forskel for dem?

Jeg arbejder målrettet for at sikre kvaliteten i projekterne. Det handler om at teste de rigtige ting på det rigtige tidspunkt og skabe overblik, så kunden kan træffe informerede beslutninger før go-live. Jeg trives også i en coachende rolle, hvor jeg hjælper teamet med at anvende testfagligheden effektivt i deres arbejde.

Hvad er dit faglige speciale? Hvorfor netop det, og hvordan kommer det i spil i dine opgaver?

Mit speciale er test og kvalitetssikring, hvilket passer godt til min detaljeorienterede og analytiske tilgang. Jeg stiller ofte de spørgsmål, som andre måske overser, og jeg dykker ned i komplekse systemer for at forstå, hvad der fungerer, og hvad der kan forbedres. Min grundighed og realisme i forhold til deadlines er også en styrke i mit arbejde.

Hvad motiverer dig mest i dit arbejde?

Jeg motiveres af at løse testfaglige udfordringer, især i samarbejde med engagerede kunder og kollegaer. Det giver mig energi at se, hvordan mit arbejde gør en forskel og bidrager til projektets succes.

Hvordan holder du dig opdateret og skarp i dit felt?

Jeg holder mig fagligt skarp ved at tage relevante certificeringer og arbejde med vores e-learning-platform, som både udfordrer og udvider min viden. Derudover deltager jeg aktivt i interne guildmøder og søger inspiration fra forskellige kilder, herunder ChatGPT, for at få nye perspektiver.

Hvordan ser en typisk arbejdsdag ud for dig?

Mine arbejdsdage varierer afhængigt af opgaven. Som test lead involverer en typisk dag møder, koordinering og planlægning med forskellige interessenter som release management og projektledelse. Jeg sparrer også med teamet om opgaveprioritering og problemløsning. I andre projekter fokuserer jeg mere på analysearbejde, hvor jeg kortlægger testgrundlaget og vurderer anvendelsen af testdesignteknikker.

Hvad kendetegner en god konsulent, efter din mening?

En god konsulent udviser ordentlighed, faglighed og glæde. Med ordentlighed mener jeg, at konsulenten er problemløsende, proaktiv og transparent i sin kommunikation. Det er vigtigt at afstemme forventninger med kunden og være ærlig om, hvad der er muligt. Fagligheden er selvfølgelig også vigtig. Understøttet af et stærkt bagland giver den faglige ballast troværdighed og gennemslagskraft. Glæde og engagement er også afgørende, især for at løfte teamets motivation og opbygge de relationer, som gør, at teamet skaber reel værdi.

Er der et projekt eller en opgave, som du bliver særligt glad eller stolt af at tænke tilbage på?

CRM-projektet for en kunde i energisektoren var både spændende og komplekst, og jeg arbejdede sammen med mange dygtige mennesker. Det var en opgave, der virkelig udfordrede mig og gav mig mulighed for at anvende mine færdigheder fuldt ud.

Hvad laver du, når du ikke er på arbejde? Har du en særlig passion?

Jeg nyder god mad, især når jeg ikke selv skal lave den, og jeg værdsætter tid med mine nærmeste. Jeg holder også af at være i naturen og tager ofte på vandre- og shelterture. I efteråret 2024 gik jeg for eksempel Caminoen, som længe havde stået på min ønskeliste.

Hvordan vil du beskrive Key2Quality med tre ord?

Ordentlighed, faglighed og glæde. Disse værdier gennemsyrer vores arbejde og samarbejde med kunderne.

The post Mød en konsulent: Alberte Sørensen appeared first on Key2Quality.

Derfor er standardsystemer ikke plug-and-play

Trine Zachariassen — Thu, 10 Apr 2025 06:10:34 +0000

”Nej, det er da ikke nødvendigt at teste – det er et standardsystem, vi implementerer”. Har du hørt den kommentar før?

Nogle af de antagelser, jeg har mødt igennem årene omkring standard løsninger, har været:

”Det virker jo allerede – andre bruger det jo.”
”Vi behøver ikke test – vi regner ikke med at lave ændringer.”
”Det er hurtigt og billigt at implementere.”
”Vi kan tilpasse vores processer til systemet.”
”Leverandøren tager sig af det.”
”Brugerne lærer det bare henad vejen.”

Alt for ofte ser vi organisationer, der kæmper med at lykkes med at implementere f.eks. nye CRM- eller ERP-systemer, fordi man har undervurderet opgaven.

I denne artikel vil vi dykke ned i, hvorfor implementering af standardsystemer ikke altid er helt så simple, som det ser ud til udefra, og med testbrillerne på vil vi komme med anbefalinger til, hvordan vi kan gribe kvalitetssikringen af disse implementeringsprojekter an.

Men lad os lige starte med en definition:

En standardløsning refererer til en softwarepakke designet til at imødekomme de generelle behov hos en bred vifte af brugere eller organisationer. Disse løsninger er færdigudviklede produkter, der kan implementeres uden væsentlige ændringer.

Her bider jeg mærke i to ting:

”Disse løsninger er færdigudviklede produkter”
”kan implementeres uden væsentlige ændringer”

Umiddelbart lyder det fantastisk, men for de fleste organisationer er det bare ikke den virkelighed, de står overfor, når først de kommer i gang. Lad os prøve at dykke ned i nogle af udfordringerne.

Udfordringer

Processer og arbejdsgange

Hvis vi tager udgangspunkt i Dynamics 365FO, kommer det ganske rigtigt som en færdigudviklet løsning med en hel pakke med en struktur af foruddefinerede processer og arbejdsgange – og en brugerflade, der supporterer dem. Men her er der lige en håndfuld spørgsmål, som vi skal huske at stille:

Hvordan ser vores arbejdsgange ud i dag?
Har vi styr på, hvor mange der er? Og er de dokumenteret?
Passer vores arbejdsgange til de standardprocesser, der er implementeret?
Er det praktisk muligt at ændre vores arbejdsgange, eller er det systemet, der skal ændres?
Har vi alle de felter til rådighed i de forskellige skærmbilleder, for at vi kan gennemføre de forskellige arbejdsgange, vi har identificeret?

Testfokus kan have stor værdi i arbejdet med processer: Det kan identificere uoverensstemmelser mellem standardprocesser og virksomhedens arbejdsgange tidligt i forløbet gennem workshops med testcases baseret på rigtige arbejdsgange til at validere, om systemet fungerer i praksis.

Test af konfigurationen kan afsløre, om systemets standardfunktionalitet understøtter de eksisterende arbejdsgange, eller om der er behov for tilpasninger. Hvis strategien er at tilpasse forretningen til systemet (i stedet for at tilpasse systemet), kan test vise, om ændringerne er realistiske for medarbejderne.

I komplekse organisationer er processer ofte afhængige af flere systemer og aktører. En test med end-to-end scenarier kan afsløre, om f.eks. en ordreproces fungerer på tværs af ERP, lager- og finanssystemer.

Data

Den næste udfordring, vi kan stå overfor, er dataaspektet. Dette afhænger en del af, hvorvidt vi migrerer fra et andet system og skal have data med over, eller om vi starter på en frisk. Hvis organisationen hører til en af de første, så er det værd at stille spørgsmål som:

Hvor ligger data i dag? Er data spredt over flere systemer, regneark og manuelle processer?
Er alle nødvendige data tilgængelige, eller findes de slet ikke i struktureret form?
Hvem ejer data? Hvilke afdelinger eller systemer har autoritet over hvilke data?
Hvem har ansvaret for data efter implementeringen? Hvem opdaterer og vedligeholder?
Har vi styr på politikker, så datakvaliteten ikke sander til over tid?
Hvordan er den nuværende datakvalitet? Er der mange dubletter, er der fejl i data, mangler der nøgledata?
Er data standardiseret i dag? Er der f.eks. en ensartet brug af landekoder mv.?

Når vi taler om data, kan vi heller ikke komme udenom datamigrering.

Hvordan flytter vi data fra det gamle til det nye system? Big bang eller bulks?
Hvordan håndterer vi historiske data? Skal alt migreres med over, eller tager vi først fra et vist tidspunkt? Hvis det sidste er tilfældet, hvad er så konsekvensen af at udelade data?
Hvad gør vi med fejlbehæftede eller ufuldstændige data?
Hvordan sikrer vi, at alle relevante data er overført korrekt?

Dette kræver også test – både med fokus på datakvaliteten i forbindelse med migration i form af datavalideringstest, hvor den migrerede data sammenlignes med den originale – men også dataflow test, hvor fokus er på, at data bevæger sig korrekt både internt i systemet og mellem systemerne. Det bringer os videre til næste udfordring.

Integrationer

Og lad os også lige tale om en af de klassiske elefanter i rummet, integrationer. Som testmanager er det virkelig et af mine yndlingsord, ”integrationer”. Mest fordi det er sådan en ”sjov” testopgave, som gang på gang bliver undervurderet. Jeg tror, den bedste kommentar jeg har fået i den kontekst er, ”Vi har testet ud til snitfladen, så vi ved, at det virker”. Famous last words. Selvom det er to standardsystemer, der skal integreres, kan det være en stor udfordring, og det er essentielt, at der er fokus på integrationerne fra dag 1:

Hvilke systemer skal vores nye ERP-løsning integrere til?
Hvordan virker integrationen? Bulk loads? Delta overførsel? Realtids push?
Har vi defineret klare snitflader? Har vi helt styr på feltformaterne i begge ender af integrationerne?
Har vi fået mappet alle de data, der skal flyde mellem systemerne?
Har vi klart overblik over, hvem der har ejerskab over data? F.eks. hvis nu vores Dynamics skal integrere til et HR-system, hvilket af systemerne ejer så løndata? Persondata?

Regulatoriske krav og governance

Og så er der selvfølgelig også det med den generelle governance såvel som regulatoriske krav:

Hvordan styrer vi adgangsstyring og datasikkerhed?
Hvem må se hvilke data i det nye system?
Hvem må gennemføre hvilke processer?
Overholder vi GDPR?
Hvilke compliance krav skal vi overholde? F.eks. bogføringsloven, regler i forhold til told og skat, NIS2 osv. Og så er der selvfølgelig alle de domænespecifikke compliance-krav som f.eks. i forhold til Finanstilsynet, hvis man er i finanssektoren, eller GAMP5, hvis man er i pharma.

Også denne del kan være temmelig omfattende at få styr på i løbet af projektet, afhængigt af hvilket domæne man arbejder i.

Så der er en række udfordringer, der kræver, at vi, inden vi går i gang med implementeringen, har styr på:

overblik over hvilke processer, systemet skal supportere
en strategi for datamigrering
en plan for at sikre datakvalitet
klare ejerskaber og governance
test af integrationer, datavalidering og processer.

Terminologi

Vær også opmærksom på, at nogle termer bruges anderledes, end vi er vant til. I SAP bruges termen unit test f.eks. ofte om en funktionel test af en konfigureret løsning eller forretningsproces, typisk udført af konsulenter for at sikre, at f.eks. en indkøbsordre eller en bogføringsfunktion virker som forventet. Det adskiller sig fra ISTQB’s definition, hvor unit test er en lavniveau test af isoleret kode skrevet af udviklere for at verificere korrektheden af individuelle funktioner eller metoder.

Hvordan tester man så et standardsystem?

Når man skal teste standardsystemer (f.eks. ERP, CRM eller HR-systemer), adskiller teststrategien sig fra en traditionel softwareteststrategi, da standardsystemer sjældent udvikles fra bunden men i stedet konfigureres, integreres og migreres. Det betyder, at vores fokus ikke ligger på de mere udviklernære testniveauer som unittest og unitintegrationstest men ofte har fokus på:

konfigurationstest: Sikrer, at systemet er opsat korrekt i forhold til de krav og behov, vi har identificeret sammen med vores brugere
integrationstest: Sikrer, at systemet fungerer sammen med det eksisterende IT-landskab
datamigreringstest: Hvis organisationen har data fra andre systemer, der skal migrereres, skal vi sikre at gamle data overføres korrekt til det nye system
forretningsproces-test: Det er helt essentielt, at vi gennemfører test af de identificerede forretningsprocesser for at bekræfte, at arbejdsgangene fungerer som forventet
accepttest (UAT): Brugerne bekræfter, at systemet understøtter deres daglige opgaver. Accepttesten kan være en ”paraply”, der reelt samler op på resultatet af de andre testaktiviteter og evt. supplerer med noget scenariebaseret test med end-to-end fokus for at sikre, at daglige opgaver kan løses.

Principper for test af standardsystemer

Der er nogle vigtige principper for test af standardsystemer, som bør tages med i planlægningen af projektet:

Risikobaseret test: Fokus på de mest kritiske områder (f.eks. finansielle processer i et ERP). Ofte kan der f.eks. være rigtigt mange forretningsprocesser (jeg har set eksempler på 150-200 forskellige), og her er det vigtigt at kunne prioritere testaktiviteterne, så de vigtigste processer er dem, der får den mest grundige test.
Tidlig test af konfiguration og integration: Undgå at vente med test til slutningen af projektet. Generelt er princippet om shift-left også vældigt relevant her. Der er ingen grund til at vente med test af f.eks. feltkonfigurationer til UAT eller procesorienteret test; lav tidlig test af de enkelte konfigurationer, og gerne noget der er automatiseres, så det bliver en integreret del af regressionstesten. Det er et nærmeste, vi kommer ”unit test” i klassisk forstand, da vi jo ikke tester kodekomponenter som sådan men konfigurationer.
Automatisering hvor det giver mening: F.eks. regressionstest af workflows eller API‘er. ERP-systemet skal give værdi i mange år fremover, og mange organisationer vil opleve, at de løbende har behov for forbedringer og tilpasninger. For ikke at forglemme de forholdsvis store releases, der kommer fra leverandøren (SAP eller Microsoft afhængigt af platform) med utallige rettelser. Her har jeg set releasenotes med flere tusinde rettelser til en af de store releases – så her bliver regressionstest essentiel, og den skal ikke være manuel, da organisationen som oftest så vil være tvunget til at trække på forretningen i stort omfang, hver gang der kommer en ny release.
Brugerinvolvering i accepttest – Forretningsbrugerne skal godkende, at systemet virker som forventet. Hvis vi skal være sikre på, at vi ikke kun har bygget det rigtigt men også har bygget det rigtige – at det virker i brugernes hverdag – så skal brugerne involveres i testen af løsningen. Som minimum i accepttesten.

Tips til test

Rent praktisk er der en række ting, der er værd at have in mente, når vi planlægger testen. Dette for at sikre, at vi får skabt det rigtige setup for testen og får styr på det rette omfang af testen – ikke for meget, ikke for lidt – men lige tilpas.

Så brug denne tjekliste som inspiration, når I skal i gang med at planlægge testen;

Fokus på de mest kritiske forretningsprocesser. Brug workshops med forretningen til at identificere de kritiske områder.
Brug testteknikker!! Også ved standardsystemer. F.eks. er procescyklustest helt fantastisk til at skabe det mest effektive sæt af test cases med procesfokus.
Automatiser gentagne tests så som workflows og tests af API’er.
Manuel test er vigtig, hvor brugeroplevelsen er i fokus. Altså test af konfigurationer og accepttest.
Hvis eksterne systemer ikke er klar, så brug mocks og testdata til at simulere integrationerne – men husk at teste dem rigtigt også!
Hvis mange brugere skal bruge systemet samtidig, så overvej, om det er relevant at gennemføre performance test for specifikke områder.
Hvordan får vi et testmiljø, der afspejler produktionen? Er det nødvendigt?
Hvordan håndterer vi versioner og opdateringer af standardsystemer?
Hvordan får vi testdata? Kan vi bruge anonymiseret produktionsdata, eller skal det genereres?

Test bør ske løbende gennem projektet. En prioriteret rækkefølge kan være som vist nedenfor, dog med den tilføjelse, at regressionstesten bør udvikles så tidligt som muligt, så den kan køres løbende gennem projektet; især hvis man arbejder inkrementelt, hvor områder færdiggøres løbende og samles til en samlet idriftsættelse:

Tidlig test af konfigurationer (konfigurationsvalidering)
Integrationstest (sikre system-til-system kommunikation)
Datamigreringstest (test af dataoverførsel fra gamle systemer)
End-to-end test (validering af forretningsprocesser)
Brugeraccepttest (UAT) (slutbrugerne godkender systemet)
Regressionstest og stabilitetstest før go-live

Men vi skal selvfølgelig kigge på jeres egen kontekst og finde det setup, der passer. Det kan være, at der er behov for en separat test, der fokuserer på compliance i forhold til, hvad I nu end har af regulativer, som I skal overholde for at sikre, at I får den korrekte og tilstrækkelige dokumentation til at bevise compliance. For i den type test handler det jo i lige så høj grad om den rapport/dokumentation, I kan levere efterfølgende som bevis for compliance – så det er nødt til at være i fokus ved planlægningen af testen.

Det kan også være, at der stort set ikke sker tilpasning af processerne, da vi udelukkende bruger standardprocesserne. Så kan der skæres ned på den detaljerede test af processer og fokuseres på en overordnet end-to-end test som en del af brugeraccepttesten.

Konklusion

Selvom standardsystemer kommer som færdige løsninger, betyder det ikke, at de kan implementeres uden grundig test. Konfigurationer, integrationer og datamigreringer introducerer risici, der kan påvirke både systemets funktionalitet og forretningens daglige drift.

En veltilrettelagt teststrategi sikrer, at systemet fungerer i praksis og understøtter forretningens behov. Fokus bør være på tidlig test af konfigurationer, grundig validering af integrationer, kvalitetssikring af data og risikobaseret prioritering af kritiske forretningsprocesser.

Test er ikke en unødvendig omkostning. Det er en investering i en succesfuld implementering.

The post Derfor er standardsystemer ikke plug-and-play appeared first on Key2Quality.

Hvad gør vi, når vi har bygget systemet men ikke fik kvaliteten med?

Trine Zachariassen — Tue, 08 Apr 2025 07:45:11 +0000

Kender du det? Systemet er bygget, det kan i grove træk det, det skal kunne, men undervejs glippede det med kvaliteten og der er alt for mange (kritiske) fejl.

Det kan der være flere årsager til, f.eks.:

Tidspres
Manglende teststrategi
Dårligt kravgrundlag
Ufuldstændig dokumentation
Dårlig eller ingen sporbarhed, der fører til mangelfuld testdækning
En af de agile faldgruber; fokus er udelukkende på den enkelte user story og aldrig på produktet i sin helhed.

Særligt sidstnævnte kan være resultatet af, at vi laver et komplekst produkt med leverancer fra flere teams, der hver især har ansvar for deres eget delområde.

Når vi går på kompromis med kvaliteten, begrænser vi potentielt den værdi, produktet egentlig skulle give. Vi risikerer at ende med et produkt, der er besværligt at bruge og i stedet skaber irritation – det kan overskygge det, der i princippet fungerer.

Dårlig kvalitet er uholdbart – særligt når der fortsat skal udvikles og vedligeholdes på systemet.

Vedligeholdbarhed

Når vi går på kompromis med kvaliteten, medfører det typisk teknisk gæld, fordi midlertidige eller forhastede løsninger hober sig op. Det kan have konsekvenser for, hvor let systemet er at vedligeholde efterfølgende, blandt andet fordi det bliver svært at undgå fejl, når der tilføjes ny funktionalitet – særligt hvis der ikke findes tests til at fange de fejl, der måske introduceres.

Manglende eller dårlig dokumentation kan også påvirke vedligeholdbarheden af systemet og kan være resultatet af, at viden primært ligger hos nøglepersoner. Det gør det vanskeligt for nyansatte at danne sig et overblik over det produkt, de arbejder på, hvilket yderligere gør det vanskeligt at skulle foretage ændringer eller fejlrettelser, hvis de ikke i tilstrækkelig grad forstår omfanget af ændringen.

Sporbarhed

En af vores fornemste opgaver som testfaglige er at kunne give information om kvaliteten af et produkt. Jo bedre sporbarhed vi har at arbejde med, jo mere detaljeret og konkret kan den information blive. Derudover giver det os et overblik over vores testdækning og ikke mindst kan vi mere effektivt vurdere, hvad der potentielt kan være påvirket efter en ændring, når vi ved præcist, hvad det er, vi tester og hvordan det hænger sammen med andre funktioner/komponenter.

Tunnelsyn

Når vi arbejder i agile teams, risikerer vi at arbejde i siloer, hvor fokus primært er på de enkelte user stories fremfor på den feature, de tilsammen udgør – og produktet som helhed. Vi ender vi med et fragmenteret produkt med inkonsistente brugeroplevelser, hvis hvert team blot fokuserer på, at deres del fungerer, og ikke forholder sig til, hvordan den del skal indgå i systemet eller hvilke afhængigheder, der måtte være på tværs af teams.

Hvad kan vi gøre ved det?

Helt grundlæggende skal der forankres et supplerende fokus på produktet. Det kan virke som en forholdsvis uoverskuelig opgave, men hvordan er det nu, man spiser en elefant?

Produktperspektivet skal indføres på flere forskellige parametre – én bid ad gangen.

Der bør etableres et testteam på produktniveau. Er dette ikke en mulighed, kan et alternativ være at placere ansvaret for test på produktniveau hos en repræsentant fra hvert team.

Derudover skal den, der har produktansvaret – enten forretnings- eller IT-mæssigt – have ansvaret for at skabe et overblik over (og ikke mindst dokumentere) alle produktets funktioner samt hvilke processer/arbejdsgange, det understøtter – gerne med support fra test.

Herefter kan vi:

mappe funktionerne til systemets komponenter
lave en produktrisikoanalyse (PRA) på funktionsområderne
etablere regressionstest på produktet i prioriteret rækkefølge efter risikoklasse.

Når vi har et dokumenteret overblik over alle funktionsområder, skal de mappes til systemets komponenter – det vil være en opgave for arkitekter/lead developers.

Denne dokumenterede sammenhæng vil ikke mindst give værdi til (nye) udviklere, der nemmere kan få overblik over produktet og dermed nemmere forstå den kontekst det, de arbejder med, skal indgå i.

Næste skridt bør være at lave en PRA på funktionsområderne. Det vil give værdi til alle, der er involveret i udviklingen, da det vil synliggøre hvilke dele af produktet, der er kritiske. For testteamet vil det særligt give værdi i forbindelse med etablering af regressionstest på funktionsområderne med dertilhørende processer/arbejdsgange og senere i forbindelse med udvælgelse af, hvilke tests der skal afvikles når en ny feature og/eller release introduceres.

PRA’en vil derudover give input til, i hvor høj grad de forskellige funktionsområder skal dækkes med test, dermed være input til, hvilke testdesignteknikker der skal benyttes i testanalysen.

Hvordan skal vi arbejde fremadrettet?

Når vi har dokumenteret produktets funktioner, dokumenteret sammenhængen mellem dem og komponenter, lavet en PRA på dem og påbegyndt etablering af regressionstest på produktet, skal vi til at kigge fremad.

Vi skal begynde at:

arbejde aktivt med sporbarhed mellem feature, user story, komponent og funktionsområde.
arbejde aktivt med sporbarhed fra krav/feature til test til testresultat til bug.
bruge testdesignteknikker tidligt.

Sporbarheden til komponenter og funktionsområder kan helt lavpraktisk implementeres som tags eller felter i opgavestyringssystemet. På den måde vil vi på enhver feature eller user story kunne se, hvilke(t) funktionsområde(r) der måtte blive påvirket af den – og planlægge vores test ud fra det.

Sporbarheden skal implementeres på alt nyt, så vi ved, hvilket krav eller hvilken feature der bliver påvirket, når vi finder en bug. Så vi ved, om vi har dækket det, vi skal.

For at vi fremadrettet og på en struktureret måde kan illustrere, hvad en feature eller et krav egentlig indeholder, skal vi begynde at bruge testdesignteknikker, inden vi begynder at udvikle. Indeholder kravet/featuren processer, vil det for eksempel være oplagt at bruge teknikken procescyklustest, når det drejer sig om arbejdsgange, eller tilstandsovergangstest, hvis det omhandler en tilstandsmaskine. Handler det om forretningsregler, vil det være en fordel at lave en beslutningstabel. Tidlig brug af testdesignteknikker vil fange fejl tidligt og bidrage til at tydeliggøre, hvad der skal bygges.

Teknikkerne giver input til test på flere niveauer – også produktniveau. Vi skal huske at jo højere niveau vi tester på, desto mere bør testen afspejle det reelle brug af systemet. Vi skal ikke genbruge de testcases, der blev udviklet for den enkelte user story – medmindre den har fokus på systemet som helhed.

Sidst men ikke mindst – drop de dårlige vaner – hellere sent end aldrig

Stop starting, start finishing – husk at prioritere fejlrettelser undervejs – hvis de konstant parkeres til fordel for nyudvikling, ophober den tekniske gæld sig, og det går ud over den grundlæggende kvalitet af systemet. Vi kan ikke forvente at skabe værdi med nye features hvis de skal eksistere i et system, der grundlæggende er af dårlig kvalitet.

Skal vi hjælpe?

Vil du høre mere om, hvordan vi kan hjælpe med at bygge kvalitet ind i jeres system fra starten af? Så kontakt chefrådgiver og områdeleder for kompetencer og viden, Gitte Ottosen, på gitte@key2quality.dk eller 4940 8552.

The post Hvad gør vi, når vi har bygget systemet men ikke fik kvaliteten med? appeared first on Key2Quality.

Er testmanagement-rollen død?

Trine Zachariassen — Wed, 19 Feb 2025 15:46:38 +0000

“Er testmanagement-rollen død?”

Er den klassiske testmanager overflødig, nu hvor det er det tværfunktionelle team, der har ansvaret for kvaliteten?

Det spørgsmål er jeg blevet stillet en del gange i de sidste mange år – ja, faktisk lige siden vi begyndte at arbejde indenfor rammerne af agile.

Det korte svar må være ja.

Det lidt længere svar får du herunder.

Det enkelte agile team

Hvis vi ser det helt isoleret på det enkelte agile team, kan der godt være noget om snakken.

Der er ingen grund, til at have en testmanager tilknyttet, hvis du har et modent team, der:

er godt klædt på til at forstå, hvordan de kan tage det fulde ansvar for kvaliteten af deres løsning
har styr på den statiske test, uanset om vi taler dokument review, kodereview eller statisk analyse
har fokus på kvalitetsrisici, så testen har den rette fokus
har et solidt fundament af unit- og unit integrationstest
har en velfungerende CI/CD-pipeline, hvor deres automatiske test kører
har fokus på, at der er tests, der ligger udover unit- og unitintegrations test
har transparens på deres kvalitet. De ved hvad kvaliteten er på deres løsning – og ikke mindst hvor det gør ondt

Hvis ikke dit team har så godt styr på det, har de brug for hjælp til at modnes; enten i form af en testmanager eller en quality coach, der kan være med til at løfte kompetenceniveauet og fokussen i teamet.

Du kan læse mere om forskellen på rollerne i artiklen Testmanager, orchestrator, quality coach – kært barn har mange navne – Key2Quality.

Når agile skalerer

Men hvad nu hvis vi har en flok agile teams, der arbejder på en større kompleks løsning, hvor de:

har afhængigheder på tværs af teams
har komplekse forretningsgange, der skal understøttes
har en del integrationer, der skal virke, før forretningsgangene kan gennemføres
har leverancer fra 3. part, der skal med i den samlede løsning
har en formel afleveringsforretning (brugeraccepttest) i forløbet.

Her er der brug for en profil, der:

driver det testfokuserede arbejde
sætter strategien og hjælper teams med at implementere den
sikrer, at der bliver testet på løsningen som en helhed og ikke kun på de enkelte dele
driver fokus på at få testet tidligt og tænke testautomatisering ind fra starten af, så denne ikke er noget, vi gør i retrospekt.
– Selvom det er et stykke tid siden, at begreber som ”shift-left” og ”built-in quality” blev lanceret, er de stadig fuldt ud lige så vigtige som før. Det er essentielt, at vi hele tiden har fokus på at teste vores løsninger så tidligt som muligt, og samtidig har fokus på, at der skal testes med forskellige perspektiver. Her er jeg stadig vældig glad for de agile testkvadranter som et fundament for diskussionen om, hvordan vi skal teste – netop for at sikre, at vi har fokus på de forskellige perspektiver.

Når du er kunde

Hvis du sidder på den anden side af bordet i forhold til det tidligere beskrevne – altså på modtagersiden som kunde – så er fokus på test og kvalitet ikke mindre vigtigt.

Som kunde bør du spørge dig selv:

Hvordan sikrer vi, at den leverance vi modtager er blevet tilstrækkeligt kvalitetssikret af vores leverandør?
Hvordan får vi drevet, at vi får lavet en accepttest, så vi kan validere, at vi rent faktisk har fået den løsning, som vi bad om?

Det er essentielt, at vi, allerede når vi laver et evt. udbud og en aftale med en leverandør, er HELT skarpe på, hvordan de skal kvalitetssikre, hvordan vi skal samarbejde i forhold til test og kvalitetssikring, hvordan der skal kommunikeres om kvalitet, og hvordan der skal laves en egentlig afleveringsforretning.

Alt for ofte ser vi desværre, at kontrakter i denne kontekst ikke har meget fastlagt omkring dette, og det gør, at vi efterfølgende ikke har nogen håndtag til at sikre, at vi rent faktisk får leverancer i en tilfredsstillende kvalitet. Så at tilknytte en testmanager til projektet, allerede når vi går i gang med at definere udbuddet og så ellers hele vejen gennem projektets levetid, er bestemt ikke uvæsentligt.

Nu tænker du måske; ”Jamen, vi vil være agile, og så laver vi ikke de der vandfaldsprojekter med store accepttests sammen med vores leverandør.”

Uanset hvilken udviklingsmodel/leverancemodel, I vælger at arbejde indenfor, er det vigtigt, at I allerede fra starten af har fokus på at få lavet et samarbejde, der har fokus på kvaliteten – også selvom I vil arbejde agilt.

Aftalen skal sætte rammerne for:

review af featurebeskrivelser
deltagelse i demoer
jeres bidrag som sparringspartner i sprintet
jeres involvering i testen af user stories og features
hvor tit I vil have leverancer
hvorvidt I skal have en accepttest i den forbindelse.

Ofte er der grænser for, hvad leverandøren reelt kan teste i deres eget miljø. De har ikke det fulde setup men måske kun en begrænset konfiguration i forhold til jeres; de har ikke adgang til større mængder testdata, og måske vigtigst af alt: de har som oftest ikke adgang til jeres integrationer. Leverandøren kan selvfølgelig lave stubbe og simulatorer, og de kan stille krav om interfacebeskrivelser mv. Men det kan aldrig erstatte en reel systemintegrationstest. Den ender derfor ofte med at være kundens ansvar, da kun de har testmiljøet til at kunne.

Alt det andet

Hertil kommer de punkter, som går på tværs af alle udviklingsmodeller og kontekster, og som ofte bliver enten nedprioriteret eller glemt i farten:

test i forhold til regulering og compliance. I mange brancher er der krav til testdokumentation, sporbarhed og validering
håndtering af ikke-funktionelle krav, såsom ydeevne, sikkerhed, tilgængelighed, skalerbarhed. Hvem har ansvaret for at disse aspekter bliver testet?
testdata og miljøer: Hvem sikrer, at der er adgang til de rette testdata, og at miljøerne understøtter de nødvendige tests?

Disse er komplekse opgaver, der som oftest går på tværs af de enkelte team, og som kræver at man er oppe i helikopteren og ser på løsningen som en helhed.

Så det lange svar på spørgsmålet om, hvorvidt testmanagement-rollen er død, må være nej – testmanageren er stadig nødvendig. Rollen skal bare hele tiden tilpasses den kontekst, vi befinder os i.

…

Vil du vide mere?

Har du brug for hjælp til testmanagement, så lad os hjælpe med at finde den helt rigtige testmanager. Kontakt områdeleder for IT-kvalitetssikring og senior konsulent, Jonas Sloth, på 4940 2794 eller jonas@key2quality.dk for at høre mere.

Er du allerede erfaren testmanager, og vil du dygtiggøre dig endnu mere – så tilmeld dig vores kursus i ISTQB Advanced Test Management V3.0.

The post Er testmanagement-rollen død? appeared first on Key2Quality.

Når brugerne tester: Derfor er grundlæggende testforståelse afgørende

Trine Zachariassen — Thu, 23 Jan 2025 06:18:19 +0000

I mange IT-projekter er slutbrugerne dybt involverede i, at løsningen fungerer i praksis. Ofte er det dem, der sidder med kendskabet til processer, kunder og krav. Og ofte er forretningen de eneste, der tester, når vi ser bort fra de mere tekniske testaktiviteter.

Men hvordan sikrer vi, at forretningen også kan navigere i den tekniske og strukturerede verden af softwaretest?
Hvordan sikrer vi, at den viden, forretningen har, bliver brugt struktureret i testen?
Hvordan sikrer vi, at vi får lavet den mest effektive test?

Når forretningen træder ind i testrollen, er en grundlæggende testforståelse ikke bare en fordel. Den er en nødvendighed.

Her handler det om at bygge bro mellem viden om, hvordan løsningen skal fungere, og evnen til at omsætte det til systematiske testaktiviteter.

Men hvad indebærer en grundlæggende forståelse af test egentlig?

Lad os kigge på de vigtigste begreber.

Testanalyse og testdesignteknikker skaber overblik over kravene

Først skal testanalysen være på plads.

Ved at forstå krav gennem teknikker som ækvivalensklasser, grænseværdianalyse eller beslutningstabeller kan testeren identificere de væsentligste scenarier – og gøre det tidligt.

Faktisk er testteknikkerne utroligt effektive at bruge i starten, hvor vi definerer krav og features.

Testteknikkerne kan tydeliggøre kravene uden behov for tunge dokumenter.
Kravene bliver lige til at tage og bruge som udgangspunkt for test på alle niveauer.

På den måde bliver testteknikkerne en effektiv måde at synliggøre krav, strukturere dem og overdrage dem til teamet.

Testdesign sikrer passende test

Testdesign og testimplementering bygger videre på dette fundament.

Når testopgaverne nedbrydes, og testcases specificeres med sporbarhed mod kravene, bliver testarbejdet både mere fokuseret og effektivt. Det handler ikke kun om at finde fejl men også om at sikre, at vi får testet i passende omfang – hverken for meget eller for lidt – og at vi får prioriteret indsatsen rigtigt.

Brug et testværktøj – og forstå hvorfor

Derudover kræver de komplekse systemlandskaber, vi arbejder med i dag, en forståelse for, hvordan værktøjer som teststyring og fejlhåndtering kan understøtte processen. Det er en fordel, hvis vi ikke kun nøjes med at introducere, hvad testerne skal gøre med værktøjerne, men også får forklaret:

Hvorfor bruger vi værktøjer som teststyring og fejlhåndtering?
Hvilken værdi vi får ud af at flytte testdokumentationen fra Word, Excel, Confluence og notesbøger til et dedikeret værktøj?

Alle skal klædes ordentligt på

Vores erfaring viser, at jo bedre alle er klædt på med en grundlæggende forståelse af test, jo bedre bliver samarbejdet, og jo bedre bliver resultatet:

Forretningens testere bliver bedre rustet til at tage ejerskab over opgaven efterfølgende. Testerne kan udfordre IT, prioritere de rigtige områder og sikre, at løsningen ikke bare fungerer – men også lever op til forretningens behov.
Forretningens daglige sparringspartnere om produktet, forretningsanalytikere og produktejere kan nemmere strukturere hele grundlaget for testen, dvs. krav og acceptkriterier.
Med et fælles sprog omkring test og kvalitetssikring har hele teamet – inklusive udviklere, scrum masters og projektledere – det samme udgangspunkt for diskussionen om, hvordan I skal gribe det an i jeres kontekst.

Vil du vide mere om grundlæggende test? Vil du lære, hvordan brugen af struktureret test proaktivt kan være med til at skabe et bedre grundlag for udviklingen af jeres løsninger? Så tilmeld dig og dine medarbejdere vores kursus i Grundlæggende Test.

Læs mere om struktureret test i vores andre artikler:

Hvorfor strukturere testdesign?

Sådan sikrer du passende test med testdesignteknikker

Sådan kan test understøtte det første agile princip

Tilmelding til seminar

Tilmeld dig via formularen herunder.

Når du har tilmeldt dig, modtager du automatisk en bekræftelse pr. mail.

The post Når brugerne tester: Derfor er grundlæggende testforståelse afgørende appeared first on Key2Quality.

Er QA og testfaglige nutidens Aristoteles?

Trine Zachariassen — Mon, 16 Sep 2024 07:37:49 +0000

I en verden i konstant forandring, hvor teknologi og innovation hele tiden sætter nye standarder, spiller vi som QA (Quality Assurance) og testfaglige en vigtig rolle i at sikre, at vi lever op til disse standarder.

Kvalitet, som et begreb, har rødder i antikkens filosofi, men hvad betyder det egentlig i dag, og hvem har den bedste forståelse af, hvad kvalitet virkelig er?

Kvalitetens historiske rødder

Begrebet “kvalitet” kommer fra det latinske ord “qualitas”, som blev brugt af filosoffer som Aristoteles til at beskrive egenskaberne ved objekter. Aristoteles så kvalitet som en iboende egenskab, der definerede et objekts form og funktion. Denne grundlæggende idé har overlevet gennem århundreder og spiller stadig en central rolle i, hvordan vi i dag vurderer produkter og tjenester.

Fra filosofi til praktik

Historisk set blev kvalitet betragtet som noget, der udsprang af håndværk og opmærksomhed på detaljer. Med den industrielle revolution blev standardisering afgørende for at sikre pålidelighed i masseproduktion, og senere blev kvalitetsstyring central i både produktion og serviceindustrien. Men selvom processerne har ændret sig, forbliver kernen den samme: Kvalitet er stadig afgørende.

Som QA og testfaglige står vi midt i denne udvikling. Vores arbejde er at sikre, at de produkter og tjenester, der udvikles, lever op til de fastsatte standarder – og nogle gange overstiger dem. Dette kræver en dyb forståelse af både de tekniske aspekter og de subtile detaljer, der kan gøre forskellen mellem et godt og et fremragende produkt.

Aristoteles og QA: Er der en sammenhæng?

Aristoteles mente, at alt har et “telos” – et endeligt mål eller formål. På samme måde arbejder vi som QA og testfaglige med at sikre, at et produkt opfylder sit formål. Det handler ikke kun om at sikre, at noget fungerer, men at det fungerer på en måde, der skaber værdi for brugeren. Dette kræver en grundig test og analyse, hvor alle aspekter af produktet bliver undersøgt.

Kvalitet og værdi

Kvalitet er ikke kun en teknisk vurdering. Det er også en vurdering af, hvordan et produkt eller en tjeneste opfattes af brugeren, og hvilken værdi det leverer. Philip B. Crosby definerede kvalitet som “conformance to requirements”, mens Joseph M. Juran talte om “fitness for use”. Begge definitioner understreger, at kvalitet handler om at opfylde både eksplicitte krav og implicitte forventninger.

Som QA og testfaglige er vi dem, der kan afkode disse krav og sikre, at produktet eller tjenesten ikke kun lever op til dem, men også overgår dem. Vores arbejde er afgørende for at sikre, at brugerne får det, de forventer – og lidt til.

En refleksion over QA’s rolle

Som QA og testfaglige spiller vi en central rolle i at sikre kvaliteten af de produkter og tjenester, vi bruger hver dag. Vi arbejder ofte i baggrunden, men vores arbejde er afgørende for, at brugerne kan have tillid til det, de køber og bruger. Vores opgave er ikke kun at finde fejl, men også at sikre, at alt lever op til den højeste standard – at alt når sit “telos”.

Er vi så nutidens Aristoteles? Det må være op til andre at vurdere. Men én ting er sikkert: Vores arbejde er uundværligt, og vi sikrer, at kvalitet forbliver en hjørnesten i vores moderne samfund.

The post Er QA og testfaglige nutidens Aristoteles? appeared first on Key2Quality.

Sådan vælger du det rette test management-værktøj

styrmand — Wed, 02 Aug 2023 13:29:29 +0000

Vælg det rigtige test management-værktøj

Valget af test management-værktøj er afgørende for, om du kan bevare overblikket over testen og tilstanden på systemets kvalitet. Med det rette test management-værktøj får du hjælp til at organisere testprocessen, sikre sporbarhed til krav, generere rapporter og meget mere.

Men der er mange muligheder på markedet. Blandt de mest populære kan nævnes Zephyr, Xray, Testrail, Azure Test Plans og PractiTest; men det er på ingen måde en udtømmende liste. Med så mange muligheder på markedet kan det være en udfordring at finde det værktøj, der bedst passer til jeres specifikke behov.

I denne artikel bliver du skridt for skridt guidet gennem processen med at vælge det rigtige test management-værktøj.

1. Undersøg og afdæk jeres behov

Det første skridt i at vælge det rette test management-værktøj er at identificere de behov, I har i jeres team eller organisation.

Da vi på vores seneste seminar omkring test management-værktøjer 14. juni 2023 spurgte deltagerne om, hvilke egenskaber der var vigtigst for dem i et test management-værktøj, var det tydeligt, at det var meget forskelligt, hvad der var vigtigt. Dette stemmer helt overens med det faktum, at behovet afhænger af konteksten.

Så hvilke egenskaber, der er vigtigst for jer, vil afhænge af den kontekst, I befinder jer i, og de behov, I har. Start derfor med at kortlægge den kontekst, værktøjet skal bruges i, og hvem der skal anvende det.

Det kan du gøre ved at stille dig selv og dine kolleger følgende spørgsmål:

Er dit team lille og selvstændigt, eller indgår I i et større program med flere release trains, hvor værktøjet skal skabe overblik på tværs?
Hvem er brugerne af værktøjet?
- Er det testmanagere, testere, udviklere, forretningen, releasemanagere, product owners, operations eller andre?
- Hvordan kan de forskellige roller involveres i processen, så I kan undersøge, hvilke behov de forskellige roller har?
- Skal forretningen kunne deltage i testen? I så fald kan det være vigtigt med brugervenlighed.
Har I behov for at kunne håndtere krav i samme system og have sporbarhed mellem krav, defekter og testcases?
Har I behov for at integrere test management-værktøjet med andre værktøjer eller systemer, såsom automatiserede testværktøjer eller tredjepartsapplikationer?
Hvor mange brugere har I behov for? Og hvad er jeres budget? Priser og prismodeller varierer meget mellem værktøjerne.
Hvilket værktøj bruger I i dag? Hvad fungerer godt? Og hvad savner I?

Dette er blot et bud på nogle af de spørgsmål, der kan hjælpe med at afdække, hvad jeres præcise behov er. Det er ikke en udtømmende liste; I kan sikkert komme i tanker om mange flere spørgsmål, der kan bidrage til at afdække jeres behov.

2. Identificer de vigtigste egenskaber/kriterier

Når I har fået kortlagt jeres behov, er næste skridt at identificere de specifikke funktioner og egenskaber, som test management-værktøjet skal have for at imødekomme jeres behov.

Nogle eksempler på egenskaber, som I bør overveje, er følgende:

Rapportering: Hvilken type rapporter og dashboards er afgørende for jer? Ønsker I at kunne generere omfattende testrapporter, følge testdækning eller visualisere testresultater på en bestemt måde? Definer de rapporteringsbehov, der er vigtige for dit team og dine interessenter, og tænk over, hvorvidt I har brug for tilpassede rapporteringsmuligheder eller indbyggede rapportskabeloner.

Release management: Hvis du har behov for at administrere testaktiviteter i forbindelse med releases, bør værktøjet kunne understøtte release management. Skal det kunne hjælpe med at planlægge og organisere testaktiviteter i forhold til forskellige udgivelser og versionsnumre?

Defect management: I hvor høj grad har I behov for, at værktøjet tilbyder en integreret defect management-funktionalitet? Hvis defekthåndtering er vigtigt for dig, så overvej, hvilke funktioner der er nødvendige for at kunne spore defekter, tildele dem til teammedlemmer, definere prioriteringer og overvåge defekternes livscyklus.

Testplanlægning og -organisering: Har du behov for at kunne oprette og administrere testplaner, definere testomfang, tildele opgaver og følge teststatus? Overvej, hvilke funktioner der er vigtige for at organisere og planlægge dine testaktiviteter.

Integrationsmuligheder: Har I behov for at integrere test management-værktøjet med eksisterende systemer, som for eksempel fejlsporingssystemer, CI/CD-værktøjer eller automatiserede testrammer? Identificer de specifikke integrationer, der er nødvendige for jeres projekt.

Kravshåndtering og sporbarhed: Har I behov for, at værktøjet også fungerer som kravstyringsværktøj? Skal værktøjet kunne håndtere versionering af krav? Har I brug for fuld sporbarhed mellem krav, testcases, defekter og måske endda koden?

Skalerbarhed og fleksibilitet: Hvis du forventer, at dit projekt eller din organisation vil vokse over tid, skal du tænke på værktøjets skalerbarhed og fleksibilitet. Kan det håndtere et øget antal brugere, større datamængder og kompleksitet, hvis det skulle blive nødvendigt?

Konfigurerbarhed og tilpasning: Hvor vigtigt er det for dig at kunne tilpasse værktøjet til dine arbejdsprocesser og terminologi? Ønsker du mulighed for at tilføje brugerdefinerede felter og tilpasse workflows? Vurder graden af fleksibilitet og konfigurerbarhed, der er nødvendig for din organisation.

Ovenstående liste er ikke udtømmende, men blot eksempler på nogle af de mest almindelige egenskaber, som I bør forholde jer til.

Det kan være svært at få alle ønsker opfyldt, så før I kigger på konkrete værktøjer, bør I forholde jer til, hvad der er ufravigelige krav, og hvad der blot er ”nice to have”.

3. Undersøg relevante værktøjer

Når du har afdækket jeres behov og identificeret, hvilke egenskaber der er vigtigst, kan du begynde at identificere de test management-værktøjer, der bedst opfylder jeres kriterier.

Der findes mange forskellige værktøjer på markedet, så det kan være en god idé at starte med at indsnævre feltet ved at fokusere på de værktøjer, der opfylder jeres ufravigelige krav.

Lav en prioriteret liste af de værktøjer, der umiddelbart er interessante, og gennemgå dem så fra toppen af, for at afdække om de enkelte værktøjer opfylder jeres ufravigelige krav.

Når du har indsnævret listen til højst en håndfuld værktøjer, er du klar til næste trin.

4. Anvend Structured decision making

Nu hvor du har en liste over potentielle værktøjer, kan du anvende metoden Structured decision making for at afgøre, hvilket værktøj der bedst passer til jeres behov.

Der findes mange skabeloner til Structured decision making på nettet, så start med at finde en god skabelon.

Metoden går kort fortalt ud på, at man vægter de forskellige egenskaber og kriterier baseret på deres vigtighed. Dernæst scorer man hvert værktøj i forhold til disse egenskaber. Det værktøj, der opnår den højeste samlede score, vil være det bedst egnede til jeres behov.

5. Prøv værktøjet af

Før I træffer en endelig beslutning og investerer i et test management-værktøj, er det en god idé at prøve det af i praksis. Lav et Proof of Concept (POC), og sørg for at gøre det så realistisk som muligt. Involver forskellige roller, så værktøjet bliver afprøvet fra forskellige vinkler og med forskellige fokuspunkter. Hvis det er muligt, kan du også lade et enkelt team prøve værktøjet af, for at få en bedre fornemmelse af hvordan det fungerer i praksis.

6. Lav en udrulningsplan

Dette blogindlæg vil ikke gå i dybden med, hvordan I udruller det nye værktøj i jeres organisationen. Det er et større emne i sig selv, så vær opmærksom på at det kan være en meget stor opgave.

Sørg for at overveje følgende punkter i din udrulningsplan:

Kommunikationsplan og stakeholder management
Planlægning og tidsplan
Konfiguration og tilpasning af værktøjet
Træning og opkvalificering af brugerne
Dataoverførsel og import af eksisterende testdata
Gradvis udrulning eller pilotprojekt
Supportstruktur og opfølgning efter udrulning

7. Bed om hjælp, hvis det virker uoverskueligt

Valget af det rette test management-værktøj er afgørende for at opnå effektiv teststyring og overblik over kvaliteten i dit softwareprojekt. Ved at undersøge og afdække jeres behov, undersøge relevante værktøjer, anvende Structured decision making og afprøve værktøjet i praksis kan I vælge det værktøj, der bedst understøtter jeres testprocesser og bidrager til succesen af jeres projekt.

Har du spørgsmål eller kommentarer til artiklen, er du velkommen til at kontakte vores senior testkonsulent Daisy Fischlein Steffensen på daisy@key2quality.dk.

Virker det uoverskueligt, og har I brug for hjælp til at finde frem til det test management-værktøj, der passer ind i jeres virksomhed? Så lad os hjælpe jer med afklaringen og med at blive fortrolige med det nye værktøj. Kontakt os på telefon 4940 8060 eller kontakt@key2quality.dk.

The post Sådan vælger du det rette test management-værktøj appeared first on Key2Quality.