mandag den 23. juli 2018

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.

fredag den 13. april 2018

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.

mandag den 29. januar 2018

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.