Når man søger en test manager …

istqbJeg er i gang med at finde et nyt projekt der mangler en dygtig test manager.

Under min søgen falder jeg en gang imellem over nogle arbejdsgiver forventninger, som vækker min undren og jeg har lyst til at dele et eksempel.

En arbejdsgiver søger efter en Senior Test Manager og det er i den finansielle sektor. Tjek, det kunne sagtens være mig de har brug  for, men så jeg bliver lidt skuffet efter at have læst stillingsopslaget – primært pga af en enkelt formulering (resten af ønskerne kan jeg opfylde).

Formuleringen lyder sådan:

Your key responsibilities in this role will be:

  • You will be responsible for ensuring that our mobile payment services are stable and robust.

(der er flere på listen, men denne tog pusten fra mig)

Der søges efter en senior test manager der skal være ansvarlig for at deres platform er stabil og robust?!?

Desværre er det noget jeg møder fra tid til anden, at man er af den opfattelse at dette er et ansvar der ligger hos en testfagligt ansvarlig. Det er også min erfaring, at med et sådant ansvar har man sjældent nogen myndighed eller beslutningsdygtig indflydelse i organisationen.

Meget kort fortalt så er en test manager (senior eller ej) noget så enkelt som en projektleder med et særligt fokusområde, nemlig: test af produktet.

Så set i forhold til eksemplet ovenfor er det helt sort for mig, at en test manager gøres ansvarlig for en platform, som formentligt består af infrastruktur, enheder, servere, operativsystemer, storage enheder, databaser osv. osv. og så til sidst softwareproduktet der leverer mobile payment services. Den samlede løsning er i mine øjne langt udover hvad en test manager skal tage ind i sit ansvarsområde. Det er desuden svært at finde en person der har alle de fornødne kompetencer.

Med mindre jeg tager fejl og det kun er produktet mobile payment services at test manageren bliver ansvarlig for, men så rejser der sig spørgsmålet, hvem er ansvarlig for resten af løsningen? Hvordan samarbejder man om det? Hvordan er ansvarsfordelingen? Det kan hurtigt blive et komplekst landskab at navigere rundt i med en sikker hånd, hvis det brænder på.

Så er der ordet “robust”. Her tænker jeg at der skyder man ved siden i forhold til en test manager. Krav til robustheden kan verificeres og testes under test managerens kyndige indflydelse, men oprindelsen til krav om robusthed kommer i designet af løsningen, implementeringen af platformen og med udviklerenes ekspertise.

Derudover så er resultatet af en verificering og test noget som test manageren rapporterer – det er ikke noget en test manager som sådan skal tage stilling til. En test manager kan godt have sin egen mening om produktets robusthed- og det rapporterer test manageren, men det er nu engang ledelsen der i sidste ende beslutter om produktet anses for at være robust nok i forhold til de krav der er stillet til produktet.

Jeg beklager hvis jeg har stødt nogen med mine betragtninger, men det er blot vigtigt for mig at fortælle om hvad en test manager skal arbejde med i sit job – set fra mit synspunkt. Det handler i allersidste ende om ens helbred og jeg mener eksemplet beskriver problematiske forhold der er kan lede til en test managers fremtidige psykiske nedbrud.

Det er i hvertfald meget vigtigt at spørge ind til ansvarsområder og beslutningskompetence inden man vælger en stilling som test manager.

eBook: The Assertive Tester

I would like to be an assertive tester. Get inspired by reading the short eBook by Declan O’Riordan:

Assertive testing is based on the belief that the tester has the same rights, responsibilities and personal self-worth as other people. An assertive tester evaluates a situation, decides how to act, then responds honestly and spontaneously without anxiety or guilt. The assertive tester respects themselves and others, and takes responsibility for their actions and decisions.

Link to eBook

The cost of fixing defects

I have many times been asked to estimate the test effort in a variety of test activities in different projects. In general test estimation is a difficult skill to master  and it sometimes requires several iterations before I am confident about the result – even when I have gathered some test metrics regarding time and effort on test activities in previous projects.

One of the test activities that can mess up your test estimates is the cost of fixing defects (from a test perspective it’s about defect management, retests and regression tests). You will not gain popularity or gather useful insight if you ask the project manager or the developers the question “How many defects do you expect to put in the product?”

This week I read a new book about test and again I see some estimates on how much it costs to fix defects depending on when the defect was discovered.

Continue reading “The cost of fixing defects”

CAT training

I have participated in a CAT (Certified Agile Tester) training course by Sogeti in the period 25.-26. and 29.-30. September 2014.

The teacher on the course was Hans-Henrik Olesen. He’s a very experienced agile tester and developer which was a big advantage since he could relate the theory to practical examples and real life experiences.

The course is a combination of learning theory from the CAT manual and practical exercises where we were doing actual testing on a demo system. It was not boring in any way since the training consisted of listening to Hans-Henrik, discussions in groups, discussions in plenum and practical exercises in a logical context. Also homework in form of questions was assigned for each training day. This enabled us to quickly learn about the agile process and putting it into practical use.

This was the first course where the exam is not an extension of the training days. Normally the course is 5 days in a row where theory and exercises is held on Monday to Thursday and exam is on Friday. Normally a very hectic training period for the participants. Our training was cut in half by a weekend and exam will be held on the 6. October.

Hans-Henrik has informed us that 80% pass the exam first time – well, we know later if it’s still true.

About ISO 29119

The tester community do not like the upcoming ISO 29119 “standard”. Why is that?Stop ISO 29119 Another issue is that is this really a standard created according to the rules and guide lines from the ISO organization?

Here’s my very short list of reading before you make up your mind:

DevelopSense, Frequently-Asked Questions About the 29119 Controversy

Huib Schoots has a collection of resources here: ISO29119

If you do not agree on making ISO 29119 a testing standard then support the tester community against the standard by signing the Petition: Stop 29119

It is my opinion that I don’t need a standard for my work that tries to guide my way of thinking in the same way no matter what kind of product or project I working on. I believe that testing and preparation of testing activities should always be done with respect to the context in which it is performed. It is also my believes that a standard will only increase the costs of testing without adding more value to the end product.

Thoughts about Testing

This morning I saw this tweet from Michael Bolton

testing

My first thought was here is another bumber sticker statement from Michael. Usually I just read these statements and wonder how he can compress his knowledge and experience to so short statements. And does he  expect every reader fully understand them?

Well, I read it and went outside to remove the snow from my car. During this activity my thoughts fell back on Michaels statement and I tried to follow the track of thoughts.

“Testing cannot confirm that something WILL work or even that it DOES work; only that it CAN work”

In my company we use different test environments for different test phases (yes, we have a lot of “Factory” testing going on). We use a pre-production environment for our user acceptance test before deploying a release to production.

And almost every release deployed to production creates failure scenarios that the previous test phases did not find. Why?

One reason is that the test environments never will have the exact same configuration as production – mainly due to costs of licenses and hardware not to mention maintenance costs of test environments. But also configuration and interfaces can be significantly different.

Test data is another reason. It can be very difficult to create every bit of test data to match production – same goes for test configurations for that matter.

Testing is also about using your time on specific prioritized areas. As Michael often points out: “What is the problem?”. Maybe this focus on specific problems can take some of our focus away from secondary and low priority areas? And this will later create new problems.

Testers are very skilled (hopefully) and they can be very creative and eager to learn and play with the software under test. Yet sometimes obvious problem slips through to production. Can a tester become “blind” to problems during testing and not see what 1000 users later discover 10 minutes after release have gone in production?

Michael statement contains a lot of truth (if I understand it correctly); When we perform test, it is done under certain conditions with certain test configurations with certain tester skills etc. and under these circumstances we, the testers, can conclude that the software CAN work.

I am not saying that every tester should have a tattoo with “Testing cannot confirm that something WILL work or even that it DOES work; only that it CAN work”

– but maybe every responsible CEO should have this Tattoo?