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?
  

Testing United 2019 - Fredagens Oplevelser

Så kom vi til testkonferencens anden dag - altså fredagen, og den kom hurtigt, men sådan må det være med en kort konference.

Første keynote var med Ron Werner om temaet The X-Factor. Keynoten var i programmet sat til at omhandle Mobile Testing, så det var da lidt spændende, hvad han så ville tale om. Han gennemgik en række cases om forskellen mellem succes og fiasko inden for it-industrien, fra Atari til Amazon og en lang række andre eksempler - spændende gennemgang og lidt interessant at se, hvor mange af dem man selv kunne huske. Det var også en meget levende keynote med involvering af deltagerne i forskellige afstemninger på konference app'en. Nogle af konklusionerne var, at succes handler om 'innovation with right timing' og det er brugeren der bestemmer.

Første tracksession var Ingo Philipp med AI in Software Testing - Will a Bot Steal Your Spot?, som var et indlæg mere om hans holdninger til temaet end om beviser eller fakta. Han kom med et godt statement om test - det er at lukke gap'et mellem hvad vi ved og hvad vi ikke ved. Hans konklusion var opdelt mellem begreber checking og testing - hvor man mente at AI kunne klart overtage checkning (verificere), men ikke testing (undersøgende/undrende m.m.). Men AI ville klart kunne hjælpe os med testen, men ikke overtage den. Så i vores levetid var det hans vurdering, at AI ikke ville overtage vores jobs.

Efter formiddagens kaffepause var det Abian Blome med Fuzzing Industrial Devices - Implementing Feedback Driven Fuzzing Tests in an Embedded World, som var rigtigt spændende alene grundet det setup det skulle fungere i. Indlægsholderen kom fra Siemens så det var i alt fra små enheder til tog, og det drejede sig om indlejret software, så skulle det dække både hardware og software. Det var et meget ærligt indlæg, hvor han ikke kun fortalte om successen, men også om de fejltagelser de havde begået. Det er nok nødvendigt med lige at få defineret fuzzing testing: Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.

Det er nu skønt med disse indlæg som også kommer ind på de fejltagelser, fejlvurderinger og dårlige beslutninger der tages og må gøres om eller justeres.

Derefter var der en længere paneldiskussion med Karen N. Johnson, Roman Nagy, Ron Werner og James Whittaker over konferencens tema og indlæg - alle keynotes talerne undtagen Greet Burkels. Altid interessant at overvære sådanne debatter og med spørgsmål fra deltagerne.

Efter frokosten var det Geoffrey van der Tas og Marta Wozniak-Semenniuk med et anderledes tema, nemlig Learn from a famous detective duo to improve your testing skills. Det var lidt sjovt da indlægsholderne var udklædt som Sherlock Holmes og Dr. Watson, og undervejs spillede rollerne ganske fint. Der var mange gode pointer fra dette indlæg i forhold til test, herunder observer - døm ikke. Ikke være biased. Få nye erfaringer. Få nye kompetencer. Brug deduktion i analyseprocessen om eventuelle årsager, herunder root-cause-analysis. Et dejligt skævt og sjovt indlæg og anderledes vinkel på testdisciplinen.

Konferencens sidste faglige indlæg var en keynote med Karen N. Johnson med emnet What We Bring Across Industries, og som var en mere personlig beretning om hendes opture og nedture, også rent personligt. Man kan have meget forskellige holdninger til sådanne indlæg, men det var ikke lige min kop te.

Samlet set en spændende og udbytterig konference, hvor jeg havde valgt at gå efter indlæg med AI vinkel, og når der er flere parallelle spor, så er der altid noget man går glip af. En god oplevelse, og lad os se om jeg når til Prag næste år.