QA Network Aarhus is a local non-affiliated network of testers (and good friends) in Aarhus. Where I had the great pleasure of talking about Exploratory Testing. This is the link collection, the slides are attached.

Ten years ago I was in software testing, and we looked into test process improvement by the guidelines of the Test Maturity Model (of 1998). Sometimes we tried to add more process and structure, insisting that unit test was documented prior to integration test start or that the lead developers participated in the reviews of the test strategy (gosh). Often it happened that our quick wins was not in line with the “maturity” of the rest of the delivery organisation.

Here is the picture we sometimes drew to understand: If you have a wheel, that has to be round to deliver systems to the business, and each group is a cog. Then the best thing is for the cogs to be equal length. If the testing cog is too long / too “mature”, the wheel doesn’t run around, but bumps into testing. If a cog is too short, the wheel may run, but the next cog catch the drift of the previous one.

Sometimes it was truly, that testing picked up where the application teams had failed to integrate and communicate. We could spend weeks of snow-plowing with one integration defect stopping all progress, just to find yet another bridge to cross in the enterprise delivery landscape.

Sometimes management added metrics – like the number of testcases to pass pr. day (linear progress) or a real couch to have the project manager to sit on, until we found yet another problem to have resolved among the many teams. But pouring more process descriptions, more contract interpretations or rigor into the testing never fixed the real problem – that the cogs of the delivery wheel needed to grown across teams – not driven by the need from management to control testing (because testing picked up the tap in the end).

ISO 29119 may be a vocabulary and a guideline, and at best a body of knowledge. But the thing is that if organisations try to fix their delivery process by adding more rigor, ceremony and borrowed vocabulary the testing activities will yet again be the odd cog in the wheel. I don’t see any ISO standard for management, for leadership, for a standard development methodology or ISO standard for how to solve unknown problems. And testing is about finding the unknown and inform the stakeholders.

Learn the context – and provide information to the business within that frame.

Similar to scope creep we may also experience “test creep“. Test Creep is when the tester adds more tests than what is in scope. Just as well as more business functionality is added during scope creep, more testing is added in test creep. Both aren’t necessarily bad, but in time-boxed or similar (budgeted) constraint projects creeping isn’t necessarily value adding. This is probably easier to understand in an agile project focusing on minimal viable product , but may happen in other contexts too.

It is test creep, when the tester feels an obligation to run an extra drill down into browser and OS configurations, when scope is less broad. It is creeping the scope of testing, if the testers feels a “/need/ to write testcases for this first” when exploratory sessions fits the mission. Consider test creep like gold plating, in that way that it tries to refine and perfect the product – when good enough is the perfect fit.

Test creep can happen intentionally, happen by management or by product owner request. It may happen unintentionally, and usually it is with the best intentions – as more testing always is better testing – right? (But it Depends) Sometimes yes, we as testers are to blame that we add more scenarios, rigor and details, because a testing mindset drives us to investigate the product.

In discussing this with Mohinder and Darren, we found that – it’s not only a matter of removing wait time for testers. This may add more time, to test but the scope creep in testing may happen none the less. A Lean mindset with focus on what adds value to the business and a discussion on the minimum viable testing will assist the project in avoiding test creep.

What I know of the ISO29119 is that specifies specific numerated techniques, documents and document content. I know this from their website, where I can read that it will cost me $1000 to buy “the book” (club discounts available) – the body of knowledge.

It’s a collective work written by a number of people in the industry, and have been years in the making. Some of the people work in consulting and provide training in the framework, some of the companies sponsoring the work provide consulting in implementation of the framework. Companies can have an audit for a certificate too. That will require a large investment as the organisation have to (norminative) conform to plenty of “shall”.

But besides that it’s a closed book (and it’s not even on Amazon). To me the 29119 is misguided from the beginning, it should be a book – a commercial body of knowledge, like TMAP or like ITIL. Something that you could buy into or not. Not something in any respect labelled as a international standard.

It seems it requires either a range of documents and lot of tailoring

It seems to be some what “dated” in the addressing ways of testing being added in recent years

It seems to claim that it has consensus in the industry

It seems that some people have tried to participate , but failed

It seems that some people did not want to participate on principle, even if invited

It seems to claim that it is a silver bullet, a one size fits all

I cannot evaluate the implications for my customers asking about compliance without elaboration – on the details of 29119, and on the customers objectives. What is the business driver for complying with said framework? Which is actually what I was looking for – what helps the (customer) business making a business?

I doubt that someone else’s delivery framework can provide you with the DNA, the unique value proposition, of the specific context that is needed – for you! #ImLookingAtYou. If we blindly comply with the framework what is the driver besides cost and commodity. If the driver is something else, then start right there. Start with how testing and artefacts implements the strategy, values and decisions that you have. Start with “innovative“, “quality of life“, “coherent” – how does that relate to your testing.

You stop going deeper down the tree, when there is nothing more knowledge to gain, just like good (exploratory) testing.

—

Cultural context of the “for 100″ comes from the Jeopardy TV Quiz, where the questions come in 4 levels: 100, 200,300, 400 for the increasingly harder questions. The prize is similarly $100 for level 100 etc.

Yes I could, but the thing is it would need longer runs. I run with the Running Club Tuesdays and Thursdays before dinner. As a simplified example – if dinner get’s delayed the kids won’t eat as well, then they can’t fall asleep – and will need to eat past their bed time. They will sleep too late, and we (the parents) will have less time to the evening chores and being together. Every time there is something I’d like to do, there is always something else that matters that doesn’t get done.

“Come to X-conference – it’s just a matter of priority if you’re one of the ones”

Sure, it is – that’s easy for you to say. But €2000 + travel is out of my private pocket, missing work hours is out of my pocket, being away from family is out of both my time and their time. And really €4000 is a lot of money in a family with two kids with special needs – where the income is one job, one early retired. Also it’s a stupid argument, as I can point to heroes of testing that I consider “one of the ones” that like me aren’t going to both this and that.

I can do a Test Bash, write blog posts* and articles for the Testing Planet etc.