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.

Testing United 2019 - Torsdagens Oplevelser

Jeg kørte spændt til konferencens første dag - det er altid spændende med en ny kontekst. Samlet set var der ca. 300 deltagere, mange med germanske eller slaviske navne. Tydeligt en mere regional konference, men det er spændende at opleve, se og høre hvad der rør sig i testverdenen i mellemeuropa.

Konferencen åbnede med en introduktion til emnet og de to der skulle lede 'slagets' gang.

Den første keynote var med James Whittaker over emnet The Future of Technology and How It Will Impact Test, hvilket var en god åbning af konferencens faglige del. Han gennemgik de sidste 30 års teknologiske udvikling med 1980'erne som han kaldte 'powerful' med mainframes og centrale systemer, 1990'erne som blev kaldt 'accessible', hvor PC'erne blev introduceret og udbredt både arbejdsmæssigt og lidt i privaten, 2000'erne kaldt 'connected', hvor internettet blev 'folkeligt' og så kom han til 2010'erne kaldt 'mobile' med en masse enheder vi alle går rundt med og til sidste forsøgte han at kigge et tiår frem, nemlig 2020'erne som han kaldte 'ambient'. En interessant gennemgå og spådom. Interessant var det også med hans udtalelse om alle de smart-ting vi har i dag og vil få fremover, f.eks. SMART TV - han sagde at første byggede/udviklede man computeren og derefter TV'et, og ikke omvendt som man måske vill tro. Generelt var hans råd til testerne - lær at kode og sørg for at være i front med udviklingen.


Så begyndte tracksession, hvor der skulle vælges, og det første valg endte på Ewald Roodenrijs med emnet Implement Continuous Testing in an Organization. Et spændende tema, hvor han gennemgik den rejse de havde været igennem - præsentationen var overraskende lidt vaklende og han brugte kun det halve af den afsatte tid. Men spændende at høre om autonomous testing og de udfordringer, faldgruber m.m. der er. Han nævnte flere gange at det vigtigste aspekt var mennesket. Deres evne og vilje til forandring.

Så blev det Raj Subrameyer med emnet Being Mortal in the Age of Artificial Intelligence, hvor han kom bredt omkring emnet AI og hvor meget data betyder i den forbindelse. Han præsenterede bl.a. begreberne weak AI og strong AI, som den svage var AI med en ting og den stærke var at kunne emulere menneskelig adfærd. Han kom også ind på AI og test, herunder mulighederne for at AI kan lave testautomatiseringen, hvilket kunne gøre vedligeholdelsen lettere (læs: billigere). Han kom også ind på det emne der måske ligger mange i testverdenen på sinde - mister vi vores job? Hans klare bud på det var Nej - undersøgelser viser at for hvert job der nedlægges som følge af AI oprettes der 1-2 nye. Han sluttede af med at omtale 'safery' i forhold til AI, og opfordrede at man deltog i arbejdet i de forskellige organisationer der er.

Så var der en ny keynote efter frokosten med Roman Nagy med emnet Artificial Intelligence in Autonomous Driving - Chances and Challenges. Han lagde ud med en gennemgang af Gartners Hype Cycle for 2019, hvor man kan se hvilke trends der kommer. Hans indlæg var rigtig spændende og lærerigt, selvom hans fokus ikke var test, men han kom ind på flere emner der var relevante, herunder de fælder der ved læring med billeder for AI modellen. Sådanne forhold er jo ganske relevante for testere.

Så påny tracksessions og den første efter keynoten var Vipin Jain med IOT Testing to deliver Values Across Industries. Han lagde ud med et statement om forskellen på 'almindelig' test og test af IoT - IoT er hardware, software og connectivity, og ALT skal testes. Antallet af devices og IoT enheder er stort og bliver endnu større med de fremskrivninger der foretaget, hvilket gør testen kompleks. Hans generelle budskab var 'det er her nu og det vil kun blive større'.

Så valgte jeg Lan Xia og Shelley Lambert med temaet Dealing with Verification Data Overload, og det var fra min side et lidt fejlvalg - det var meget teknisk og arkitekturmæssigt med en masse om Jenkins-servere m.m., men de fangede mig noget da de begyndte at omtale testdækning og måling af kodedækningen - de kunne dog ikke redegøre nærmere for, hvilke(n) af de mange kodedækningsmetrikker der er de anvendte. De var ikke testere.

Dagens sidste keynote af Greet Burkels med Multi-Industry Testing of New Amsterdam Metro Lin, som var en god afslutning på dagen, og relevant i forhold til Københavns metro.


Om aftenen var der Networking Party.

Samlet set en god og interessant første dag på Testing United, og ser frem til fredagens oplevelser.

Testing United 2019 - Test konference - Starter om få timer

Nogle gange skal man prøve noget nyt (og spændende) - denne gang er det en ny testkonference. Den hedder Testing United og foregår denne gang i Wien. Den roterer mellem tre byer - Wien, Prag og Bratislava. Min vurdering er, at det mere er en slags regional konference modsat de mere internationale som STAReast og STARwest i USA. Udvalget af sessioner er også mindre og så varer den kun to dage, men så undgår jeg sandsynligvis den 'traditionelle' konferencekuller, som jeg nogle gange har oplevet ved ugekonferencerne. Men spændende bliver det, og jeg vil efter hver dag skrive her på bloggen - så følg gerne med. 

Grænseværdianalyse i Wien

Grænseværdianalyse er en af testanalytikerens basisteknikker. Når man har undervist i testteknikken i mere end 10 år har man (læs: jeg) den under huden, og som en del af min DNA. Som nogle ved rejser jeg meget ofte til Wien, og senest fik jeg set på billetten til hurtigtoget fra lufthavnen til Wien centrum. Børn til og med 14,99 år rejser gratis med. Men hvor gammel er man når man er ældre end 14,99 år? Man er 14 år og 361,35 dage og 362,34 dage i skudår. Så man skal faktisk betale for rejsen 3/4 dage FØR man fylder 15 år. Det her bliver en spændende test. 

Testprocesforbedring - hvad skal være fokus?

I mange organisationer og virksomheder er interessen for at forbedre test- og kvalitetsprocesserne stor, men der er ofte tvivl om, hvilket fokus der skal være. For hvad betyder det at forbedre processerne i forhold til kvalitet og test?

I nedenstående figur er vist nogle af de fokusområder der kan være. Basis i figuren er testprocessen med input som testobjektet og forskellige midler, herunder ressourcer og tid, og med output i form af testresultaterne. Disse to inputemner og et outputemne kan være omdrejningspunktet omkring valg af fokus i modenhedsudviklingen.

Nogle af de spørgsmål man typisk vil have svar på kan være:

• Findes de vigtigste fejl i testobjektet så tidligt som muligt? (Egnethed)
• Hvor effektiv er testprocessen med hensyn til ressourcer og tid? (Effektivitet)
• Fungerer testprocessen som aftalt? (Verificerbarhed)

Hvad fokus der skal være i en analyse af modenheden afhænger naturligvis af virksomhedens situation og forretningsmæssige fokus - der er ikke nødvendigvis tale om et valg mellem de tre aspekter: Egnethed, effektivitet og verificerbarhed. Der er derimod ofte tale om et fokus der kombinerer de tre aspekter, men det er vigtigt i starten af arbejdet med modenheden, at være enige med ledelsen om, hvilket fokus der ønskes, idet dette påvirker scope for analysen og de tiltag der foreslås.

Back to the future - testmanagerens rolle i fremtiden med scaleret agilt setup

I foråret havde vi et Quality Time arrangement over temaet ’Har vi brug for testmanagers fremover?’ – det var en aktiv workshop over to dage med 9 aktive deltagere fra 6 forskellige virksomheder og organisationer.

Workshoppen startede med præsentation af hypotesen ’Vi har i fremtiden behov for testmanagement, men måske ikke rollen testmanager’. Jeg er ikke i tvivl om, at den ’traditionelle’ testmanager rolle som vi kender, og som vi har kendt i en del år nu, vil ændre sig, og i mange tilfælde helt udgå som en fast rolle. Men det er ikke det samme som at de opgaver som udføres af testmanageren i dag ikke skal løses fremover, men det sker sandsynligvis bare i et mere løst og differentieret set-up.

Mange virksomheder og organisationer har taget scaled agile til sig – oftest i form af Scaled Agile Framework (SAFe), hvorfor det kan være interessant at fokusere på netop denne metode. Det er dog ikke den eneste metode til håndtering af skaleret agil udvikling.

På teamniveauet foregår testen naturligvis som en integreret del af scrum-teamets arbejde, og vil typisk også indgå i slutkriterierne (Definition of Done), og teamets opgaver. 

På programniveauet kan testen forankres i systemteamet og/eller i shared services. I system-teamet kunne end-to-end testen foregå samt en tværgående regressionstest i forhold til ART’en, mens der i shared services kunne være opgaver som en samlede teststrategi, teatautomatiseringsstrategi og -services, værktøjsstøtte m.m.

Men er det så gammel vin på nye flasker? Nej, faktisk ikke, og det er heller ikke ny vin på gamle flasker. Det er faktisk ny vin på nye flasker. Det skal forstås på den måde, at vi er nødt til at tilpasse os den nye verden, men også at se på test med nye øjne.

På workshoppen var der bred enighed om hypotesen, dog med indsættelse af ordet traditionelle i anden del.

Syv testprincipper - men ikke fra ISTQB

Principle 1: Definition

To test a program is to try to make it fail.

Principle 2: Tests versus specs

Tests are no substitute for specifications.

Principle 3: Regression testing

Any failed execution must yield a test case, to remain a permanent part of the project’s test suite.

Principle 4: Applying oracles

Determining success or failure of tests must be an automatic process.

Principle 4 (variant): Contracts as oracles

Oracles should be part of the program text, as contracts. Determining test success or failure should be an automatic process consisting of monitoring contract satisfaction during execution.

Principle 5: Manual and automatic test cases

An effective testing process must include both manually and automatically produced test cases.

Principle 6: Empirical assessment of testing strategies

Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.

Principle 7: Assessment criteria

A testing strategy’s most important property is the number of faults it uncovers as a function of time.