Forelæsningsrække om kunstig intelligens på CBS

Kunstig intelligens (AI) har på rekordtid forandret måden, vi lever og arbejder på. Forelæsningsrækken på Copenhagen Business School gav deltagerne en dybere forståelse af AI's indflydelse på erhvervslivet, uddannelsessektoren og den offentlige sektor. Med tre skarpe foredrag af førende eksperter fik vi en bred indsigt i AI's revolutionerende potentiale samt de udfordringer, teknologien bringer med sig.

AI – Den store revolution (27. januar 2025)

v. Jan Damsgaard, professor, Institut for Digitalisering, CBS

Første forelæsning tog os med på en rejse gennem AI's eksplosive udvikling og de konsekvenser, den har for virksomheder, samfund og vores dagligdag. Jan Damsgaard præsenterede, hvordan AI allerede nu skaber værdi ved at automatisere processer, optimere beslutningstagning og åbne for nye forretningsmodeller. Han berørte åbne spørgsmål om regulering, dataetik og risikoen for AI-baserede monopoler, som kan forme fremtidens digitale landskab.

Et centralt tema var behovet for en balanceret tilgang til regulering: AI skal styres, men ikke kvæles af for restriktive love, så Europa kan forblive konkurrencedygtig. Afslutningsvis blev der reflekteret over, hvordan AI vil forme fremtidens arbejdsmarked og kravene til vores digitale kompetencer.

AI, læring og uddannelse (3. februar 2025)

v. Sine Zambach, adjunkt, Institut for Digitalisering, CBS

Den anden forelæsning fokuserede på AI's rolle i uddannelsessektoren og læring. Sine Zambach belyste, hvordan AI allerede nu transformerer undervisning gennem personaliseret læring, automatiserede feedbacksystemer og intelligent tutoring. Hun præsenterede eksempler på, hvordan AI understøtter lærere i at skræddersy undervisning og identificere elever, der har brug for ekstra støtte.

Men med teknologien følger også dilemmaer: Hvordan sikrer vi, at AI ikke skaber etisk problematiske situationer, hvor elever bliver overvåget eller ensrettet i deres læring? Hvordan kan vi forberede elever og studerende på en fremtid, hvor AI er en naturlig del af deres arbejds- og studieliv? Forelæsningen understregede behovet for kritisk tænkning i brugen af AI i undervisningen og en åben debat om teknologiens etiske aspekter.

AI, healthcare, and the public sector (10. februar 2025)

v. Rony Medaglia, professor MSO, Institut for Digitalisering, CBS

Den tredje og sidste forelæsning, afholdt på engelsk, dykkede ned i AI's betydning for sundhedssektoren og den offentlige forvaltning. Rony Medaglia præsenterede eksempler på, hvordan AI bruges til at forbedre patientdiagnostik, effektivisere sagsbehandling og optimere offentlige ydelser. AI's evne til at analysere store datamængder betyder, at sundhedspersonale kan tage hurtigere og mere præcise beslutninger, hvilket kan redde liv og reducere omkostninger.

Forelæsningen behandlede dog også de udfordringer, som AI medfører i den offentlige sektor: Hvordan sikrer vi transparens i beslutninger truffet af algoritmer? Hvordan beskytter vi borgernes privatliv i en tid, hvor AI anvender enorme datamængder? Diskussionen kredsede om balancen mellem teknologisk innovation og borgernes retssikkerhed.

Konklusion

Forelæsningsrækken gav et nuanceret billede af AI's indflydelse på samfundet. Fra erhvervslivet til uddannelse og sundhed blev det klart, at AI byder på store muligheder, men også udfordringer, der kræver opmærksomhed. Reguleringsspørgsmålet stod centralt i alle tre foredrag: Vi skal finde en vej, hvor vi udnytter AI's potentiale uden at overse de etiske og juridiske risici.

Med anbefalede læsninger som 'AI – Mellem fornuft og følelse' og 'AI i gymnasiet' er der rig mulighed for at dykke endnu dybere ned i emnet og reflektere over AI's rolle i vores hverdag. Forelæsningsrækken på CBS har uden tvivl været en værdifuld oplevelse for mig, der ønsker at forstå AI's betydning i et moderne samfund.

 

Test i sekventielle vs agile udviklingsprojekter - En komparativ analyse

Forskellen mellem test i sekventielle (traditionelle) udviklingsprojekter og agilt baserede udviklingsprojekter er markant både i tilgangen, timing, roller og værktøjer. Nedenfor gives en detaljeret sammenligning af test i de to tilgange.

1. Overordnet tilgang

Sekventielle udviklingsprojekter (fx Vandfaldsmodellen, V-Model)

• Test følger en lineær, faseopdelt tilgang, hvor test først påbegyndes efter udvikling er afsluttet.
• Krav defineres i starten af projektet, hvilket gør det svært at ændre dem senere.
• Test foregår i en separat testfase (ofte Unittest → Integrationstest → Systemtest → Accepttest).
• Formålet er at bekræfte, at produktet lever op til de fastlagte krav.

Agilt baserede udviklingsprojekter (fx Scrum, SAFe, Kanban)

• Test er en iterativ og kontinuerlig proces, hvor test sker parallelt med udviklingen.
• Krav kan ændres dynamisk i takt med nye forretningsbehov og brugerfeedback.
• Test udføres løbende i hver sprint og integreres i udviklingsprocessen.
• Formålet er at sikre kvalitet og hurtig feedback for at understøtte en inkrementel levering af funktionalitet.

2. Timing og testfaser

Sekventiel udvikling

• Test kommer sent i udviklingsforløbet (ofte efter implementering er færdig).
• Ofte store testsessioner mod slutningen, hvilket kan føre til tidspres og flaskehalse.
• Regressionstest foretages primært i den afsluttende fase.
• Brugere inddrages typisk kun i slutningen (UAT – User Acceptance Testing).

Agil udvikling

• Test er en integreret del af hver sprint (typisk 1-4 uger lange).
• Kontinuerlig test gennem testautomatisering, unittests, integrationstest og funktionelle tests.
• Regressionstest er en fast del af hver sprint og sikres via automatisering.
• Brugerne kan være involveret løbende (f.eks. gennem demoer og feedback).

3. Testroller og ansvarsfordeling

Sekventiel udvikling

• Testansvaret ligger ofte hos en dedikeret testafdeling eller QA-team.
• Udviklere er sjældent involveret i testningen.
• Testere skriver detaljerede testcases og testplaner i starten af testfasen.
• Fejlrapporter sendes tilbage til udviklingsteamet, hvilket kan føre til lange cyklusser for fejlrettelser.

Agil udvikling

• Testansvaret er distribueret, og hele teamet har ansvar for kvalitet.
• Udviklere, testere og forretningsanalytikere samarbejder tæt om test.
• Testere arbejder tæt sammen med udviklere om testautomatisering og tidlig validering.
• "Shift-left"-tilgangen anvendes, hvor testning påbegyndes så tidligt som muligt.

4. Test og testværktøjer

Sekventiel udvikling

• Primært manuelle testcases, struktureret systemtest og accepttest.
• Større fokus på end-to-end test i en adskilt testfase.
• Testautomatisering anvendes typisk kun i regressionstest, men kan være begrænset.
• Almindelige værktøjer: (HP) ALM, TestRail, Xray, Selenium (hvis automatisering anvendes).

Agil udvikling

• Fokus på automatisering af unit test, API test og GUI test.
• Test udføres kontinuerligt via CI/CD-pipelines.
• Brug af eksplorativ test og adfærdsdrevet test (BDD) for hurtigere feedback.
• Almindelige værktøjer: JIRA, Xray, Selenium, Cypress, Postman, Cucumber, Jenkins.

5. Håndtering af fejl og kvalitetssikring

Sekventiel udvikling

• Fejl identificeres sent i udviklingsprocessen, hvilket gør dem dyrere at rette.
• Testere skriver detaljerede fejlrapporter, som udviklerne løser separat.
• Fokus er på at dokumentere defekter og fejlsporing.

Agil udvikling

• Fejl identificeres og rettes hurtigt, ofte i samme sprint.
• Kontinuerlig integration gør det muligt at fange fejl tidligt.
• Testere arbejder tæt sammen med udviklere for hurtig fejlfinding (f.eks. via par-testning).

6. Risici og faldgruber

Sekventiel udvikling

• Risiko for, at test kommer for sent, og kritiske fejl først opdages sent.
• Store og tunge testcyklusser kan forsinke levering.
• Mindre fleksibilitet i forhold til ændrede krav.

Agil udvikling

• Risiko for utilstrækkelig testdækning, hvis der ikke er en struktureret teststrategi.
• Testautomatisering kræver investering og vedligeholdelse.
• Hurtigt tempo kan føre til kompromiser i testkvaliteten, hvis teamet ikke er disciplineret.

Konklusion

Sekventiel test er velegnet til stabile, langsigtede projekter med fastlagte krav, hvorimod agil test er ideel til projekter med hurtigt skiftende krav og behov for hurtig feedback.

En hybrid tilgang, hvor testautomatisering, tidlig testinvolvering og strukturerede teststrategier kombineres, kan ofte give de bedste resultater – især i organisationer, der er i en overgang fra sekventiel til agil udvikling.

 

Boganmeldelse: Holistic Testing – Weave Quality into Your Product

Forfattere: Janet Gregory & Lisa Crispin
Forlag: Agile Testing Fellowship Press
Udgivelsesår: 2022

 

En helhedsorienteret tilgang til kvalitet i agile teams

Janet Gregory og Lisa Crispin er velkendte autoriteter inden for agile testmetoder, og deres bog Holistic Testing – Weave Quality into Your Product er endnu en stærk ressource til testere, udviklere og produktteams, der ønsker at forbedre softwarekvaliteten på en integreret måde.

I stedet for at se test som en separat fase i udviklingsprocessen, argumenterer forfatterne for, at kvalitet bør være en fælles opgave på tværs af hele teamet – fra idéfase til levering. Bogen er både inspirerende og praktisk, med klare strategier til, hvordan test og kvalitetssikring kan blive en naturlig del af agile arbejdsprocesser.

Styrker ved bogen

1. Klar og tilgængelig formidling

Bogen er skrevet i et letforståeligt sprog med en logisk opbygning, der gør det nemt for læseren at følge med. Gregory og Crispin er kendt for deres evne til at forklare komplekse emner på en jordnær måde, og denne bog er ingen undtagelse.

2. Holistisk perspektiv på test og kvalitet

En af de stærkeste sider ved bogen er dens helhedsorienterede tilgang til testning. Den dækker både tekniske og ikke-tekniske aspekter af kvalitetssikring, herunder:

• Hvordan teams kan samarbejde for at forebygge fejl tidligt
• Hvordan kvalitet kan indarbejdes i udviklingsprocessen frem for kun at blive kontrolleret bagefter
• Hvordan en testdrevet kultur kan styrke hele organisationen

3. Praktiske værktøjer og teknikker

Bogen er ikke kun teoretisk – den indeholder også en række konkrete værktøjer og teknikker, som teams kan anvende for at forbedre deres testpraksis. Der er eksempler på:

• Hvordan testere kan samarbejde tættere med udviklere
• Hvordan test og kvalitetssikring kan integreres i CI/CD-processer
• Hvordan man måler testeffektivitet i agile teams

4. Relevante eksempler og cases

Forfatterne bruger en række cases og eksempler fra den virkelige verden til at illustrere deres pointer. Dette gør det lettere for læseren at relatere bogens koncepter til deres egen praksis.

5. Fokus på teamsamarbejde og kvalitet som et fælles ansvar

I mange organisationer er test stadig en siloaktivitet, men Holistic Testing udfordrer denne tilgang og viser, hvordan kvalitet bliver stærkere, når hele teamet tager ansvar. Dette perspektiv gør bogen særligt værdifuld for agile teams, der ønsker at forbedre deres samarbejde omkring test og kvalitetssikring.

Forbedringsområder

1. Flere tekniske eksempler

Mens bogen dækker mange aspekter af teststrategi og samarbejde, kunne den have inkluderet flere eksempler på tekniske implementeringer, f.eks. testautomatisering, performance-test og sikkerhedstest. For testere med en mere teknisk baggrund kunne dette have givet yderligere værdi.

2. Dybdegående analyse af måling af kvalitet

Bogen berører, hvordan teams kan måle kvalitet, men en mere struktureret tilgang til testmetrikker og KPI’er ville have gjort denne del stærkere. For mange teams er det en udfordring at finde de rette målepunkter for test og kvalitet, og en mere detaljeret vejledning kunne have hjulpet her.

Samlet vurdering

Holistic Testing – Weave Quality into Your Product er en fremragende bog for testere, udviklere, Scrum Masters og produktledere, der ønsker at gøre test og kvalitet til en integreret del af deres agile processer. Gregory og Crispin leverer en inspirerende guide til, hvordan teams kan samarbejde om at skabe software af høj kvalitet.

Selvom bogen kunne have haft flere tekniske eksempler og en dybere analyse af kvalitetsmåling, er den stadig en værdifuld ressource, især for teams, der ønsker at bevæge sig væk fra en silo-baseret tilgang til test.

Den anbefales varmt til alle, der arbejder med test og kvalitet i agile miljøer, og som ønsker en stærkere forståelse af, hvordan test kan være en drivkraft for bedre softwareudvikling.

 

Boganmeldelse: Test Automation Engineering Handbook

Forfatter: Manikandan Sambamurthy
Forlag: Packt
Udgivelsesår: 2023

 

En omfattende guide til testautomatisering for moderne softwareteams

Testautomatisering er blevet en afgørende disciplin i softwareudvikling, hvor agilitet og DevOps stiller stadigt højere krav til hurtigere og mere stabile leverancer. Test Automation Engineering Handbook af Manikandan Sambamurthy er en stærk ressource for testingeniører, udviklere og testledere, der ønsker at opbygge eller forbedre deres automatiseringskompetencer.

Bogen leverer en balanceret blanding af teori og praktiske eksempler, hvilket gør den velegnet til både begyndere og erfarne testautomatiseringsspecialister.

Styrker ved bogen

1. Klar struktur og progression

Bogen er velstruktureret, idet den fører læseren fra grundlæggende principper i testautomatisering til avancerede emner såsom CI/CD-integration, strategisk testautomatisering og skalerbare frameworks. Denne progression gør det nemt at følge med, uanset erfaringsniveau.

2. Hands-on tilgang med eksempler

En af bogens store fordele er dens praktiske eksempler og kodeuddrag. Læseren får konkrete demonstrationer af testautomatiseringsværktøjer som Selenium, Cypress, Playwright og Appium. Bogen forklarer ikke blot, hvordan man skriver automatiserede tests, men også hvordan man organiserer dem for maksimal genanvendelighed og vedligeholdelse.

3. Fokus på bedste praksis og strategi

Ud over tekniske detaljer diskuterer bogen vigtige strategiske aspekter af testautomatisering, såsom:

• Hvordan man vælger den rigtige testautomatiseringsstrategi
• Hvornår automatisering giver mest værdi
• Hvordan man strukturerer tests, så de er robuste og nemme at vedligeholde

Dette gør bogen til mere end blot en guide til værktøjer – den hjælper testteams med at træffe informerede beslutninger.

4. Moderne teknologier og tendenser

Bogen er opdateret med moderne trends inden for testautomatisering, herunder AI-baseret testning, skalerbarhed i cloud-miljøer og integration med DevOps-pipelines. Dette sikrer, at læseren får indsigt i de nyeste udviklinger på området.

Forbedringsområder

1. Mere dybde i performance- og sikkerhedstest

Mens bogen dækker funktionel testautomatisering i detaljer, kunne den have givet mere dybdegående indsigt i automatisering af performance- og sikkerhedstest. Disse områder bliver stadig vigtigere i moderne softwareudvikling, og en udvidelse her ville have gjort bogen endnu mere komplet.

2. Flere cases fra virkelige virksomheder

Selvom bogen indeholder praktiske eksempler, kunne den have draget fordel af flere konkrete cases fra virksomheder, der har implementeret testautomatisering – herunder hvilke udfordringer de stod overfor, og hvordan de blev løst.

Samlet vurdering

Test Automation Engineering Handbook er en fremragende bog for alle, der ønsker at forstå eller forbedre deres testautomatiseringspraksis. Den kombinerer teori med praktiske eksempler og dækker moderne teknologier, hvilket gør den relevant for testautomatiseringsspecialister i dag.

Bogen fungerer både som en introduktion for nybegyndere og en værdifuld reference for erfarne fagfolk. Med nogle flere cases og dybdegående dækning af performance- og sikkerhedstest ville den være endnu stærkere.

Den anbefales til testingeniører, udviklere, testmanagers og DevOps-professionelle, der ønsker en solid og moderne tilgang til testautomatisering.

 

Webinar om Testteknikkerne Ækvivalenspartitionering og Grænseværdianalyse og lidt mere

Den 30/1 2025 afholdt jeg et webinar om testteknikkerne Ækvivalenspartitionering og Grænseværdianalyse i vor Q Topics regi @ Q Nation. Hvis ikke du deltog eller gerne vil gense webinaret findes optagelsen på dette link. På linket finde både mine og mine dygtige kollegaers webinarer. Du er naturligvis også velkommen til at dele det med dine kollegaer. God fornøjelse.

LINK: 

https://www.qnation.dk/oversigt-over-tidligere-events

Test af User Stories: En Guide til Effektiv Test i Agile Projekter

 1. Introduktion

Test af user stories er en kritisk aktivitet i agile udviklingsmetoder. Det sikrer, at kravene til systemet er forståelige, entydige og testbare. I modsætning til traditionelle kravspecificeringer er user stories ofte mere uformelle, hvilket kræver en struktureret tilgang til test for at minimere misforståelser og sikre funktionalitet.

Agile teams arbejder iterativt og inkrementelt, hvilket betyder, at test af user stories sker kontinuerligt gennem udviklingsprocessen. Testerne spiller en aktiv rolle i at analysere user stories, definere testcases og samarbejde tæt med udviklere og produktejere for at forbedre kvaliteten.

2. Formål med at teste user stories

Formålet med at teste user stories er:

• At validere forståelsen af kravet – Sikre, at alle teammedlemmer har en fælles forståelse af, hvad der skal udvikles.
• At identificere manglende eller uklare acceptancekriterier – Testning afslører huller i kravene og mulige edge cases.
• At verificere funktionalitet – Sikre, at implementeringen stemmer overens med kravene.
• At understøtte automatisering – Tidlig testdesign gør det nemmere at implementere automatiserede tests.
• At reducere fejl senere i udviklingsforløbet – Jo tidligere fejl opdages, jo billigere er de at rette.

3. Forudsætninger for test af user stories

For at kunne teste user stories effektivt skal følgende forudsætninger være opfyldt:

a) Kvaliteten af user stories

En god user story bør følge INVEST-kriterierne:

• Independent (Uafhængig): Skal kunne udvikles og testes isoleret.
• Negotiable (Forhandlingsbar): Ikke en kontrakt, men et udgangspunkt for dialog.
• Valuable (Værdiskabende): Skal give værdi for brugeren.
• Estimable (Estimerbar): Skal kunne vurderes ift. udvikling og test.
• Small (Lille): Skal kunne implementeres i én iteration.
• Testable (Testbar): Skal have klare acceptancekriterier.

b) Acceptancekriterier

Acceptancekriterier er afgørende for test af user stories, da de definerer de betingelser, der skal være opfyldt, for at en user story kan betragtes som færdig. De bør være:

• Specifikke: Tydelige og præcise.
• Målbare: Kan verificeres via test.
• Forståelige: Letforståelige for både forretning og teknik.

c) Samarbejde mellem roller

Effektiv test af user stories kræver tæt samarbejde mellem udviklere, testere og produktejere. En fælles forståelse skabes ofte gennem Three Amigos-møder, hvor disse tre roller gennemgår og diskuterer user stories.

4. Fremgangsmåde

a) Gennemgang af user story

• Gennemlæs user story og acceptancekriterier.
• Identificér manglende informationer eller uklare krav.
• Identificér edge cases og risikoområder.

b) Definering af testcases

• Funktionelle tests: Sikrer, at funktionaliteten virker som forventet.
• Negative tests: Tester uventede input og fejlscenarier.
• Non-funktionelle tests: Test af ydeevne, brugervenlighed og sikkerhed.
• Testteknikker:
  • Ekvivalenspartitionering: Opdeling af input i grupper med samme adfærd.
  • Grænseværdianalyse: Test af værdier tæt på grænserne.
  • Beslutningstabeller: Test af komplekse logiske sammenhænge.
  • Exploratory testing: Ad hoc test for at opdage uventede fejl.

c) Testafvikling

• Testcases udføres manuelt eller automatiseres.
• Fejlrapportering sker med detaljerede beskrivelser af fundne problemer.
• Regressionstests sikrer, at ændringer ikke bryder eksisterende funktionalitet.

d) Automatisering

• Automatiserede tests kan dække regressionstest af user stories.
• Testframeworks som Selenium, Cypress eller Playwright kan bruges til UI-test.
• Unit tests i udviklerens kodebase kan hjælpe med at validere logik.

e) Feedback og iteration

• Testresultater deles med udviklingsteamet.
• User stories opdateres efter behov for at afspejle nye læringer.

5. Stærke og svage sider

Stærke sider:

• Tidlig validering: Tester krav, før de udvikles.
• Forbedret samarbejde: Styrker dialogen mellem udvikling, test og forretning.
• Mere præcise krav: Acceptancekriterier bliver mere skarpe.
• Automatiseringsvenlig tilgang: Strukturerede tests kan let automatiseres.

Svage sider:

• Afhængig af gode acceptancekriterier: Dårligt definerede user stories giver uklare tests.
• Kan være tidskrævende: Test af user stories kræver grundig analyse.
• For mange små stories kan skabe overhead: Hvis user stories opdeles for meget, kan det give mere testarbejde end nødvendigt.

6. Eksempler på test af user stories

Eksempel 1: Test af login user story

User Story:

Som bruger vil jeg kunne logge ind med mit brugernavn og password, så jeg kan få adgang til mine personlige data.

Acceptancekriterier:

1. Brugeren skal kunne logge ind med et gyldigt brugernavn og password.
2. Brugeren skal få en fejlmeddelelse ved forkert brugernavn eller password.
3. Efter 5 fejlede loginforsøg skal kontoen låses i 5 minutter.

Testcases:

• Log ind med gyldige credentials (positiv test).
• Log ind med ugyldigt brugernavn eller password (negativ test).
• Forsøg at logge ind 5 gange med forkerte credentials og verificér låsning.

Eksempel 2: Test af en søgefunktion

User Story:

Som bruger vil jeg kunne søge efter produkter i en webshop, så jeg kan finde det, jeg leder efter.

Acceptancekriterier:

1. Brugeren kan søge ved at indtaste søgeord i søgefeltet.
2. Systemet viser produkter, der matcher søgeordet.
3. Systemet viser en besked, hvis ingen produkter findes.
4. Systemet skal kunne håndtere store datamængder effektivt.

Testcases:

• Søgning med et gyldigt søgeord.
• Søgning med et ugyldigt søgeord (ingen resultater).
• Søgning med specialtegn.
• Søgning med store datamængder for at teste performance.

7. Afslutning

Test af user stories er afgørende for at sikre software af høj kvalitet i agile projekter. Ved at bruge strukturerede testteknikker og tæt samarbejde med udviklingsteamet kan testere hjælpe med at identificere fejl tidligt og forbedre kravspecificeringen.

For at få mest muligt ud af test af user stories bør teams fokusere på klare acceptancekriterier, automatisering og løbende feedback. Dette fører til mere præcise krav, færre fejl og et bedre slutprodukt.

 

Klassifikationstræ - En konkret og visuel testteknik

Som senior testanalytiker er du altid på udkig efter teknikker, der kan sikre effektiv og præcis testdækning. Klassifikationstræ-metoden (Classification Tree Method, CTM) er en kraftfuld tilgang, der strukturerer testdesign på en visuel og systematisk måde, især når du arbejder med komplekse systemer med mange inputkombinationer.

Hvad er klassifikationstræ?

Klassifikationstræ er en black-box testteknik, der bruges til at identificere og kombinere testtilfælde ved hjælp af et trædiagram. Denne metode opdeler inputvariabler og deres mulige værdier i klasser og kombinerer dem på en organiseret måde for at sikre optimal testdækning.

Fremgangsmåde

1. Definér testobjektet
   Start med at identificere det system eller modul, der skal testes. Klargør, hvilke inputvariable og funktionelle aspekter der er relevante.

2. Identificér klassifikationer
   For hver inputvariabel identificeres klassifikationer, som repræsenterer mulige tilstande, værdier eller kategorier.
   Eksempel: Hvis en bruger skal vælge en betalingsmetode, kan klassifikationerne være "kreditkort", "PayPal" og "bankoverførsel."

3. Definér partitioner
   Opdel hver klassifikation i disjunkte værdier eller intervaller (partitioner).
   Eksempel: Kreditkort kan yderligere opdeles i "Visa", "MasterCard" og "Amex."

4. Byg klassifikationstræet
   Visualisér klassifikationerne og deres partitioner som et trædiagram, hvor grene repræsenterer mulige kombinationer.

5. Udvælg testkombinationer
   Brug heuristikker som pairwise eller udtømmende testdækning til at vælge meningsfulde kombinationer af klassifikationer.

6. Opret testtilfælde
   Hver udvalgt kombination repræsenterer et testtilfælde, som kan implementeres og køres.

Værktøjer

• Testona
  Et specialiseret værktøj til at opbygge og administrere klassifikationstræer.

• Microsoft Excel eller Google Sheets
  Kan bruges til simple klassifikationstræer og testtilfælde uden ekstra software.

• Mindmapping-værktøjer
  Værktøjer som XMind og MindMeister er effektive til at visualisere klassifikationstræer.

Fælder

1. Overvældende kompleksitet
   Store klassifikationstræer kan hurtigt blive komplekse og svære at vedligeholde. Reducér kompleksitet ved at bruge pairwise-strategi.

2. Manglende forankring i krav
   Hvis klassifikationerne ikke er veldefinerede eller knyttet til krav, risikerer du at teste irrelevante scenarier.

3. Overset negative testtilfælde
   Fokus på positive kombinationer kan føre til, at kritiske fejl i negative scenarier ikke opdages.

Styrker

• Visuel repræsentation
  Klassifikationstræet giver et klart overblik over mulige testkombinationer og hjælper med at identificere udeladelser.

• Systematisk tilgang
  Metoden sikrer, at alle relevante kombinationer af input behandles, hvilket forbedrer testdækningen.

• Fleksibilitet
  Velegnet til både simple og komplekse systemer, da træet kan justeres efter behov.

Eksempel - Tekst

Scenarie: Validering af loginformular

En loginformular kræver, at brugeren indtaster brugernavn, adgangskode og vælger en sikkerhedsmulighed.

• Klassifikationer:

  • Brugernavn: "Udfyldt", "Tomt".
  • Adgangskode: "Gyldig", "Ugyldig", "Tom".
  • Sikkerhedsmulighed: "To-faktor", "Ingen sikkerhed".

• Udvalgte testkombinationer:

  1. (Udfyldt, Gyldig, To-faktor)
  2. (Udfyldt, Ugyldig, Ingen sikkerhed)
  3. (Tomt, Gyldig, To-faktor)

Eksempel - Visuelt

Nedenstående er vist et mere visuelt eksempel på et klassifikationstræ:

Konklusion

Klassifikationstræ-metoden er en effektiv teknik til at designe testtilfælde på en struktureret måde. Når teknikken anvendes korrekt, sikrer den både bedre testdækning og en reduceret risiko for oversete fejl. Brug værktøjer til at visualisere træet og vær opmærksom på potentielle faldgruber for at få det fulde udbytte af denne metode.

 

Sådan udarbejder du en testplan

Her er en detaljeret guide til at skrive en testplan baseret på ISO 29119 og ISTQB-standarderne:

1. Forstå formålet med testplanen

En testplan er et styringsdokument, der beskriver omfang, tilgang, ressourcer og tidsplan for de testaktiviteter, der kræves for et projekt. Det hjælper med at sikre, at testindsatsen opfylder kravene og interessenternes forventninger.

Formål ifølge:

• ISO 29119: Fremhæver, at testplanen skal være et levende dokument, der udvikles gennem projektets livscyklus.
• ISTQB: Fokuserer på at skabe gennemsigtighed, opnå aftaler og styre testindsatsen.

2. Definer indholdet i testplanen

ISO 29119-3 giver en standardiseret skabelon, som kan tilpasses projektets behov.

Overordnede sektioner i testplanen

1. Introduktion

   • Beskrivelse af projektet og testens formål.
   • Projektets kontekst og baggrund.
   • Definition af testobjekter.

2. Testmål og -kriterier

   • Overordnede testmål (funktionelle, ikke-funktionelle).
   • Acceptkriterier for testens afslutning.

3. Omfang

   • Hvilke dele af systemet der testes.
   • Hvad der ikke er omfattet (out of scope).

4. Teststrategi og -tilgang

   • Beskrivelse af den overordnede tilgang.
   • Brug af teknikker som risikobaseret test, boundary value analysis osv.
   • Planlagte testtyper (fx unit, integration, UAT).

5. Ressourcer og ansvar

   • Allokering af testteamets roller og ansvar.
   • Involvering af eksterne parter eller leverandører.

6. Tidsplan

   • Overordnede milepæle og deadlines.
   • Afhængigheder mellem testfaser og andre projektaktiviteter.

7. Miljøer og værktøjer

   • Oversigt over testmiljøer (hardware, software, netværk).
   • Liste over testværktøjer og deres anvendelse.

8. Risici og afhængigheder

   • Identificering og vurdering af risici.
   • Afbødningsplaner for kritiske risici.

9. Testdata

   • Planlægning af testdata (syntetisk eller produktionsdata).
   • Sikring af dataenes sikkerhed og anonymitet.

10. Monitorering og rapportering

    • Hvordan teststatus rapporteres til interessenter.
    • Testmetrikker, der bruges til at spore fremdrift.

11. Afslutningskriterier

    • Definition af, hvornår testen er færdig.
    • Leverancer, der skal leveres ved afslutningen af testen.

12. Godkendelse

    • Liste over interessenter, der skal godkende planen.

3. Følg en proces for udarbejdelse

Trin-for-trin proces

1. Forberedelse

   • Indsamling af kravspecifikationer, design og projektmål.
   • Konsultation med relevante interessenter.

2. Identificering af testmål

   • Definér mål for kvalitet og funktionalitet.
   • Forankr mål hos projektteamet.

3. Udarbejdelse af teststrategien

   • Fastlæg testtilgangen og metodikker.
   • Vurder behovet for automatisering eller manuel test.

4. Planlægning af ressourcer

   • Identificer testteamets størrelse og kompetencer.
   • Fastlæg nødvendige værktøjer og miljøer.

5. Risikovurdering

   • Udfør en analyse baseret på produkt- og projektfaktorer.
   • Identificér risikoområder, og prioriter testindsatsen.

6. Udarbejdelse af planen

   • Brug ISO 29119-skabelonen som reference.
   • Tilpas planen til projektets behov.

7. Godkendelse og kommunikation

   • Få planen godkendt af projektledelse og andre interessenter.
   • Kommuniker planen til testteamet.

8. Kontinuerlig opdatering

   • Revider planen regelmæssigt baseret på projektændringer.
   • Dokumentér alle ændringer og informér interessenter.

4. Brug relevante værktøjer

• Teststyringsværktøjer: TestRail, Zephyr, qTest.
• Risikoanalyseværktøjer: Excel-skabeloner, Monte Carlo-simulering.
• Dokumentationsværktøjer: Confluence, MS Word, eller specialiserede værktøjer til ISO 29119-dokumenter.

5. Best Practices og faldgruber

Best Practices

• Involver interessenter tidligt i processen.
• Prioritér test baseret på risici.
• Dokumentér klare acceptkriterier.

Faldgruber

• Undladelse af at opdatere testplanen undervejs.
• For ambitiøse eller urealistiske planer.
• Mangel på involvering fra udviklings- eller forretningsholdet.

Denne guide sikrer, at din testplan er omfattende og i overensstemmelse med de standarder, du arbejder efter. 

 

Beslutningstabeltest - En systematisk og struktureret testteknik

 

Beslutningstabeltest er en kraftfuld teknik, der strukturerer komplekse beslutningsprocesser og sikrer, at alle tænkelige kombinationer af input og deres tilhørende resultater bliver testet. Denne teknik er særlig nyttig i systemer, hvor flere regler eller betingelser interagerer.

Hvad er en beslutningstabel?

En beslutningstabel er et tabellarisk værktøj, der visualiserer forskellige betingelser (input) og handlinger (output). Tabellen består typisk af:

• Betingelser: Forskellige inputbetingelser, der påvirker resultatet.
• Handlinger: Mulige resultater eller systemreaktioner.
• Regler: Kombinationer af betingelser og deres tilsvarende handlinger.

Eksempel på komplet beslutningstabel

Her er vist en komplet beslutningstabel på generisk form med 3 betingelser:

Fremgangsmåde for den komplette beslutningstabel

En komplet beslutningstabel dækker alle mulige kombinationer af betingelser. Følg disse trin:

1. Identificer betingelser og handlinger:

   • Kortlæg alle betingelser, der påvirker systemets adfærd.
   • Definér de handlinger, systemet kan udføre.

2. Opsæt betingelseskombinationer:

   • For n betingelser med to mulige værdier (ja/nej), vil der være $2^n$ kombinationer.
   • Eksempel: For tre betingelser bliver kombinationerne $2^3 = 8$.

3. Tildel handlinger:

   • For hver kombination af betingelser tildeles en specifik handling.

4. Validér og verificér:

   • Gennemgå tabellen for at sikre, at alle regler er korrekte, og der ikke er manglende kombinationer.

Fordele

• Komplet dækning: Alle tænkelige kombinationer testes.
• Systematisk tilgang: Reducerer risikoen for udeladelser.

Ulemper

• Kan blive uoverskuelig for systemer med mange betingelser, da antallet af regler eksploderer eksponentielt.

Fremgangsmåde for den komprimerede beslutningstabel

Den komprimerede beslutningstabel reducerer antallet af regler ved at fjerne redundante kombinationer og fokusere på væsentlige testtilfælde.

1. Identificer grupper af lignende regler:

   • Kombiner regler med samme handling, hvor betingelserne er ens eller ikke væsentligt påvirker resultatet.

2. Fjern overflødige regler:

   • Undgå kombinationer, hvor betingelserne ikke ændrer output.

3. Dokumentér beslutningerne:

   • Notér, hvorfor visse kombinationer er udeladt, for sporbarhed.

Fordele

• Effektivitet: Mindsker antallet af testtilfælde.
• Tidsbesparelse: Reducerer testindsats uden at gå på kompromis med dækning.

Ulemper

• Risiko for at overse vigtige kombinationer, hvis komprimeringen ikke udføres korrekt.

Værktøjer til beslutningstabeltest

Flere værktøjer kan hjælpe med at oprette og vedligeholde beslutningstabeller:

• Excel eller Google Sheets: Simpelt og fleksibelt værktøj til små tabeller.
• Specialiserede værktøjer: Fx Decision Table Testing Tools (DTT) eller business rule management systemer.

Styrker

• Grundig validering: Sikrer dækning af komplekse regelsæt.
• Høj kvalitet: Reducerer risikoen for fejl ved at teste alle kritiske kombinationer.
• Sporbarhed: Hjælper med at kortlægge krav til test.

Fælder at undgå

1. Overkomplicering:

   • Forsøg ikke at inkludere for mange detaljer i én tabel. Overvej at opdele systemet i mindre dele. En fornuftig tommerfingerregel er maksimalt 5 betingelser.
     

2. Mangelfuld dokumentation:

   • Sørg for at forklare, hvorfor visse kombinationer er valgt eller udeladt.

3. Uklarhed i krav:

   • En ufuldstændig forståelse af krav kan føre til fejl i beslutningstabellen.

Konklusion

Beslutningstabeltest er en essentiel teknik for enhver senior testanalytiker, især når det handler om at teste komplekse systemer med flere betingelser og regler. Ved at forstå forskellen mellem den komplette og den komprimerede tilgang kan du balancere mellem grundighed og effektivitet.

 

Boganmeldelse - Facilitering i Agile Projektteams

Forfattere: Pil Sally Bach - Daniel Ladefoged - Morten Flørness Kerrn-Jespersen
Forlag: Djøf Forlag
Udgivelsesår: 2024

 

Agile arbejdsmetoder har i mange organisationer transformeret samarbejdsdynamikken og tilgangen til projektstyring. Bogen Facilitering i agile projektteams fra Djøf Forlag tilbyder en dybdegående og praktisk vejledning i at facilitere agile teams, hvilket gør den til et must-read for både erfarne og nye aktører i det agile univers.

Styrker ved bogen

1. Klar struktur og praktisk relevans
Bogen er struktureret på en måde, der gør den let at følge, selv for læsere, der er nye i agile sammenhænge. Kapitlerne er opdelt i overskuelige emner som faciliteringsprincipper, værktøjer og praktiske cases, hvilket sikrer en god balance mellem teori og praksis.

2. Fokus på faciliteringsrollen
En af bogens store styrker er dens fokus på, hvordan man som facilitator skaber et trygt og produktivt miljø, hvor alle teammedlemmer kan bidrage. Den går i dybden med vigtige emner som aktiv lytning, konfliktløsning og fremme af engagement – færdigheder, der er altafgørende for succes i agile teams.

3. Inspirerende eksempler og cases
Bogen inkluderer en række virkelighedsnære eksempler og cases, der viser, hvordan facilitering kan håndtere typiske udfordringer i agile teams. Eksemplerne gør bogen levende og giver konkrete ideer til, hvordan man kan implementere dens råd.

4. Teoretisk forankring
Selvom bogen er praktisk orienteret, hviler den på et solidt teoretisk fundament. Referencer til klassiske og moderne teorier inden for facilitering og teamdynamik gør den troværdig og fagligt funderet.

Forbedringsområder

1. Mere om facilitering af virtuelle teams
Selvom bogen giver gode råd om generel facilitering, kunne der være mere fokus på at arbejde med virtuelle eller hybride teams, som er blevet stadig mere relevante i mange organisationer.

2. Dybdegående værktøjsbeskrivelser
Mens værktøjer som retrospektiver og teamøvelser bliver nævnt, kunne nogle læsere måske savne mere detaljerede trin-for-trin-beskrivelser af disse værktøjer.

Samlet vurdering

Facilitering i agile projektteams er en værdifuld bog for enhver, der ønsker at styrke deres faciliteringskompetencer i et agilt setup. Den kombinerer teori, praksis og inspiration på en måde, der gør den både lærerig og anvendelig. For ledere, Scrum Masters, Product Owners og teammedlemmer, der ønsker at skabe et mere velfungerende samarbejde, er dette en bog, der bør stå på hylden.

Bogen får mine varmeste anbefalinger for dens relevante indhold, klare formidling og inspirerende tilgang til, hvordan facilitering kan være en afgørende faktor for agile teams’ succes.

 

Anvendelse af pareto-analyse i testmanagement - En effektiv tilgang

Pareto-analysen, også kendt som 80/20-reglen, er et værdifuldt værktøj for testmanagers, der arbejder med at identificere og løse problemer inden for softwaretest. Denne metode, opkaldt efter den italienske økonom Vilfredo Pareto, bygger på observationen af, at 80 % af konsekvenserne ofte skyldes 20 % af årsagerne. I dette blogindlæg vil vi udforske Pareto-analysens historiske baggrund, fremgangsmåde, praktiske anvendelser, styrker og svagheder i testledelse.

Historisk baggrund

Vilfredo Pareto introducerede i 1896 sin opdagelse af, at 80 % af Italiens rigdom blev ejet af 20 % af befolkningen. Denne observation blev senere generaliseret til mange andre områder af Joseph Juran (Jurans Quality Handbook), som populariserede reglen inden for kvalitetsstyring. I softwaretest bruges Pareto-princippet ofte til at fokusere på de mest kritiske problemer, hvilket muliggør en effektiv ressourceanvendelse.

Fremgangsmåde

En Pareto-analyse i softwaretest involverer følgende trin:

1. Indsamling af data: Identificer og kvantificer problemer eller fejl, der opstår under testprocessen. Dette kan være antallet af fejl i forskellige moduler, antal fejl pr. udvikler eller hyppigheden af specifikke fejlkategorier.

2. Kategorisering: Grupper problemerne i kategorier, fx funktionelle fejl, ydeevneproblemer, sikkerhedsfejl osv.

3. Sortering: Rangér kategorierne efter deres indvirkning eller hyppighed, så de mest signifikante problemer vises først.

4. Visualisering: Lav et Pareto-diagram, hvor problemmængden vises på y-aksen, mens x-aksen repræsenterer de forskellige kategorier. En kumulativ kurve kan tilføjes for at vise, hvordan de førende kategorier bidrager til den samlede problemmængde.

5. Handling: Fokusér på de vigtigste problemer, som oftest udgør 20 % af kategorierne, men står for 80 % af fejlene.

Praktiske eksempler

Eksempel 1: Identifikation af defektmønstre

Et testteam indsamler data om fejl fundet under systemtest. Efter at have kategoriseret fejlene viser en Pareto-analyse, at 75 % af alle fejl skyldes problemer i kun to moduler. Ved at rette op på disse moduler reduceres det samlede antal fejl betydeligt.

Eksempel 2: Forbedring af testdækning

En organisation analyserer problemer, der er rapporteret i produktionsmiljøet. Analysen viser, at 80 % af fejlene er relateret til manglende testdækning inden for specifikke integrationsscenarier. Fokus på disse områder under regressionstest forbedrer produktkvaliteten markant.

Eksempel 3: Graf

 Styrker

• Fokus på væsentlige problemer: Pareto-analysen sikrer, at ressourcer bruges effektivt ved at fokusere på de mest kritiske områder.
• Visualisering: Pareto-diagrammer giver et klart overblik over problemprioriteter og deres relative betydning.
• Skalerbarhed: Metoden kan anvendes på alt fra små projekter til komplekse systemer.

Svagheder

• Afhængighed af data: Resultaterne er kun så gode som datakvaliteten. Forkerte eller ufuldstændige data kan lede til fejlagtige konklusioner.
• Ignorerer muligvis mindre, men kritiske fejl: Mindre hyppige problemer kan have alvorlige konsekvenser, men overses let i en Pareto-analyse.
• Ikke en løsning i sig selv: Analysen identificerer problemer, men tilbyder ikke en direkte løsning.

Konklusion

Pareto-analysen er et kraftfuldt værktøj for testmanagers til at identificere og prioritere de mest kritiske områder i testprocessen. Ved at fokusere på de 20 % af problemerne, der forårsager 80 % af konsekvenserne, kan teams opnå større effektivitet og bedre kvalitetsstyring. Det er dog vigtigt at supplere analysen med andre metoder for at sikre en omfattende tilgang til softwarekvalitet.

 

Tilstandsovergangstest: En Praktisk Guide til Testere, Testdesignere og Testanalytikere

Introduktion 

Tilstandsovergangstest er en effektiv testteknik, der anvendes til at validere systemadfærd i forhold til skift mellem forskellige tilstande. Denne teknik er særligt nyttig, når systemet eller applikationen fungerer som en state machine med definerede tilstande og overgange. Dette blogindlæg forklarer fremgangsmåden for tilstandsovergangstest, dækningsstrategier, styrker, faldgruber og tilgængelige værktøjer.

Hvad er tilstandsovergangstest?

Tilstandsovergangstest bruges til at verificere, at systemet reagerer korrekt på forskellige input og bevæger sig gennem de definerede tilstande og overgange. Hver tilstand repræsenterer en specifik status for systemet, og hver overgang beskriver, hvordan systemet skifter fra en tilstand til en anden baseret på en given begivenhed eller et input.

Eksempel:

Overvej en simpel kaffemaskine med tre tilstande:

1. Idle (standby).
2. Brewing (brygger).
3. Error (fejl).

Overgange kunne være:

• Fra Idle til Brewing, når en bruger trykker på start-knappen.
• Fra Brewing til Idle, når brygningen er afsluttet.
• Fra hvilken som helst tilstand til Error, hvis der opstår en fejl.

Fremgangsmåde

1. Identificer tilstande og overgange:

   • Kortlæg alle mulige tilstande, systemet kan befinde sig i.
   • Definér alle mulige overgange mellem tilstande, inklusive betingelser og input, der udløser dem.

2. Opret en tilstandstabel eller -diagram:

   • En tilstandstabel viser tilstande som rækker og input som kolonner, hvor hver celle angiver, hvilken tilstand systemet skifter til.
   • Et tilstandsdiagram er en grafisk repræsentation af tilstande og overgange.

3. Definer testcases:

   • Skriv testcases for hver overgang, inklusive gyldige og ugyldige input.
   • Overvej dækning af kanttilfælde og fejlhåndtering.

4. Udfør testen:

   • Brug manuelt eller automatiseret testværktøj til at validere, at systemet skifter korrekt mellem tilstande.

5. Analysér resultaterne:

   • Verificer, om systemet har opfyldt de forventede resultater, og dokumentér eventuelle afvigelser.

Testdækning

Tilstandsovergangstest kan anvende forskellige dækningsstrategier:

• Overgangsdækning: Test alle mulige overgange mindst én gang.
• Tilstandsdækning: Test alle tilstande mindst én gang.
• Sekvensdækning: Test forskellige sekvenser af overgange.
• N-dækning: Test n-antal successive overgange for at sikre korrekt opførsel over tid.

Styrker

• Systematisk tilgang: Sikrer, at alle tilstande og overgange bliver testet.
• Effektiv til komplekse systemer: Velegnet til applikationer med mange tilstande og logik.
• Identificerer skjulte fejl: Afslører fejl, der kun optræder ved specifikke tilstandsskift.

Faldgruber

• Kompleksitet: Tilstandsovergangstest kan blive svær at administrere, hvis antallet af tilstande og overgange er meget stort.
• Ufuldstændige modeller: Hvis tilstandstabellen eller diagrammet er ufuldstændig, kan vigtige scenarier blive overset.
• Tidskrævende: Kræver betydelig tid til at definere og dække alle testscenarier.

Værktøjer til Tilstandsovergangstest

• GraphWalker: Et værktøj til model-baseret test, der understøtter tilstandsovergangsmodeller.
• TestOptimal: En platform til automatisering af tilstandsovergangstest.
• Spec Explorer: Et værktøj fra Microsoft til model-baseret test.
• State Transition Diagram Tools: Forskellige diagramværktøjer som Lucidchart, Visio eller PlantUML til at skabe og analysere tilstandsdiagrammer.

Konklusion

Tilstandsovergangstest er en kraftfuld teknik til at validere systemadfærd, særligt i applikationer, der afhænger af tilstande og overgange. Ved at anvende en systematisk tilgang kan testere, testdesignere og testanalytikere effektivt finde fejl og sikre, at systemet opfører sig korrekt under forskellige betingelser. Selvom teknikken kan være tidskrævende og kompleks, opvejes dette af dens evne til at afsløre kritiske fejl, der ellers kunne blive overset.

 

Testafslutningsrapport - Inspiration baseret på ISTQB og ISO 29119-3

 1. Titelblad

• Indhold:
  • Projekt- eller systemnavn: Angiv det fulde navn og evt. version af det system eller projekt, der testes.
  • Rapportens dato: Dato for udarbejdelse af rapporten.
  • Forfatter(e) og interessenter: Navn(e) på ansvarlige for rapporten samt de vigtigste interessenter (f.eks. projektleder, testleder).

2. Indledning

• Formål med rapporten:
  • Beskriv, hvorfor rapporten udarbejdes (f.eks. som dokumentation for afslutning af testfasen).
• Kontekst for projektet:
  • Kort beskrivelse af systemet eller projektet, herunder hvilke dele der er blevet testet.
  • Hvilke krav og mål testen skulle opfylde.
• Referencer til relevante dokumenter:
  • Testplan.
  • Kravspecifikationer.
  • Risikovurderinger.
  • Tidligere testrapporter eller relaterede dokumenter.

3. Samlet Status for Testaktiviteter

• Oversigt over testaktiviteter:
  • Antal planlagte, gennemførte og resterende tests.
  • Forventet og faktisk tid brugt på test.
• Status på testcases:
  • Fordeling af afsluttede, beståede, fejlede og ikke-udførte testcases.
• Afvigelser fra testplanen:
  • Beskrivelse af afvigelser og årsager (f.eks. uventede tekniske problemer).

4. Testdækning

• Kravdækning:
  • Procentdel af kravene, der er testet og opfyldt.
• Risikoafdækning:
  • Analyse af testens dækning af de identificerede risici.
• Visualisering:
  • Tabeller og grafer, der viser testdækningen.

5. Fejlhåndtering

• Identificerede fejl:
  • Samlet antal fejl.
  • Klassificering efter alvorlighed (kritisk, høj, medium, lav).
• Fejlstatus:
  • Fordeling af fejl i status som åbne, løste, afviste eller udsatte.
• Resterende fejl:
  • Dokumentation af fejl, der ikke er rettet, og deres indflydelse på systemet.

6. Testresultater

• Overordnede resultater:
  • Antal testcases, der bestod eller fejlede.
• Analyse i forhold til acceptkriterier:
  • Hvor godt resultaterne opfylder de opstillede acceptkriterier.
• Anbefalinger:
  • Eventuelle anbefalinger for opfølgende arbejde.

7. Testprocessens Effektivitet

• Evaluering af teststrategien:
  • Hvor godt strategien fungerede i forhold til projektets behov.
• Identificerede forbedringsområder:
  • Forslag til, hvordan fremtidige tests kan forbedres.

8. Konklusion og Anbefalinger

• Overordnet vurdering:
  • Opsummering af, om testens mål blev opnået.
• Udtalelse om systemets frigivelse:
  • Anbefaling om, hvorvidt systemet kan frigives eller ej.
• Videre anbefalinger:
  • Forslag til fremtidige forbedringer eller yderligere tests.

9. Bilag

• Teststatistikker:
  • F.eks. antal tests pr. krav, fejlfrekvens, mv.
• Testlogfiler:
  • Uddrag eller links til detaljerede logfiler.
• Involverede ressourcer:
  • Liste over deltagende teammedlemmer og deres roller.

Eksempler på Visualiseringer og Metrics

• Testfremdrift:
  • Linjediagram, der viser afsluttede tests over tid.
• Fejltyper:
  • Pie-chart over fejl fordelt på kategorier som funktionelle, performance, osv.
• Risikoafdækning:
  • Heatmap, der viser status på risikoområder.

Denne struktur giver et omfattende overblik og sikrer, at rapporten opfylder kravene til dokumentation og kommunikation i henhold til ISTQB og ISO 29119-3.

 

Effektive testmetrikker - Hvorfor og hvordan?

Introduktion til Testmetrikker

I softwaretest er metrikker afgørende for at måle og forbedre testprocessens effektivitet. De giver værdifuld indsigt i testens fremskridt, kvaliteten af det testede produkt og teamets ydeevne. Dette blogindlæg dykker ned i fremgangsmåden for at bruge metrikker effektivt, GQM-metoden (Goal-Question-Metric), eksempler på testmetrikker, deres fordele og faldgruber samt værktøjer, der understøtter deres brug.

Fremgangsmåde til Valg og Brug af Testmetrikker

1. Definer formål og mål: Start med at identificere, hvad du ønsker at opnå med metrikkerne. Eksempler kan være forbedring af testeffektivitet eller reduktion af fejl i produktionen.

2. Involver interessenter: Forstå, hvad der er vigtigt for projektets interessenter, så metrikkerne afspejler deres behov.

3. Fastlæg dataindsamlingsmetoder: Sikr, at dataindsamlingen er automatiseret og pålidelig, hvor det er muligt.

4. Analysér og visualisér: Brug dashboards og rapporter til at gøre data nemme at forstå.

5. Evaluér og forbedr: Justér metrikkerne regelmæssigt baseret på feedback og resultater.

GQM-metoden (Goal-Question-Metric)

GQM-metoden (Goal-Question-Metric) hjælper med at sikre, at metrikker er meningsfulde og fokuserede. Metoden består af tre trin:

1. Mål (Goal): Definer et specifikt mål for testindsatsen. Eksempel: “Forbedre testprocessens effektivitet.”

2. Spørgsmål (Question): Stil spørgsmål, der hjælper med at vurdere, om målet opfyldes. Eksempel: “Hvor mange testcases køres hver dag?”

3. Metrikker (Metric): Identificér målbare indikatorer, der kan besvare spørgsmålene. Eksempel: Antallet af gennemførte testcases pr. dag.

Eksempler på Testmetrikker

Procesrelaterede Metrikker

• Testprogression: Antal gennemførte testcases over tid.
• Fejlretningstid: Tiden fra fejlrapportering til løsning.

Produktrelaterede Metrikker

• Defekttæthed: Antal fejl pr. 1.000 kodelinjer.
• Code Coverage: Procentdel af koden, der er dækket af test.

Team-/Ressourcerelaterede Metrikker

• Testeffektivitet: Fejl opdaget pr. time brugt på test.
• Kapacitetsudnyttelse: Procentdel af teamets tid brugt på produktive testaktiviteter.

Fordele og Faldgruber ved Testmetrikker

Fordele

• Objektiv vurdering: Metrikker giver faktabaseret indsigt i testprocessen.
• Forbedret beslutningstagning: Hjælper ledelsen med at prioritere ressourcer og fokusområder.
• Løbende forbedring: Identificerer områder, der kræver optimering.

Faldgruber

• Vanity Metrics: Fokuser ikke på metrikker, der ser godt ud, men ikke tilfører reel værdi.
• Misforståelse af data: Fejltolkning af metrikker kan føre til forkerte beslutninger.
• Overmæssig afhængighed: For stor afhængighed af metrikker kan underminere faglige vurderinger.

Værktøjer til Testmetrikker

• Teststyringsværktøjer:
  • JIRA, TestRail, Zephyr til planlægning og sporing.
• Analyseværktøjer:
  • Power BI, Tableau eller Excel til rapportering.
• Automatiseringsværktøjer:
  • Selenium, Appium for at integrere metrikdata i realtid.

Praktiske Eksempler

Case: En testleder implementerede GQM-metoden i et projekt og valgte "fejlretningstid" som en metrik. Denne metrik afslørede flaskehalse i fejlhåndteringen, hvilket førte til en 20% reduktion i fejlretningstiden efter procesforbedringer.

Visualisering: Et eksempel kunne være en graf over fejl pr. testfase, der hjælper med at identificere særligt fejlbehæftede områder.

Afslutning og Anbefalinger

Testmetrikker er et kraftfuldt værktøj til at forstå og forbedre testprocessen. Ved at anvende en struktureret tilgang som GQM og kombinere relevante metrikker med effektive værktøjer kan organisationer opnå betydelige forbedringer. Husk dog at bruge metrikkerne med omtanke og altid kombinere dem med faglig vurdering.

Anbefaling: Start med få, men meningsfulde metrikker, og udvid porteføljen efter behov. Visualisér data klart og regelmæssigt, og brug dem som grundlag for kontinuerlige forbedringer.

 

Value Stream Mapping i Agile Teams: En Guide til Forbedret Effektivitet

I agile miljøer handler det om at levere værdi hurtigt og effektivt. Men hvordan sikrer vi, at vores processer ikke spilder tid eller ressourcer? Value Stream Mapping (VSM) er et værktøj, der kan hjælpe med netop dette. Denne artikel dykker ned i, hvad en Value Stream er, formålet med VSM, fremgangsmåden, faldgruber og konkrete eksempler.

Hvad er en Value Stream?

En Value Stream repræsenterer alle de trin, som et produkt eller en service gennemgår for at levere værdi til kunden. Den inkluderer både værdiskabende aktiviteter (som udvikling og test) og ikke-værdiskabende aktiviteter (som ventetid eller unødvendige godkendelser).

Typer af Value Streams:

• Operationelle Value Streams: Fokus på levering af eksisterende produkter eller tjenester.
• Udviklingsmæssige Value Streams: Fokus på at skabe eller forbedre produkter og tjenester.

Formål med Value Stream Mapping

Value Stream Mapping er en visuel teknik til at analysere og optimere processer. Formålene inkluderer:

• Identifikation af spild: Synliggør aktiviteter, der ikke skaber værdi.
• Forbedring af flow: Reducer ventetider og flaskehalse.
• Skabe gennemsigtighed: Hjælp teams med at forstå hele processen.
• Understøtte løbende forbedringer: Fungerer som grundlag for optimering.

Fremgangsmåde for Value Stream Mapping

1. Definér scope og formål:
   - Identificer processen eller produktet, der skal analyseres.
   - Definér start- og slutpunkter.

2. Kortlæg den aktuelle tilstand (Current State):
   - Skitser processen som den er.
   - Notér tid brugt på hver aktivitet (Value-Added Time) og ventetid (Non-Value-Added Time).

3. Analysér spild og flaskehalse:
   - Identificer aktiviteter, der ikke skaber værdi.
   - Brug principper som Lean til at vurdere processens effektivitet.

4. Design den fremtidige tilstand (Future State):
   - Visualisér en optimeret proces med reduceret spild og bedre flow.
   - Inddrag interessenter for at sikre buy-in.

5. Implementér forbedringer:
   - Prioritér handlinger og opret en handlingsplan.
   - Monitorér og evaluer resultaterne.

Faldgruber at undgå

• Overfokus på detaljer: Hold fokus på de vigtigste problemer, der skal løses.
• Ignorering af kultur: Forandringer kan møde modstand, så inddrag teams tidligt.
• Manglende opfølgning: Sikr, at forbedringer implementeres og evalueres.

Konkrete Eksempler

Eksempel 1: Softwareudvikling
I et softwareprojekt blev ventetiden mellem udvikling og test reduceret fra 3 dage til 1 dag ved at automatisere testmiljøopbygning. Det resulterede i kortere lead time og hurtigere feedback.

Eksempel 2: Kundesupport
En organisation brugte VSM til at analysere kundesupportprocesser. Ved at eliminere unødvendige godkendelsestrin blev svartiden reduceret med 40%.

Afslutning

Value Stream Mapping er et effektivt værktøj for agile teams til at forbedre flowet, reducere spild og levere mere værdi til kunden. Ved at anvende denne metode kan teams skabe gennemsigtighed, optimere processer og fremme en kultur af løbende forbedringer. 

Prøv det i dit team og se forskellen!

Vigtigheden af Testdesign - Inspiration

Indledning

Testdesign er en essentiel del af softwareudviklingens livscyklus. Godt testdesign sikrer, at testaktiviteter er målrettede, effektive og omfattende, hvilket bidrager til at identificere og rette fejl tidligt i udviklingsprocessen. I dette blogindlæg vil jeg dykke ned i vigtigheden af testdesign, inklusive input, forudsætninger, testteknikker, styrker, faldgruber og resultater samt dokumentation.

Input til Testdesign

Effektivt testdesign begynder med indsamling af relevante inputdata - kaldet testgrundlag. Disse inkluderer:

• Kravspecifikationer: Forståelse af funktionelle og ikke-funktionelle krav.
• User Stories: Specielt anvendt i det agile setup.
  
• Design- og arkitekturdokumenter: For at identificere kritiske områder af applikationen.
• Tidligere testresultater: For at genkende gentagne fejlmønstre.
• Projektplaner: For at planlægge testfaser i henhold til udviklingscyklussen.

Forudsætninger for Testdesign

Forudsætningerne dækker de nødvendige betingelser for at udføre testene korrekt:

• Miljøopsætning: Sikring af et testmiljø, der spejler produktionsmiljøet.
• Tilgængelige ressourcer: Testere, testdata, værktøjer og tidsplaner.
• Adgang til systemer: Påkrævet adgang og tilladelser til at teste de relevante systemkomponenter.

Testteknikker

Valget af testteknikker kan påvirke effektiviteten og dækningen af testene. Nogle af de vigtigste teknikker er:

• Black-box test: Tester applikationens funktionalitet uden at kende dens interne struktur. Eksempler på black-box testteknikker er: Ækvivalenspartitionering, grænseværdianalyse, beslutningstabeltest, tilstandsovergangstest, parvis test, klassifikationstræ, usecase-baseret test, domæneanalyse, test af user story etc.
  
• White-box test: Tester applikationens indre struktur og koder. Eksempler på white-box testteknikker er: Instruktionstest, beslutningstest, betingelsestest, bestemmende betingelsestest (MC/DC), multipel betingelsestest, stitest etc.
  
• Regressionstests: Sikrer, at nye ændringer ikke har påvirket eksisterende funktionalitet negativt. Er som sådan ikke en testteknik, men bør altid klart overvejes via en effektanalyse.
  
• Erfaringsbaseret test: Herunder Exploratory test, som er en fleksibel og kreativ testmetode, hvor testere udforsker applikationen uden foruddefinerede tests.

Styrker og Faldgruber

Godt testdesign har mange styrker, men der er også faldgruber, man skal være opmærksom på:

• Styrker:
•  Øget dækningsgrad af testen.
•  Tidlig identifikation af fejl.
•  Forbedret kvalitet af slutproduktet.
• Faldgruber:
•  Overfokusering på testdokumentation frem for faktisk testafvikling.
•  Mangel på kontinuerlig forbedring af testdesignprocessen.
•  For lidt samarbejde mellem testere og udviklere.

Resultater og Dokumentation

Dokumentation er en nøglekomponent i testdesign, da den hjælper med at spore fremdrift og identificere forbedringsområder. Vigtige dokumenter inkluderer:

• Testcases: Detaljerede beskrivelser af individuelle tests, der skal udføres.
• Teststatusrapporter: Rapporter over testdesignfremdriften og fejl, der er fundet.
• Målinger og metrikker: Data om testdækning, fejltyper og deres sværhedsgrad.

Konklusion

Et veldefineret testdesign er fundamentet for at levere software af høj kvalitet. Ved at sikre, at der er klare input, relevante forudsætninger, anvendelse af passende testteknikker, og fokus på styrker og faldgruber, kan testteamet effektivt identificere og rette fejl. Dokumentation spiller en central rolle i at spore og forbedre testprocessen løbende. Ved at følge disse principper kan vi sikre, at vores testaktiviteter er både målrettede og effektive.

 

Modelbaseret test - Lidt Inspiration

Introduktion til Modelbaseret Test

Modelbaseret test (MBT) er en metode, der bruger modeller til at beskrive systemets forventede adfærd som basis for testdesign og -udførelse. Det er en effektiv tilgang, der kan forbedre testkvaliteten og reducere tidsforbruget. I denne blog vil vi gennemgå, hvad MBT indebærer, hvordan det kan implementeres, samt fordele og faldgruber ved metoden.

Hvad er Modelbaseret Test?

MBT indebærer brugen af modeller, typisk i form af diagrammer eller matematiske repræsentationer, til at generere testcases. Modellen repræsenterer:

• Funktionalitet (use cases, aktivitetsdiagrammer)
• Systemets tilstande (state machines)
• Beslutninger og regler (decision tables)

Testcases genereres automatisk eller semi-automatisk fra disse modeller og sikrer dermed en systematisk og omfattende dækning.

Fremgangsmåde

1. Opret en model: Byg en model, der præcist beskriver systemets forventede adfærd. Brug værktøjer som Unified Modeling Language (UML), State Transition Diagrams eller andre notationer.
2. Generér testcases: Anvend værktøjer til at skabe testcases baseret på modellen.
3. Implementér og udfør tests: Testcases udføres manuelt eller automatiseret.
4. Analyser og justér: Gennemgå resultaterne og opdater modellen eller testcases efter behov.

Eksempler på Anvendelse

• Bankapplikation: MBT bruges til at teste login-procedurer, pengeoverførsler og transaktionshistorik ved hjælp af state diagrams.
• Medicinsk udstyr: MBT sikrer omfattende test af sikkerhedskritiske funktioner gennem modeller baseret på regulatoriske krav.

Værktøjer til Modelbaseret Test

Der findes flere værktøjer, der kan hjælpe med MBT:

• TOSCA MBT: Integreret med Tricentis-platformen og fokuseret på automatiseret testcase-generering.
• Conformiq: Specialiseret i modellering og testcase-automatisering.
• Spec Explorer: Et værktøj fra Microsoft til state machine-baseret test.
• GraphWalker: Open source-løsning til at arbejde med grafer og generere testcases.

Fordele ved Modelbaseret Test

• Automatisering: Reducerer manuelt arbejde ved at generere testcases automatisk.
• Omfattende testdækning: Modellen sikrer, at alle tænkelige scenarier og systemtilstande dækkes.
• Forbedret kommunikation: Modeller fungerer som en fælles referenceramme mellem udviklere, testere og forretningsfolk.
• Hurtigere ændringstilpasning: Ændringer i krav kan nemt implementeres i modellen, hvilket gør tests mere fleksible.

Faldgruber ved Modelbaseret Test

• Indlæringskurve: Det kan være udfordrende at lære at bygge og bruge modeller effektivt.
• Afhængighed af modellen: Dårligt designede modeller fører til ineffektive tests.
• Værktøjskompleksitet: Nogle MBT-værktøjer kan være dyre og kræver specialkompetencer.

Konklusion

Modelbaseret test er en kraftfuld metode, der kan forvandle måden, hvorpå software testes. Ved at bruge MBT kan du spare tid, forbedre dækningen og minimere fejl. Dog kræver det en investering i viden og værktøjer for at høste fordelene fuldt ud.

Hvis du endnu ikke har prøvet MBT, kan det være tid til at udforske, hvordan denne metode kan gavne din organisation.

 

Prioritering af testindsatsen - Inspiration

Som senior testmanager er prioritering af testindsatsen afgørende for at sikre, at de vigtigste aspekter af systemet testes først, og at ressourcerne anvendes optimalt. Her er en oversigt over forskellige metoder til testprioritering:

1. Risikobaseret test (Risk-Based Testing - RBT)

Beskrivelse:
Prioriterer testindsatsen baseret på risikoen ved fejl i forskellige dele af systemet. Risiko vurderes typisk ud fra sandsynlighed og konsekvens.

Tilgang:

• Identificer risici ved hjælp af workshops eller analyser.
• Vurder sandsynligheden for fejl og deres konsekvenser (fx som lav, middel eller høj).
• Prioriter testcases, der afdækker de højrisikoområder først.

Fordele:

• Fokus på kritiske områder.
• Reducerer sandsynligheden for alvorlige fejl i produktion.

Eksempel:
En bankapplikation vil typisk prioritere test af transaktionshåndtering (høj risiko) over farvetemaer i brugergrænsefladen (lav risiko).

2. Fordelsbaseret test

Beskrivelse:
Testindsatsen prioriteres baseret på, hvor stor forretningsværdi de forskellige funktionaliteter har.

Tilgang:

• Samarbejd med interessenter for at identificere, hvilke funktioner der skaber mest værdi.
• Prioriter test af funktioner, der understøtter kerneforretningsprocesser.

Fordele:

• Direkte sammenhæng mellem test og forretningsmål.
• Effektiv ressourceudnyttelse.

Eksempel:
I en webshop prioriteres tests af betalingsgateway og søgefunktion (høj værdi) frem for mindre kritiske funktioner som anbefalede produkter.

3. MoSCoW-metoden

Beskrivelse:
En enkel prioriteringsteknik, der inddeler krav og testcases i fire kategorier:

• Must Have: Kritisk funktionalitet, der skal virke.
• Should Have: Vigtige funktioner, men ikke kritiske.
• Could Have: Nice-to-have funktioner.
• Won’t Have: Funktioner, der ikke testes nu.

Fordele:

• Nem at anvende og forklare.
• Giver hurtig overblik over, hvad der er vigtigst.

Eksempel:
I et nyt HR-system kan Must Have være at kunne tilføje medarbejdere, mens Could Have kan være en automatisk fødselsdagspåmindelse.

4. Kundefokuseret testprioritering

Beskrivelse:
Fokus på at teste de funktioner, som brugerne vil interagere mest med, baseret på brugeradfærd eller feedback.

Tilgang:

• Indsaml data om brugeradfærd via analyser eller interviews.
• Prioriter funktioner med høj brugerfrekvens eller høj kundetilfredshed.

Fordele:

• Giver et brugercentreret perspektiv på testindsatsen.
• Øger sandsynligheden for positiv brugeroplevelse.

Eksempel:
En streamingtjeneste kan prioritere tests af afspilningskvalitet og søgefunktion frem for mindre brugte features som profiltilpasning.

5. Defektbaseret prioritering

Beskrivelse:
Tidligere defekter bruges som grundlag for at prioritere test af områder, der historisk har haft flest fejl.

Tilgang:

• Analyser defektrapporter fra tidligere releases.
• Prioriter test af områder med høj fejlrate eller kompleksitet.

Fordele:

• Lærer af tidligere erfaringer.
• Målrettet indsats mod problemområder.

Eksempel:
Hvis rapportering i et ERP-system tidligere har haft mange fejl, prioriteres tests af rapportgenerering i næste release.

6. Testefasens afhængigheder og kompleksitet

Beskrivelse:
Komplekse og afhængige funktioner prioriteres højere, da fejl her ofte kan påvirke mange andre funktioner.

Tilgang:

• Kortlæg afhængigheder mellem systemkomponenter.
• Prioriter tests af kernekomponenter eller funktioner med mange afhængigheder.

Fordele:

• Forebygger kaskadefejl.
• Øger systemstabilitet.

Eksempel:
I et softwareprojekt prioriteres tests af API’er og integrationspunkter før frontend-funktioner.

Ved at kombinere flere af disse metoder kan du sikre en effektiv og strategisk tilgang til testprioritering, der er tilpasset projektets behov og kontekst.