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.

Fra Test Manager til QA Manager

I takt med den generelle udvikling i teknologier og udviklingsmetoder sker der også en afsmitning i forhold til de roller og titler der bruges inden for testverdenen. Da jeg startede i test var der ikke særskilte roller og titler, og slet ikke test manager.

I takt med udbredelsen af de mere dynamiske udviklingsmetoder som agile, DevOps, NEXUS og SAFe nævnes det oftere og oftere, at test manager rollen vil forsvinde eller i hvert fald ændre sig. Forandringen vil være fra udførende til rådgivende og støttende.

Det nævnes også ofte, at scopet/indholdet vil ændre sig, så den 'nye' test manager også har ansvaret for politikker og processer i bredere forstand.

Det er naturligvis en spændende udvikling vi går i møde - og måske skal du i den kommende tid have nye visitkort, og ikke mere tituleres test manger, men måske QA Manager, Test Master, Test Mentor eller Test Coach.