Tilmelding til webinar

Tilmeld dig via formularen herunder.

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

Navn

Indtast din e-mail

Titel

Firma

Vælg dato for webinar

11. juni 2025

Evt. besked

Send

The post Quality coach – når kvalitet bliver en fælles styrke i teamet appeared first on Key2Quality.

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

The post Sådan lykkes I med test i skaleret agil udvikling appeared first on Key2Quality.

The post Bliv bedre til at forstå kundens behov appeared first on Key2Quality.

The post Kvalitet handler ikke om test men om værdi appeared first on Key2Quality.

The post Testmanager, orchestrator eller quality coach appeared first on Key2Quality.

Start med kundens behov

Egentlig starter det med en dialog med vores interessenter: Hvorfor er det, de synes, vi skal teste? Hvad er det, de gerne vil have ud af det? Som oftest finder vi ud af, at kunden ønsker:

• Kendt kvalitet inden idriftsættelse – transparens over løsningens kvalitet
• Overblik over risici – hvor har vi bekymringer i forhold til kvaliteten?
• At test skal være effektiv – der ønskes mest mulig test for færrest muligt penge
• At test ikke er en flaskehals

Kend svaret på de 6 H’er

For at vi kan imødekomme kundens ønsker, er det min erfaring, at vi er nødt til at have en struktureret tilgang til test i al almindelighed. Vi skal kende svaret på de 6 H’er:

• Hvad skal vi teste?
• Hvordan skal vi teste løsningen?
• Hvem tester?
• Hvor tester vi?
• Hvornår tester vi?
• Hvordan skal vi kommunikere om resultatet?

Brug testdesignteknikker

Struktureret test handler om at finde den gode arbejdsgang eller proces, have den rigtige strategi for projektet, toget, teamet – eller hvad vi nu organiserer os i. Men også nede i den konkrete testopgave, er det essentielt, at vi er strukturerede:

• Hvilke risici er der ved den feature, vi sidder med?
• Hvordan håndterer vi de risici bedst muligt med test?
• Hvordan sikrer vi, at den test, vi skal lave for en feature, giver værdi så hurtigt som muligt?
• Hvordan sikrer vi i virkeligheden, at vi ikke tester FOR MEGET?

Et af de værktøjer, som ethvert agilt team bør kunne grave frem for at sikre dette, er en struktureret tilgang til testdesign – og med det også en forståelse og brug af testdesignteknikker (Læs mere om testdesignteknikker i denne artikel). – Og nej, testdesignteknikkerne døde ikke med vandfaldet og v-modellen. De giver mere værdi end nogensinde, hvis de bliver brugt rigtigt! Og hvad er så rigtigt? Det hurtige svar er; så tidligt som muligt og så interaktivt som muligt.
Testdesignteknikkerne skal bruges…

• til at afklare, hvad det er, en given feature skal kunne
• til at detaljere og visualisere acceptkriterier på en måde, der kræver minimal dokumentation
• i samarbejdet i teamet (three amigos)
• til at forme grundlaget for det, vi gør, når vi implementerer testen; uanset om det er den test, som laves som en integreret del af udviklingen (unittest og unit-integration test), om det er en del af den regressionstest, der kører løbende, eller om det er en del af den udforskende test, vi laver på de enkelte user stories.

Værdien af testdesignteknikker

Og hvad er det så, de kan give af værdi, de der testdesignteknikker? Ikke så lidt, vil jeg mene:

1. 1. Øget dækning og effektivitet
      Testdesignteknikker hjælper med at identificere det sæt af testcases, der sikrer den ønskede testdækning, og som sikrer, at softwaren bliver testet fra forskellige perspektiver. Samtidig optimerer vi vores ressourcer, da vi tester med det mest effektive sæt i forhold til den dækning, vi ønsker.
   2. Tidlig fejlidentifikation
      Når vi bruger strukturerede testdesignteknikker proaktivt ved identifikation af acceptkriterier for user stories og features, identificerer vi potentielle fejl og mangler i softwaren tidligt i udviklingsprocessen. Altså hurtig feedback som muliggør hurtigere rettelser og reducerer de omkostninger, der er forbundet med at løse problemer, der opdages sent i processen.
   3. Bedre kvalitet af softwaren
      Testdesignteknikker bidrager til at øge kvaliteten af den udviklede software ved at sikre, at den opfylder kravene og fungerer som forventet.
   4. Forbedret rapportering og kommunikation
      Brug af testdesignteknikker fører til klare og veldefinerede testcases, og implementeret med den rette værktøjsdækning kan det skabe et bedre overblik over dækningen af testen. Dette forbedrer kommunikationen mellem teamet og dets interessenter.
   5. Øget kundetillid
      En struktureret tilgang, der anvender testdesignteknikker, resulterer i en mere pålidelig og robust software. Dette øger kundens tillid til det endelige produkt, da de kan være sikre på, at det er blevet gennemgribende testet for at sikre dets funktionalitet og kvalitet.
   6. Udforskende test
      Endelig kan testdesignteknikkerne bruges som et indspark til udforskende test og hjælpe med at strukturere de testideer, vi får, når vi analyserer den opgave, vi står overfor. Her kan vi vælge at tage den viden, vi får fra teknikkerne med videre til en dokumenteret test case, eller vi kan bruge dem som testideer i udforskende test.Så der er mange gode grunde til at fokusere på, hvordan vi i teamet og organisationen får et større fokus på en mere struktureret og effektiv tilgang til testdesign; både når det gælder økonomi, effektivitet og kvalitet af løsningen:
      • Vi får mere effektiv test – bedre test for færre penge
      • Vi får færrest muligt test cases for at dække bedst muligt
      • Vi laver løsningen rigtigt, og vi laver det rigtige

Bed om hjælp, hvis det virker uoverskueligt

Alt dette er noget, som vi arbejder med på vores kursus i Grundlæggende struktureret test, som er målrettet dig, der er ny i rollen som tester, eller som bare gerne vil have opdateret din testfaglige værktøjskasse uden at skulle tage en egentlig testcertificering.
Har du spørgsmål eller kommentarer til artiklen – eller har du brug for hjælp til at komme i gang med struktureret test – er du velkommen til at kontakte ekspert testkonsulent og underviser Gitte Ottosen på gitte@key2quality.dk eller telefon 4940 8552.

The post Hvorfor strukturere testdesign? appeared first on Key2Quality.

Vi bruger meget ordet “kvalitet”:

• Vi har et mål om at have høj kvalitet
• Vi har et “kvalitets-mindset”
• Vi bygger kvalitet ind
• Vi måler på mange forskellige ting for at kunne fortælle/rapportere om kvaliteten

Men hvad mener vi, når vi siger kvalitet? Og mener vi det samme som kunden, slutbrugeren eller ledelsen?

Husk på det første agile princip: “Vores højeste prioritet er at tilfredsstille kunden gennem tidlig og kontinuerlig levering af værdifuld software.”

Med det i tankerne – hvorfor så ikke flytte fokus til, hvilken værdi vores kunde ønsker, med den løsning vi skaber for dem? Og så finde ud af en måde at måle, om vi leverer denne værdi?

Dét ville være interessant af flere årsager: Ifølge forskning fra McKinsey “overstiger store IT-projekter i gennemsnit budgettet med over 45 procent, de går 7 procent over tid, og de leverer 56 procent ringere værdi end forudsagt”. Derfor er det første agile princip et værdifuldt fokus for vores kunder – og for os selv – ikke kun ud fra et forretningsmæssigt værdiperspektiv, men også ud fra et økonomisk synspunkt.

Alt det vil Gitte komme meget mere ind på i sin keynote “Let’s stop talking about quality” på konferencen German Testing Day onsdag d. 24. maj 2023 kl. 9.20-10.05.
Læs mere om Gittes keynote her, og tilmeld dig konferencen her.
Obs! Der er early bird indtil 28. april!

Du behøver dog ikke at tage helt til Frankfurt for at høre Gittes foredrag. Du kan blot booke Gitte til komme ud og holde foredraget hos jer, lige når det passer jer. Book foredraget her!

The post Oplev Gittes keynote på “German Testing Day” 23.-24. maj 2023 appeared first on Key2Quality.

Nu er der så gået 20 år, siden det agile manifest, og mange kæmper stadig med udfordringen om, hvordan agile ser ud i deres kontekst. Vi har samtidig fået selskab af diverse skalerede rammeværk som SAFe®, LESS, Scrum@Scale osv. Og sideløbende med dét, har vi også erkendt, at der i nogle situationer stadig eksisterer vandfalds/v-models lignende modeller i en del organisationer, dels af nød og dels fordi det måske bare passer bedst til deres kontekst.

Hvordan skal en testmanager så se ud i dag? Hvordan skaber man en profil, der passer ind i så forskelligartede kontekster som dét? Hvilke kompetencer og evner skal der til?

I forbindelse med min præsentation på EuroStar kiggede jeg en del på de forskellige definitioner på roller, som jeg har kunnet grave frem rundt omkring, nærmere bestemt de tre roller, som er nævnt i titlen på denne artikel; testmanager, orchestrator og Quality Coach. I det følgende kommer en hurtig gennemgang af de tre.

Testmanager

Testmanager rollen er defineret i ISTQB med følgende overordnede opgaver:

• Udvikling eller review af testpolitik og teststrategi for organisationen
• Planlægning af testaktiviteter ved at overveje konteksten og forstå testformål og -risici
• Forfatning og opdatering af testplaner
• Koordinering af testplanen med projektleder, product owners og evt. andre parter
• Påvirkning af projektplanlægningen med testperspektiver, f.eks. ved planlægning af integration
• Igangsætning af analyse, design, implementering og afvikling af tests, overvågning af testens fremdrift og resultater, tjek af slutkriteriernes status (eller ”Definition of Done”) og facilitering af testafslutningsaktiviteter
• Forbereding og levering af testfremdriftsrapporter og testopsummeringsrapporter, baseret på de indsamlede oplysninger
• Tilpasning af planlægningen baseret på testresultater og -fremdrift og udførsel af alle handlinger, der er nødvendige for testkontrol
• Understøttelse af opsætning af defektstyringssystem og passende konfigurationsstyring af testware
• Introduktion af passende metrikker for måling af testfremdrift og evaluering af testens og produktets kvalitet
• Understøttelse af udvælgelse og implementering af værktøjer til at støtte testprocessen, herunder anbefaling af budget for værktøjsvalg, tildeling af tid og indsats til pilotprojekter og vedvarende support til anvendelsen af værktøjerne.
• Beslutningstagning vedrørende implementering af testmiljøer
• Fortaler for testere, testteamet og testprofessionen inden for organisationen
• Udvikling af testernes færdigheder og karriere (f.eks. ved uddannelsesplaner, performanceevaluering, coaching osv.

Alt i alt en lang række opgaver, som har til formål at sikre, at vi

1. får defineret en teststrategi og får den implementeret
2. har de kompetencer, der skal til for at kunne udleve strategi og planer
3. får fulgt op på, at ”testprojektet” så også afvikles som planlagt
4. supporterer, når der opstår problemer.

Hvis du føler, at beskrivelsen er antikveret og handler om en testmanager i et vandfald eller v-models projekt, så prøv lige at parkere den tanke indtil videre.

Orchestrator

Den anden rolle på min liste var ”orchestrator”. Jeg har valgt at bibeholde det engelske navn, da denne syllabus ikke er oversat til dansk. Rollen er blevet defineret af Sogeti i forbindelse med udviklingen af TMAP® og fokuserer på en rolle, der arbejder med at supportere test og kvalitetssikring på tværs af flere agile teams, altså en skaleret agil kontekst som f.eks. SAFe®. TMAP beskriver rollen som følger:

• Skab kontrol med kvaliteten ved implementering af ændringer i applikationskæden
• Skab og sikr gennemsigtighed, og kommuniker og kontroller på grundlag af dette
• Støt den løbende forbedringsproces
• Organiser end-to-end test
• Udfør interessentanalyser
• Estimer indsatsen for virtuelle teammedlemmer, og arranger disse aktiviteter
• Sikr værktøj til backlog og testware
• Definer og prioriter backlog for end-to-end kvalitet og test
• Organiser procesmæssig justering af features med relevante interessenter
• Organiser virtuelle teamsessioner (refinement, sprintplanlægning, sprintgennemgang mv.)
• Suppler DoD på end-to-end niveau.

Der er altså tale om en rolle, der stadig arbejder med noget af den ”klassiske testledelse” omkring teststrategi og planlægning men også med fokus på mere forebyggende aktiviteter i forhold til features samt primært med fokus på end-to-end test og kvalitetssikring på tværs af teams.

Quality Coach

Sidst men ikke mindst er der begyndt at dukke en rolle op, der kaldes ”quality coach”. Her er der ikke nogen officiel definition at finde, men Anne-Marie Charrett har defineret en rigtig god én af slagsen. Her listes en række områder, som en quality coach med fordel kan have kompetencer indenfor:

• Forandringsagent (ADKAR, Roadmap, Feedback)
• Coaching (testpraksis, motivation, samarbejde)
• Mentoring (distribuere information, rådgive)
• Facilitering (input til procesforbedring)
• Forskning (værktøjer, teknikker, tilgange)
• Rådgivning (identificere metrikker, udvikle metoder)
• Fortaler (forklare proces, kvalitet m.m.)
• Marketing (visualisere information, kommunikere udover teamet)

Detaljerne omkring de enkelte kompetenber kan du få i hendes artikel What is a quality coach? Men i denne rolle er der meget fokus på at gøre teamet i stand til at løse opgaverne omkring test og kvalitetssikring – og den testledelse, der hører med. Hun har et rigtig godt eksempel sidst i artiklen, hvor hun skriver:

Testlead udvikler teststrategi til teamet – quality coach faciliterer skabelsen af en teststrategi

Testlead er ansvarlig for testaktiviteterne – quality coach er ansvarlig for at muliggøre og forbedre testaktiviteter i teamet

Testlead rapporterer om status på test indenfor teamet eller på tværs af et antal teams – quality coach hjælper teamet med at rapportere på status på test og kontinuerlig kvalitetsforbedring på tværs af et antal teams.

Testlead er mentor/coach for andre testere – quality coach er mentor/coach for tværfunktionelle teams

Med andre ord fokuserer quality coachen på at sætte teamet i stand til at løse opgaven i stedet for at løse opgaven selv.

Betyder det så, at du skal vælge en af de tre løsninger? Det korte svar er nej, jeg ser det mere som en buffet af muligheder; her er alle mulige kompetencer, der MÅSKE er relevante for mig – det afhænger af konteksten. Hver gang jeg befinder mig i en ny kontekst, et nyt job eller et nyt projekt skal jeg derfor stoppe op og vurdere, hvilke kompetencer har jeg brug for her for at løse min opgave. Og mangler jeg nogen, jeg skal have styr på, inden der går for lang tid?

Et par eksempler:

Det store K02 projekt

Hvis jeg sidder som testmanager i et stort projekt på kundesiden af en K02 kontrakt, vil jeg nok hælde til dét, der er beskrevet om testmanageren i ISTQB. Men hvis jeg samtidig i den situation har et antal testere, som aldrig har testet før, og som nu skal sættes i stand til at gøre klar til al den accepttest, der er fastlagt i kontrakten, har jeg brug for coache dem – at hjælpe dem med at blive i stand til at løse deres opgave. Så dels skal jeg have kompetencer som mentor/coach, dels skal jeg have en grundlæggende testanalytisk faglighed, så jeg kan hjælpe dem i gang med at skrive testcases, og endelig skal jeg måske facilitere nogle workshops for at få hul på opgaven.

Den hjemmestrikkede skalerede agile model

Hvis jeg sidder i et program med et antal projekter og har ansvaret på tværs af alle projekter – og vi vel at mærke vil forsøge at køre en eller anden form for skaleret agil model (evt. hjemmestrik), vil jeg sandsynligvis tage lidt fra alle tre: Jeg skal have sat en strategi på tværs af programmet, jeg skal sandsynligvis håndtere accepttests i enden af et antal inkrementer, men jeg skal også sikre at der testes løbende i det enkelte teams – og at vi får testet end-to-end. Og hvis nu ikke jeg har testere i de teams, skal jeg coache teams til at tage opgaven selv, ligesom jeg skal have sikre, at vi får forretningen involveret i forbindelse med acceptests. Så reelt nok mest orchestrator, men med lidt fra testmanager og quality coachen også.

Et agilt projekt med 3-4 agile teams

Lad os antage, at jeg er heldig at skulle supportere et agilt ”projekt” med 3-4 agile teams, og der ikke i den sammenhæng er den store afleveringsforretning til kunden i form af formelle accepttests med den planlægning, styring og rapportering, der skal til i den kontekst. Her kan jeg som quality coach fokusere mit arbejde på at hjælpe ”mine” teams til at blive endnu bedre til at tage ejerskab i forhold til kvalitet. I starten kan det godt være, at jeg trækker lidt testmanagement kompetencer ind for at få noget startet, men stille og rolig bevæger jeg mig over til at blive mere coach og mindre manager.

Det var blot tre eksempler. Der er ikke to kontekster der er ens, og min anbefaling er, at du bruger ovenstående som inspiration til, hvordan du kan gå ind og ”fylde din tallerken ved buffeten”. Hvad er den rigtige kombination for dig – hvordan kan du bedst muligt hjælpe og skabe værdi, der hvor dit arbejdsliv er?

På vores kursusside kan du læse mere om mulighederne for at lære mere om nogle af de kompetencer, der er beskrevet her. Her kan du blandt andet finde kurset Organizing build-in quality at scale fra TMAP® der fokuserer på rollen som orchestrator, og selvfølgelig ISTQB Advanced Level Test Manager der giver dig kompetencerne til den klassiske testmanager rolle. Endnu eksisterer der ikke et quality coach kursus – her skal du ud og fange mange forskellige kompetencer, der ikke nødvendigvis er testfaglige (coaching, mentoring, facilitering), men du kan også få inspiration til den agile test til teamet via ISTQB Foundation Acceptance Testing eller TMAP: Quality for cross-functional teams

Er du i tvivl, er du velkommen til at kontakte mig på gitte@key2quality.dk, så finder vi ud af noget sammen.

The post Testmanager, orchestrator, quality coach – kært barn har mange navne appeared first on Key2Quality.

I mange agile teams er det primære fokus på den enkelte user story – det er ”pakken af brugerværdi”, vi arbejder på. Men med testbrillerne på er det vigtigt også at huske at komme op i helikopteren og tænke på kvaliteten af den samlede feature, potentielle afhængigheder til andre features mv. – og så skal der testplanlægning til. Også i agile.

Gitte Ottosen giver i denne video en lynintroduktion til, hvad testplanlægning er for en størrelse, både i forhold til det enkelte team og i en skaleret kontekst.

The post Testplanlægning i agil udvikling appeared first on Key2Quality.