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?

Test manager

Jeg har deltaget i et kursus i Test management, helt præcist ISTQB Advanced Test Manager og det blev afsluttet i går med en 3 timers eksamen.

Jeg kan ligeså godt afsløre med det samme, at jeg ikke aner om jeg har bestået endnu.

Selve eksamen var et opgavesæt på ca. 50 A4-sider med 65 opgaver der i alt kunne give 100 points, hvis man vel og mærket svarer rigtigt på alle spørgsmål. Det er en multi-choice eksamen (bestemt ikke en eksamensform jeg er tilhænger af) og der er i alt 3 timer til at komme gennem alle spørgsmålene.

Selve kurset op til eksamen, med Lisbeth som underviser, var rigtigt godt. Lisbeth har en meget lang erfaring indenfor området, hvilket gør det noget nemmere at komme i gang med pensum som er beskrevet i en noget kedelig og ujævn form i Syllabus (ISTQB Advanced Syllabus 2007 dk-version v1.0 – se hos dstb.dk).

Lisbeth formåede på meget inspirerende vis at holde os i gang på kurset med slides og gruppeopgaver. Dagene var lange og jeg fik desværre ikke mulighed for at lave lektier de 2-3 timer om aftenen efter hver kursusdag. Det vil vise sig senere når jeg har eksamensresultatat om det var en fejl(!)

Jeg synes selv jeg har fået et godt udbytte af kurset og jeg mener bestemt det er værd at have med i sin professionelle bagage, når man skal begå sig som testkoordinator/test manager i projekter med softwareudvikling. Jeg vil blot mene at man kommer nemmere gennem pensum og kurset, hvis man i forvejen har arbejdet med test i projekter i nogle år. Ellers bliver det måske for svært at bestå. Det er da også en forudsætning for deltagelse at man først har bestået ISTQB Softwaretest Foundation.

Planen for kurset lød:
Modul 1: 9. – 11. maj 2012
Modul 2: 6. – 8. juni 2012
Modul 3: 15. juni 2012 (repetition og eksamensforberedelse)
Eksamen: 18. juni 2012 kl. 10.00-13.00

Underviser: Lisbeth Hylke Thomsen
TestHuset.dk, Lautruphøj 1-3, 2750 Ballerup
Tlf 44 979 979
www.TestHuset.dk