tirsdag den 13. august 2024

Parvis Test - Teori, Metoder og Praktiske Eksempler

Indledning

Parvis test, også kendt som Pairwise Testing, er en metode anvendt inden for softwaretest for at reducere antallet af testcases og samtidig bevare en høj dækningsgrad af mulige fejl. Denne teknik er baseret på observationen, at de fleste softwarefejl opstår på grund af interaktion mellem to inputparametre snarere end på grund af komplekse interaktioner mellem mange parametre. Dette notat vil give en detaljeret gennemgang af teorien bag parvis test, metoder til implementering, værktøjer til brug, og praktiske eksempler.

1. Baggrund og Teori

1.1 Introduktion til Kombinatorisk Test

Kombinatorisk test er en testmetode, der involverer systematisk valg af kombinationer af inputparametre for at maksimere testdækningen. En komplet kombinationstest, hvor alle mulige kombinationer af inputparametre testes, er ofte urealistisk på grund af det store antal nødvendige testcases. Her kommer parvis test ind som en effektiv måde at reducere omfanget af test uden at kompromittere dækningsgraden væsentligt.

1.2 Parvis Test

Parvis test fokuserer på at teste alle mulige par af inputparametre mindst én gang. Dette betyder, at i stedet for at teste alle mulige kombinationer, vælger man de testcases, hvor hvert par af inputparametre bliver dækket. Denne tilgang er baseret på følgende observationer:

  • De fleste fejl opstår på grund af interaktioner mellem to parametre.
  • Når et par af parametre fejler sammen, vil de sandsynligvis også fejle, hvis de testes i andre kombinationer.

Ved at fokusere på par af parametre reduceres antallet af testcases betydeligt, samtidig med at man stadig kan opdage de fleste fejl, der skyldes parametervariationer.

2. Parvis Testmetoder

2.1 Parameteranalyse

Før parvis test kan udføres, skal de relevante inputparametre identificeres. Dette indebærer:

  • Identifikation af parametre: Alle relevante inputparametre, der påvirker systemets opførsel, skal identificeres.
  • Fastlæggelse af værdier: Hver parameter skal have et sæt værdier, som den kan antage. Disse værdier bør dække alle relevante scenarier, inklusive grænseværdier.

2.2 Testmatricer og Kombinatorisk Dækning

Når parametrene og deres værdier er fastlagt, kan en testmatrice oprettes. Denne matrice indeholder en liste over testcases, hvor hver række repræsenterer en unik kombination af parameterværdier. Parvis test sikrer, at alle par af parametre (og deres respektive værdier) er repræsenteret mindst én gang i testmatricen.

2.3 Algoritmiske Tilgange

Flere algoritmer kan bruges til at generere parvise testcases:

  • Ortogonal Array (OA): OA er en matematisk metode, der anvendes til at skabe en minimal mængde testcases, der dækker alle par af inputparametre. Denne metode sikrer fuld parvis dækning med det mindste antal testcases.
  • Greedy Algoritme: En iterativ tilgang, hvor testcases genereres ved at tilføje nye kombinationer, der dækker så mange utestede par som muligt i hver iteration.
  • Heuristiske Metoder: Disse metoder bruger heuristikker til at finde en god løsning på problemet, som ikke nødvendigvis er optimal, men som reducerer antallet af testcases væsentligt.

3. Implementering og Værktøjer

3.1 Praktisk Implementering

Implementeringen af parvis test kræver typisk følgende trin:

  1. Definere parametre og deres værdier: Dette trin involverer at identificere alle relevante inputparametre og definere deres mulige værdier.
  2. Generere testcases: Brug af algoritmer eller værktøjer til at generere en testmatrice, der dækker alle par af parameterværdier.
  3. Afvikling af test: Testmatricen bruges til at afvikletestcases, hvor hver kombination af par parametre testes.
  4. Analysering af resultater: Testresultaterne analyseres for at identificere fejl forårsaget af parametervariationer.

3.2 Værktøjer til Parvis Test

Der findes flere værktøjer, der kan hjælpe med at implementere parvis test:

  • PICT (Pairwise Independent Combinatorial Testing): Et værktøj fra Microsoft, der automatiserer genereringen af parvis testmatricer.
  • TestersDesk.com: Et online værktøj, der tilbyder parvis test og andre kombinatoriske testmetoder.
  • Hexawise: Et avanceret værktøj til generering af testcases baseret på parvis og andre avancerede testmetoder.
  • ACTS (Automated Combinatorial Testing for Software): Et open source værktøj fra NIST, der understøtter parvis test.
  • TestPairs.dk: Et online værktøj, der tilbyder parvis test. Værktøjet er gratis, og kan også håndtere eventuelle afhængigheder mellem data.

4. Praktiske Eksempler på Parvis Test

4.1 Eksempel 1: Test af en Webapplikation

Lad os tage et eksempel på en webapplikation, der skal testes på tværs af flere browsere, operativsystemer og netværkstyper. Vi har følgende inputparametre og deres mulige værdier:

  • Browser: Chrome, Firefox, Edge
  • Operativsystem: Windows, Mac, Linux
  • Netværkstype: Wifi, Mobil

For en komplet kombinationstest vil vi have (3 * 3 * 2) 18 testcases. Men ved hjælp af parvis test kan vi reducere antallet til kun 9 testcases, som vist i tabellen nedenfor - der er anvendt værktøjet TestPairs.dk:



Disse 9 testcases dækker alle par af parameterværdier, hvilket betyder, at vi har en høj sandsynlighed for at opdage fejl, der skyldes interaktionen mellem to parametre.

4.2 Eksempel 2: Test af en Mobilapplikation

For en mobilapplikation kan vi have følgende parametre:

  • Devicetype: Smartphone, Tablet
  • Operativsystem: Android, iOS
  • Skærmopløsning: Lav, Høj

Ved at anvende parvis test kan vi generere følgende testcases:



I dette tilfælde vil vi have 5 testcases, der dækker alle parvise kombinationer af parameterværdier, hvilket sikrer en grundig test af applikationen på tværs af enheder og skærmopløsninger. Igen er der anvendt gratis værktøjet TestPairs.dk - andre værktøjer vil kunne reducere til 4 testcases, som vist efterfølgende:

TC 1: Smartphone - iOS - Lav
TC 2: Smartphone - Android - Høj
TC 3: Tablet - iOS - Høj
TC 4: Tablet - Android - Lav

5. Fordele og Udfordringer ved Parvis Test

5.1 Fordele

  • Effektiv testdækning: Parvis test giver en høj grad af dækningsgrad for de mest almindelige fejltyper.
  • Reduktion i antallet af testcases: Ved at fokusere på parvise kombinationer reduceres antallet af nødvendige testcases betydeligt, hvilket sparer tid og ressourcer.
  • Nem at implementere: Parvis test kan nemt implementeres ved hjælp af tilgængelige værktøjer, hvilket gør det til en praktisk metode for mange testprojekter.

5.2 Udfordringer

  • Dækning af komplekse fejl: Parvis test fokuserer på par af parametre, hvilket betyder, at fejl, der involverer interaktioner mellem tre eller flere parametre, muligvis ikke opdages.
  • Krav til nøjagtig parameteranalyse: Succesfuld implementering af parvis test kræver en præcis og omfattende analyse af inputparametre og deres mulige værdier.
  • Begrænsninger i værktøjer: Ikke alle værktøjer understøtter komplekse scenarier eller meget store mængder af parametervariationer.

6. Konklusion

Parvis test er en effektiv og praktisk metode til at optimere testen ved at reducere antallet af testcases, samtidig med at en høj dækningsgrad bevares. Denne testmetode er særligt nyttig i situationer med mange inputparametre og begrænsede testressourcer. Ved at kombinere parvis test med andre testmetoder kan man opnå en endnu højere testdækning og sikre pålideligheden af softwareprodukter.

7. Anbefalinger

  • Inkorporér parvis test i din teststrategi: Overvej at bruge parvis test som en standarddel af din teststrategi, især når du har med komplekse systemer at gøre.
  • Kombiner med andre metoder: Parvis test bør kombineres med andre testmetoder for at sikre en mere omfattende dækning, især for fejl, der opstår på grund af interaktioner mellem flere end to parametre.
  • Brug værktøjer: Udnyt tilgængelige værktøjer som PICT, Hexawise, ACTS og TestPairs.dk til at automatisere og effektivisere parvis test.
  • Løbende evaluering: Evaluer løbende effektiviteten af parvis test i dine projekter, og juster strategien efter behov for at optimere testdækningen.

Ved at følge disse anbefalinger kan du sikre, at din testproces er både effektiv og omkostningseffektiv, samtidig med at du opnår en høj grad af pålidelighed i de softwareprodukter, du tester. 


lørdag den 15. juni 2024

Det Agile Koncept

 En god oversigt over det agile koncept findes i følgende billede:


 

fredag den 14. juni 2024

Webinarer via Q Nation A/S

 Jeg og mine kollegaer afvikler løbende forskellige webinarer under brandet Q Topics - alle webinarer relaterer sig til test og kvalitet.

Jeg har indtil dato afholdt følgende:

  • Mine hemmeligheder til effektiv testmanagement
  • Testteknikken Procescyklustest
  • Testteknikken Klassifikationstræ

Alle webinarer i Q Topics serien kan ses her:

Oversigt over tidligere events — Q NATION A/S 

 

tirsdag den 16. maj 2023

De forskellige kilder til testprincipper

Begrebet testprincipper er omtalt flere steder i litteraturen, og jeg omtaler her de steder jeg lige kender til:

I ISTQB Foundation Syllabus Version 4.0 er nævnt følgende syv testprincipper:

  1. Testing shows the presence, not the absence of defects
  2. Exhaustive testing is impossible
  3. Early testing saves time and money
  4. Defects cluster together
  5. Tests wear out
  6. Testing is context dependent
  7. Absence-of-defects fallacy

I bogen 'TestGoal - Result-Driven Testing' skrevet af Derk-Jan de Grood skriver han om følgende ti testprincipper for testerne:

  1. Focus on result
  2. Build trust
  3. Take responsibility
  4. Master the testing profession
  5. Build bridges
  6. Test in phases
  7. Facilitate the entire IT life cycle
  8. Provide overview and insight
  9. Ensure re-usability
  10. Keep in mind: Testing is fun!

I bogen 'The Complete Guide to Software Testing' skrevet af Bill Hetzel skriver han om følgende seks testprincipper:

  1. Complete Testing Is Not Possible
  2. Testing Work Is Creative and Difficult
  3. An Important Reason for Testing is to Prevent Deficiencies from Occurring
  4. Testing Is Risk-Based
  5. Testing Must Be Planned
  6. Testing Requires Independence

I bogen 'Agile Testing' skrevet af Lisa Crispin og Janet Gregory skriver de om følgende ti testprincipper i relation til test i agil kontekst, som i deres optik er vigtige:

  1. Provide continuous feedback.
  2. Deliver value to the customer.
  3. Enable face-to-face communication.
  4. Have courage.
  5. Keep it simple.
  6. Practice continuous improvement.
  7. Respond to change.
  8. Self-organize.
  9. Focus on people.
  10. Enjoy.

I bogen 'Effective Software Testing - A Developer's Guide' skrevet af Mauricio Aniche skrives der om følgende syv testprincipper - hvor nogle minder om ISTQBs - måske med lidt andre ord:

  1. Exhaustive testing is impossible
  2. Knowing when to stop testing
  3. Variability is important
  4. Bugs happen in some places more that others
  5. No matter what testing you do, it will never be perfect or enough
  6. Context is king
  7. Verification is not validation

Jeg synes de forskellige kilder er interessante, og kan danne grundlag for en del refleksion og overvejelser.


lørdag den 2. april 2022

Testerens ti testprincipper

I bogen 'TestGoal - Result-Driven Testing' skrevet af Derk-Jan de Grood skriver han om følgende ti testprincipper for testerne:

fredag den 18. marts 2022

Top ten trends that will help bulding a robust test organization in 2022

  1.  Development skills
  2. Agile and DevOps
  3. Artificial Intelligence
  4. Embrace mobile testing
  5. Test automation
  6. Establish metrics to track testing
  7. Invest in security testing
  8. Quality is owned by the entire team
  9. Rapid Software Testing
  10. Scale testing for the IoT

 

mandag den 17. januar 2022

ISO 29119-3 - Opdatering af den organisatoriske teststyringsdokumentation

 ISO har opdateret den internationale teststandard ISO 29119 del 3, som omfatter testdokumentation, og jeg fokuserer her på den organisatoriske teststyringsdokumentation.

I den tidligere udgave (2013) arbejdede standarden med følgende to niveauer:

  • Testpolitik (Test Policy)
  • Organisatorisk teststrategi (Organizational Test Strategy)

Den opdaterede version (2021) arbejder med følgende to niveauer:

  • Testpolitik (Test Policy)
  • Organisatoriske testpraksisser/testhåndbog (Organizational Test Practices)

Ændringerne i testpolitikkens indhold er mindre og primært i relation til indledningen, men ingen ændringer i relation til testpolitikkens 10 indholdspunkter.

Ændringerne i de organisatoriske testpraksisser (testhåndbog) dækker også lidt det indholdsmæssige, idet der nu er føjet punkter om testniveauer, testtyper og regler/guidelines om afvigelser fra de organisatoriske testpraksisser, og for de punkter der defineres for hvert testniveau (og nu præciseret også kan defineres for hver testtype) er punktet testdata angivet mere eksplicit.


onsdag den 20. oktober 2021

Falsk negativ vs falsk positiv

 Begreberne 'falsk-negativ' og 'falsk-positiv' giver nogle gange anledning til debat, hvorfor jeg i samarbejde med en kollega har udarbejdet nedenstående oversigt der forhåbentlig hjælper med at præcisere begreberne:


 

onsdag den 31. marts 2021

What did you learn in test today

 Nu er jeg ikke den store lyriker, men har med udgangspunkt i og inspiration fra 'What did you learn in school today' (Tom Paxton/Eddie Skoller) omskrevet til handlende softwaretest:

What did you learn in test today
Dear little tester of mine?
What did you learn in test today
Dear little tester of mine?

I learned that vendors never told a lie
I learned that testers seldom die
I learned that nothing is bug free
And that's what the test manager said to me

That's what I learned in test today
That's what I learned in test

What did you learn in test today
Dear little tester of mine?
What did you learn in test today
Dear little tester of mine?

I learned that test managers are my friends
I learned that testing never ends
I learned that bugs die for their crimes
Even if we make a mistake sometimes

And that's what I learned in test today
That's what I learned in test

What did you learn in test today
Dear little tester of mine?
What did you learn in test today
Dear little tester of mine?

I learned our test strategy must be strong
It's always right and never wrong
Our test managers are the finest men
And we admire them again and again

And that's what I learned in test today
That's what I learned in test

What did you learn in test today
Dear little tester of mine?
What did you learn in test today
Dear little tester of mine?

I learned that testing is not so bad
I learned about the great ones we have had
We fought in planning and in execution
And someday I might get my chance

And that's what I learned in test today
That's what I learned in test

 

Tjekliste til projektdialogen mellem projektleder og test(manager)

 Her er en række punkter jeg oftest tager op til et opstartsmøde med projektlederen på et nyt projekt - anvendes til forventningsafstemning:

  • Projektnavn
  • Projekttype - teknologi
  • Projektmetode/udviklingsmetode
  • Hvad skal testes
    • Scope for testen (forventet)
    • Testtyper (forventet)
    • Hvilke systemer indgår (forventet)
  • Ressourcer
    • Hvem er allokeret til projektet
    • Hvem er testerne
    • Styregruppe/projektejer
    • Øvrige relevante informationer
  • Økonomi
    • Budget for projektet
    • Afsat til test - eventuelt på hovedaktiviteter / roller
    • Øvrig testbudget - f.eks. leverandørhjælp
    • Øvrige omkostninger- f.eks. rejser, ophold, forplejning m.m.
  • Tidsplan
    • Projektstart
    • Forventet afslutning
    • Forventet levering af testgrundlag
    • Forventede leverancer / datoer for samme
    • Dato for idriftssættelse
    • Fraværsperioder / lukkeperioder
  • Testgrundlag
    • Løsningsbeskrivelse
    • Kravspecifikation
    • Workshops
    • Andet
  • Testsupport
    • Forventninger til testmanagement
  • Organisatorisk teststyringsdokumentation
    • Testpolitik
    • Organisatorisk teststrategi
  • Testleverancer
    • Testplan(er)
    • Testcases
    • Teststatus (indhold og frekvens)
    • Testafslutningsrapport
  • Testværktøjer
    • Teststyring
    • Testautomatisering
  • Leverandøraftaler
    • Testdata
    • Ressourcer - f.eks. udviklere m.fl.
    • Testsupport
  • Kendte risici
  • Hvad er vigtigst af følgende
    • Tid
    • Budget
    • Kvalitet
  • Andre relevante forhold

 

tirsdag den 19. januar 2021

12 hemmeligheder for effektiv testmanagement

  1. Forstå testmål og interessenter
  2. Fastlæg din teststrategi
  3. Brug modeller
  4. Fokuser på risici
  5. Beslut omfanget af testen
  6. Skab dokumentation der skaber værdi
  7. Planlæg det som en rejse - ikke som en opgave
  8. Gennemfør planen
  9. Test som et team
  10. Performancetest
  11. Brug rigtige værktøjer og infrastruktur
  12. Udvikl dig selv

tirsdag den 16. juni 2020

Test for ledelsen

Der findes mange opfattelser af, hvad softwaretest er, og desværre også mange misforståelser. Misforståelser som kan give en række udfordringer for dem der har roller inden for testområdet.

Mange har den opfattelse, at testerne kan sikre kvaliteten af de enkelte softwareleverancer. At teste giver ikke isoleret en højere kvalitet i softwaren - det forudsætter at de fundne fejl faktisk også rettes, og dermed øges kvaliteten. Testen bidrager selvfølgelig til denne kvalitetsforøgelse, men alene ved at evaluere softwareleverancen og belyse kvaliteten af denne.

Men hvis ikke softwaretest sikrer kvaliteten, hvad er værdien så?

Et vigtigt og værdifuldt udbytte af test er information - herunder information om kvaliteten af softwareleverancen. Denne information kan anvendes i flere sammenhænge - dels til fejlrettelse og dels til dannelsen af et beslutningsgrundlag for afgørelsen om leverancen skal idriftsættes i produktion eller ej. Testerne er med til at bidrage til grundlaget, men selve beslutningen er ledelsens ansvar.

Informationen om kvaliteten kan også med stor fordel anvendes til at italesætte de potentielle risici der er for forretningen, hvis softwaren idriftsættes.

Ledelsen får rapportering fra projektets testmanager, som typisk vil adressere følgende fem aspekter:
  • Test (og dets resultater) opdelt på status (godkendt, fejlet, blokeret m.m.)
  • Fejl opdelt på alvorlighed (forretningsmæssigt) og prioritering (hvordan skal den rettes)
  • Testdækning, herunder eksempelvis andelen af krav der er dækket af test
  • Produktrisici opdelt på risikoklasse (høj, medium, lav)
  • Tillid, som er en mere subjektiv opfattelse af softwaren og kvaliteten
Det er ikke muligt at teste alt - der er ganske enkelt for mange kombinationer og muligheder og for lidt tid og budget. Omfanget af test bør være en afvejning af de omkostninger der er forbundet med testen og fordelen/værdien af testen. Denne afvejning fremgår af nedenstående figur:


Kurven A (Rød) udtrykker de samlede omkostninger til fejl således at jo flere fejl - udtrykt ved et lavere niveau af kvalitet desto højere omkostninger og omvendt for færre fejl. Årsagen til denne sammenhæng bygger bl.a. på Barry Boehms studier. Kurven C (Gul) illustrerer de samlede testomkostninger for både statisk (f.eks. review) og dynamisk test og er stigende ved et ønske om højere kvalitet. Kurven B (Blå) viser kvalitetsomkostningerne og udgør summen af kurverne A og C. Det bør være målet at tilsikre en balancering af alle disse forhold og komme så tæt på kurvens minimum som muligt.

Da det ikke er muligt at teste alt er det vigtigt at der sker en klar udvælgelse og prioritering af testen. Det kan eksempelvis ske via risiko-baseret test med vurdering af produktrisici. Det er vigtigt, at ledelsen bakker op om dette og sikrer at forretningen deltager i dette arbejde.

Ovenstående figur kan anvendes som en god model for dialog mellem ledelsen og testmanageren om omfanget af testindsatsen. Hvis du er leder kan du anvende denne til en drøftelse med dit udviklingsprojekts testmanager - god fornøjelse.