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.

Testerens ti testprincipper

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

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

 

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.

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:

 

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

 

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
    
    

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.

Successful Test Automation

Jeg er i øjeblikket igang med en rådgivningsopgave med fokus på om forudsætningerne for testautomatisering er på plads, og faldt over denne liste:

1. Analyze the current process
2. Create an automation project plan
3. Put together the right team
4. Prepare a handful of test cases for automation
5. Research and select two or three test automation tools for further evaluation
6. Do a Proof of Concept (PoC)
7. Implement the selected automation tool
8. Allow time for training and the learning curve
9. Begin automating your documented test cases
10. Periodically review your process and adjust as necessary.
    

Procesforbedring - 10 fælder der bør undgås

Jeg faldt lige over denne oversigt - Karl Wiegers 'Software Process Improvement: Ten Traps to Avoid' - jeg har fastholdt den engelske formulering for at undgå at miste nogen af betydningen ved oversættelse til dansk:

1. Lack of Management Commitment
2. Unrealistic Management Expectations
3. Time-Stingy Project Leaders
4. Stalling on Action Plan Implementation
5. Achieving a CMM Level Becomes the Primary Goal
6. Inadequate Training is Provided
7. Expecting Defined Procedures to Make People Interchangeable
8. Failing to Scale Formal Processes to Project Size
9. Process Improvement Becomes a Game
10. Process Assessments are Ineffective

 Jeg vil i et senere blogindlæg komme ind på de enkelte fælder.

Metrikker - 10 fælder der bør undgås

Jeg faldt lige over denne oversigt - Karl Wiegers 'Software Metrics: Ten Traps to Avoid' - jeg har fastholdt den engelske formulering for at undgå at miste nogen af betydningen ved oversættelse til dansk:

1. Lack of Management Commitment
2. Measuring Too Much, Too Soon
3. Measuring Too Little, Too Late
4. Measuring the Wrong Things
5. Imprecise Metrics Definition
6. Using Metrics Data to Evaluate Individuals
7. Using Metrics to Motivate, Rather than to Understand
8. Collecting Data That Is Not Used
9. Lack of Communication and Training
10. Misinterpreting Metrics Data

Jeg vil i et senere blogindlæg komme ind på de enkelte fælder.

Test i Produktion

Så testes der i produktionsmiljøet i den københavnske metro. Lukkes i to uger i januar :

Som skatteborger er jeg da glad for at der ikke blev bygget et testmiljø, som en kopi af produktionsmiljøet. Men måske en simuleringsmodel kunne være et alternativ? 

Test Manager på et nyt projekt - Den første uge

Når jeg starter på et nyt it-projekt i rollen som testmanager tager jeg altid udgangspunkt i nedenstående tjekliste over informationer jeg bør få styr på i den første uge - tjeklisten er opdelt i nogle hovedemner:

Basis Information

• Motivationen bag projektet – hvorfor er projektet påbegyndt og hvem har startet det?
• Hvad er fordelene (benefit) for forretningen og hvilket formål understøtter det for forretningen?
• Er projektet et opfølgningsprojekt for et tidligere gennemført/lukket projekt?
• Hvilke aftaler er allerede lavet?
• Business case?
• Interessenter – bidrag og forventninger?
• Risikoanalyse?
• Hvilken information findes der om projektet og programmet som det er en del af?
• Hvilke produkter/systemer har indflydelse på test projektet?
• Hvilke afdelinger og andre projekter er involveret?
• Hvilke standarder og procedurer findes – og hvilke er obligatoriske?
• Hvilke værktøjer findes – og hvilke er obligatoriske?
• Hvilke templates/skabeloner findes – og hvilke er obligatoriske?

 Specifik Information i forhold til Test Management Model

• Hvilken testtilgang er valgt og hvorfor?
• Hvilken testmodel følges – herunder kvalitetsegenskaber, testniveauer og acceptkriterier?
• Hvilke projekt- og produktrisici er identificeret – dels for dette projekt og dels for lignende tidligere projekter?
• Er der en teststrategi?
• Hvilket budget findes – total og for test?
• Planer – projektet og for test?
• Hvordan måles projektets succes?
• Estimater – hvordan er de etableret – metoder?
• Hvordan håndterer organisationen et testprojekt?
• Hvilken support funktion findes i relation til test?
• Hvordan rapporteres fremdrift og status – og hvor ofte?
• Issues – værktøj, rapportering m.m.?
• Evaluering – efter hver fase?

 Dokumentation

• Hvilken dokumentation er tilgængelig – er hvad er dets status?
• Kravspecifikation, funktionel design, teknisk design m.m.?

 Testware

• Hvad er der tilgængeligt af testware – og kan det genbruges?
• Testscenarier, testcases, testdata, testscripts, testdrejebøger, testmiljø?

 Support Procedurer

• Hvilke støttende procedurer m.m. er der – configuration management, issue management, problem management, change management, release management?
• Hvilke udeståender er der – åbne issues?

 Rapportering & Koordinering

• Faste møder i projektteamet?
• Fast koordineringsmøder mellem projektleder og testmanager?
• Møder mellem testmanagers for hele programmet / relaterede projekter?