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!