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.

 

Teststatusrapport - Inspiration, indhold og struktur

En teststatusrapport baseret på ISTQB-rammen og ISO 29119-standarderne bør være klar, præcis og struktureret for at give interessenter et godt overblik over testforløbet og dets resultater. Her er inspiration til, hvordan en sådan rapport kan opbygges:

1. Introduktion

• Formål med rapporten: Angiv, hvorfor rapporten udarbejdes (f.eks. for at give status på testaktiviteter, fremdrift, og eventuelle risici).
• Målgruppe: Beskriv, hvem rapporten henvender sig til (f.eks. projektledere, udviklingsteam, forretningsansvarlige).
• Reference til standarder: Nævn, at rapporten er baseret på ISTQB-principper og ISO 29119-krav.

2. Testmål og omfang

• Projektmål: Kort beskrivelse af de overordnede projektmål.
• Testomfang: Angiv, hvad der er inkluderet og ekskluderet fra testforløbet.
• Testniveau: Angiv niveauet for testen (unit test, integrationstest, systemtest, accepttest).

3. Statusoversigt

3.1 Testaktiviteter

• Oversigt over de udførte og planlagte testaktiviteter.
• Brug visuelle elementer som grafer eller Gantt-diagrammer for at vise fremdrift.

3.2 Testfremdrift

• Antal udførte testcases i forhold til det samlede antal.
• Angiv resultater (bestået/ikke-bestået/ikke udført).
• Brug en tabel som denne:

Kategori	Antal	Procent
Planlagte testcases	100	100%
Udførte testcases	80	80%
Beståede testcases	70	70%

4. Kvalitet og fejl

• Fundne defekter: Oversigt over rapporterede fejl med prioritering (kritisk, høj, medium, lav).
• Defektdiagram: Visualisering af fejl fordelt på kategorier eller områder.

Eksempel:

Prioritet	Antal åbne fejl	Antal lukkede fejl
Kritisk	2	3
Høj	5	10
Medium	8	20
Lav	10	15

5. Risici og problemer

• Identificerede risici: Liste over risici med vurdering og afbødningstiltag.
• Åbne problemer: Aktuelle problemer, der påvirker testforløbet.

Eksempel på risikotabel:

Risiko	Sandsynlighed	Indvirkning	Tiltag
Forsinket leverance	Høj	Høj	Eskalere til projektleder
Utilstrækkelig testdata	Medium	Høj	Generere testdata internt

6. Afvigelser

• Afvigelser fra planen: Beskriv ændringer i tidsplan, omfang eller ressourcer.
• Årsager til afvigelser: Forklar, hvorfor ændringerne er nødvendige.

7. Konklusion og næste skridt

• Status: Samlet vurdering af testforløbet (f.eks. "Testen er 80% gennemført, og kritiske fejl er håndteret").
• Anbefalinger: Eventuelle anbefalinger baseret på testresultaterne.
• Næste skridt: Hvad skal ske fremadrettet (f.eks. yderligere test eller beslutninger om go/no-go).

8. Bilag

• Testoversigt: Liste over udførte testcases.
• Defektrapport: Detaljeret oversigt over fejl.
• Logfiler og rapporter: Eventuelle relevante dokumenter.

God fornøjelse med din rapportering.

Hvem er jeg ifølge ChatGPT?

Ole Chr. Hansen is a senior figure in the Danish software testing and quality assurance community, affiliated with Q Nation, a company specializing in software testing and ISTQB certification courses. Hansen is one of Denmark's leading experts in this field, holding the highest level of ISTQB certification in the country, particularly recognized for his expertise in improving test processes.

At Q Nation, he plays a central role as a Quality Coach, teaching a wide range of courses aimed at improving testing methodologies and processes, such as risk-based testing, exploratory testing, and other technical approaches. Hansen is also an active speaker and instructor at various events and webinars related to software testing, and he contributes to the development of testing frameworks and standards in both public and private sectors.

Performancetest - Overvejelser

1. Identifikation af kritiske funktioner og processer

• Vælg nøglefunktioner: Identificer de mest kritiske funktioner i applikationen, både dem der er standard, og dem der er tilrettet. Fokuser især på integrationerne, da de kan være flaskehalse i systemet.
• Transaktionsvolumen: Vurder, hvilke operationer der typisk vil blive udført ofte, og hvilken belastning de kan generere.

2. Miljø og infrastruktur

• Testmiljøet: Sørg for, at testmiljøet afspejler produktionsmiljøet så nøjagtigt som muligt, især med hensyn til netværkskonfigurationer, servere og databaseindstillinger.
• Skalerbarhed og cloud: Hvis applikationen er hostet i en cloud-løsning, skal du overveje skalerbarheden, og hvordan ressourcer dynamisk kan justeres.

3. Integrationernes påvirkning

• Tredjeparts integrationer: Test, hvordan eksterne systemer påvirker performance. Tredjepartsintegrationer kan tilføje latenstid, og det er vigtigt at måle, hvordan disse påvirker applikationen.
• Datahåndtering og synkronisering: Vurder, hvordan data synkroniseres mellem systemerne, og om der er tidskritiske processer, der kan påvirke performance.

4. Belastningstyper

• Loadtest: Test systemet under en realistisk arbejdsbyrde for at se, hvordan det klarer sig under normale driftsforhold.
• Stresstest: Belast systemet over det forventede maksimum for at identificere, hvornår og hvordan det begynder at fejle.
• Soaktest: Kør systemet i længere tid under vedvarende belastning for at opdage eventuelle problemer som memory leaks eller ydeevnedegeneration over tid.

5. Respons- og gennemløbstider

• Response time: Overvej acceptkriterier for svartider og performance. Hvor lang tid må det tage for brugerne at få et svar på kritiske operationer?
• Throughput: Vurder hvor mange transaktioner eller handlinger systemet kan håndtere pr. sekund eller minut uden at forringe ydeevnen.

6. Brugerbelastning og simuleringer

• Brugsmønstre: Analyser hvordan forskellige brugertyper anvender systemet, og skab testscenarier baseret på realistiske brugermønstre.
• Simulering af mange brugere: Brug værktøjer som JMeter eller LoadRunner til at simulere flere samtidige brugere og interaktioner med systemet.

7. Værktøjer til performancetest

• Værktøjer som Apache JMeter, LoadRunner og Gatling kan være nyttige til at udføre performancetest. Vælg det værktøj, der bedst matcher dine behov i forhold til integrationer og brugsmønstre.

8. Analyser af flaskehalse

• Profileringsværktøjer: Brug profileringsteknikker og værktøjer som Dynatrace eller New Relic for at overvåge systemets adfærd i realtid og identificere flaskehalse.
• Databaseoptimering: Fokusér på databaseydelse, især hvis mange data læses eller skrives under brug. Indeksering, caching og query-optimering kan være afgørende.

9. Risikovurdering og fallback-strategier

• Fejlscenarier: Simulér fejlsituationer, såsom timeout på integrationer eller ressourcemangel, og vurder, hvordan systemet håndterer dem.
• Skalerbarhed og fejltolerance: Overvej, hvordan systemet kan skaleres horisontalt eller vertikalt i tilfælde af øget brugsmængde, og hvilke failover-strategier der kan implementeres.

10. Krav og SLA'er (Service Level Agreements)

• Definerede performance-mål: Aftal klare krav til svartider, oppetid og andre performance-mål i samarbejde med forretningen.
• Overholdelse af SLA'er: Sørg for, at testene afspejler de SLA'er, der er fastlagt for applikationen, især i forhold til svartider og tilgængelighed under spidsbelastninger.

Sammenfatning

Du skal tænke på både den tekniske infrastruktur, hvordan brugerne interagerer med systemet, og hvordan du kan simulere realistiske belastningsscenarier. Husk at inkludere både normal drift og stress-situationer, samt at forberede på fejlhåndtering og failover-mekanismer.

 

Grænseværdianalyse - En effektiv testteknik

Introduktion

I softwaretest er grænseværdianalyse (Boundary Value Analysis, BVA) en af de mest udbredte og effektive testteknikker. Denne metode fokuserer på at identificere fejl, der opstår ved grænserne af input- eller outputområder. Mange fejl manifesterer sig netop ved disse grænser, og derfor kan teknikken hjælpe med at opdage kritiske problemer tidligt i udviklingsforløbet. I dette blogindlæg vil jeg udforske fremgangsmåden for grænseværdianalyse, give praktiske eksempler, diskutere relevante værktøjer samt fremhæve fordelene og faldgruberne ved teknikken.

Fremgangsmåde

Grænseværdianalyse handler om at finde og teste de værdier, der ligger ved eller tæt på grænserne af et gyldigt inputområde. Her er en trinvis tilgang til at udføre BVA:

1. Identificer kravene
   Start med at forstå systemets krav og finde de specifikke intervaller for input- og outputdata.

2. Definer grænserne
   For hver parameter defineres de laveste og højeste gyldige værdier samt værdier lige udenfor disse grænser (f.eks. minimum - 1, maksimum + 1).

3. Udvikl testcases
   Opret testcases, der dækker:

   • Laveste gyldige værdi.
   • Laveste ugyldige værdi.
   • Højeste gyldige værdi.
   • Højeste ugyldige værdi.

4. Kør testcases
   Test værdierne og analyser systemets adfærd.

5. Evaluer resultaterne
   Sammenlign resultaterne med de forventede outputs for at opdage fejl.

Eksempler

Simpelt eksempel: Alder

Et system accepterer en alder mellem 18 og 65 år.
De relevante grænser er:

• Laveste gyldige værdi: 18.
• Højeste gyldige værdi: 65.
• Laveste ugyldige værdi: 17.
• Højeste ugyldige værdi: 66.

Testcases:

1. Input: 18 (skal være gyldig).
2. Input: 17 (skal være ugyldig).
3. Input: 65 (skal være gyldig).
4. Input: 66 (skal være ugyldig).

Kompleks eksempel: Betalingssystem

Et online betalingssystem accepterer beløb mellem 1 og 10.000 DKK.
Grænser:

• Laveste gyldige: 1.
• Højeste gyldige: 10.000.
• Laveste ugyldige: 0.
• Højeste ugyldige: 10.001.

Testcases:

1. Input: 1 DKK (gyldig).
2. Input: 0 DKK (ugyldig).
3. Input: 10.000 DKK (gyldig).
4. Input: 10.001 DKK (ugyldig).

Værktøjer

Grænseværdianalyse kan udføres manuelt eller med hjælp fra værktøjer. Her er nogle nyttige værktøjer:

1. Datagenereringsværktøjer

   • Faker: Til at generere testdata med specifikke værdier.
   • Boundary Scanner: Automatiseret identifikation af grænseværdier.
   
   

Fordele

1. Effektiv fejlfinding
   Grænseværdianalyse fokuserer på kritiske områder, hvor fejl sandsynligvis opstår.

2. Mindre testindsats
   Et relativt lille antal testcases kan dække store inputområder.

3. Struktureret tilgang
   Hjælper med at standardisere testprocessen og reducere oversete fejl.

Faldgruber

1. Overser midterområder
   Teknikken tester primært ved grænserne og kan overse fejl i midterområderne.

2. Afhænger af kravkvalitet
   Uklare eller manglende krav kan føre til forkert identificerede grænser.

3. Kan virke overfladisk
   Hvis ikke kombineret med andre testteknikker, kan BVA give en falsk følelse af fuldstændig dækning.

Konklusion

Grænseværdianalyse er en uvurderlig teknik for testanalytikere, når det kommer til at identificere fejl på en effektiv måde. Ved at kombinere den med andre teknikker og ved at bruge passende værktøjer kan man opnå en solid testdækning. Hvis du ikke allerede bruger grænseværdianalyse, er det værd at prøve det i dit næste projekt.

 

Ækvivalenspartitionering - En grundlæggende testteknik

1. Introduktion

Ækvivalenspartitionering er en grundlæggende testteknik, der bruges til at reducere testomfanget uden at kompromittere kvaliteten. Den fungerer ved at opdele inputdata i grupper (ækvivalensklasser), hvor hvert medlem af en klasse forventes at opføre sig ens. Dette betyder, at du kan teste én repræsentant fra hver klasse i stedet for at teste alle mulige inputværdier.

For eksempel: Forestil dig en applikation, der kun accepterer brugeralder mellem 18 og 65 år. I stedet for at teste alle aldre fra 18 til 65, kan du opdele input i klasser som:

• Gyldige værdier: 18-65
• Ugyldige værdier: Under 18 og over 65

Denne simple opdeling kan reducere arbejdet markant og sikre, at testen stadig er dækkende.

2. Teori og Fremgangsmåde

Ækvivalenspartitionering bygger på princippet om, at data kan organiseres i klasser, hvor én testværdi repræsenterer en hel klasse. Her er trinene til at udføre teknikken:

1. Identificér inputområder
   Bestem de mulige inputområder for det system eller den funktion, der skal testes.

2. Opdel områderne i klasser
   Del input i ækvivalente klasser. Disse klasser kan være:

   • Gyldige klasser (f.eks. 18-65 i alderseksemplet).
   • Ugyldige klasser (f.eks. alder <18 eller >65).

3. Udvælg repræsentative værdier
   Vælg én værdi fra hver klasse. For gyldige klasser kunne du teste med alder 25, og for ugyldige klasser med alder 17 og 70.

3. Praktiske Eksempler

Eksempel 1: Validering af et felt for alder

Forudsætning: Systemet accepterer kun alder mellem 18 og 65.
Ækvivalensklasser:

• Gyldig: 18-65 (repræsentant: 30)
• Ugyldig: <18 (repræsentant: 17)
• Ugyldig: >65 (repræsentant: 70)

Eksempel 2: Beregning af rabatter

Forudsætning: Rabatter baseres på købssummer:

• 0-100: Ingen rabat
• 101-500: 10% rabat
• Over 500: 20% rabat

Ækvivalensklasser:

• Gyldig: 0-100 (repræsentant: 50)
• Gyldig: 101-500 (repræsentant: 300)
• Gyldig: Over 500 (repræsentant: 600)

4. Værktøjer

Der er ikke mange værktøjer der specifikt understøtter brugen af Ækvivalenspartitionering, og jeg anvender ofte Excel til dette formål. Jeg har efterfølgende vist et eksempel på brugen af Excel:

5. Fordele

• Effektivitet: Reducerer antallet af tests uden at kompromittere dækningen.
• Simplicitet: Gør det lettere at identificere essentielle testområder.
• Fleksibilitet: Kan anvendes på alt fra UI-valideringer til komplekse backendberegninger.

6. Faldgruber

• Manglende dækning: Hvis klasserne ikke er korrekt defineret, kan kritiske fejl overses.
• Forenkling: Ved meget komplekse systemer kan det være udfordrende at gruppere input korrekt.
• Tidskrævende opstart: At identificere ækvivalensklasser kan tage tid, især hvis kravene er uklare.

7. Konklusion

Ækvivalenspartitionering er en kraftfuld teknik til at optimere testdækning med færre testtilfælde. Når den anvendes korrekt, sikrer den, at både funktionalitet og valideringer bliver grundigt testet. Kombineret med andre teknikker som boundary value analysis bliver teststrategien endnu stærkere. Prøv at anvende ækvivalenspartitionering i din næste testcyklus – og mærk forskellen!