Blog

Discussing the ‘Modern Testing Principles‘

Outcome and self-reflection

On the 27th of September I had the privilege to organize a meetup in the name of the ‘Federation of Agile testers’ in the Netherlands (in short: fatnl). Together with my colleagues Klaartje and Jeroen I prepared a discussion evening, where we debated the ‘Modern Testing Principles’ coined by Alan Page and Brent Jensen. The event was sponsored by De Agile Testers, the company I work for. De Mobiliteitsfabriek sponsored the location and drinks. Thank you so much! The location was awesome providing a nice, friendly, cozy, living-room atmosphere.

There were two central goals of this evening; getting more understanding surrounding the Modern Testing Principles and discussing them and learn from the other persons’ experiences. The evening was attended by the Dutch finest agile testers.

After dinner the program started. To give our participants a warm-up in their thinking, we asked them to think what they want to achieve this evening, Klaartje started setting up ‘the tree of knowledge’.

Next the tree was built it was time to give a short introduction on each of the principles. In a 25-minute talk I introduced the principles to the audience. As expected, the discussion started instantly and I was bombarded with critical questions that I was trying to provoke. Both answering, provoking as sticking to the story was difficult.

Then it was time to discuss. The attendees split into groups of five to discuss the principles, which we split into three subjects. Each round had his own focus. Round 1 was the impact of the modern testing principles on the business, round 2 was about the impact on the team and round 3 was about the impact on the testing craft.

The atmosphere was good and the discussions were vivid and to the point, people agreed and disagreed and all was in a friendly, but to-the-point manner.

Shared agreement

There was a general shared agreement on some areas: Testers should move away from code-correctness / being a safety net / verification of the system and help developers to build their own safety net. We should help optimizing feedback loops on process level, technical level and social/empathy level. Data gathered directly and indirectly and gathered from production can – when put into context – help us getting more insights on customers’ usage, demands and steer us in the right directions.

Where things starting to diverge

From the start, during the introduction, people started wondering: ‘To who are we referring to Who is we? Do ‘we’ mean the tester, testing, the development team, organization? The hypothesis thinking triggered another question. How does this relate if you work for a financial institute when a large part of your work is mandatory by law?

As anticipated, the controversial principle number 5 (“We believe that the customer is the only one capable to judge and evaluate the quality of our product.”) triggered another flow of discussions. Who is our customer? There is a difference between our users and customers – referring to the business in enterprise organizations. Principle number 2 and 3 also triggered discussions and there were two opposites. Why do testers have to improve the team? Isn’t it arrogant to think that testers can improve the team?

But what stuck at the end was that the principles itself weren’t so practical and people started even mocking the principles a bit. They aren’t testing principles, you can maybe say they are ‘development’ principles or even ‘modern…principles’. There is nothing about testing in the principles. Also, people found the words within the principles vague and the sentences too lengthy. That makes the principles hard to remember.

 

People enjoyed the discussion and the evening. People were heavily debating the principles. The principles triggers discussion and people loved that discussion. A great thing is, I didn’t hear anyone say that the principles are unfeasible.

 

Personally

For me it was hard getting a logical flow into the presentation, even when the principles are ‘just’ 7 sentences. Being on stage ‘defending’ the principles while dealing with the critical questions was uncomfortable but also fun. Trying to get the flow into the presentation started months back. The way Alan and Brent describe things in their podcasts are great, but these guys jump forward and back all the time making it difficult to manage the flow. It doesn’t help that the principles are entangled because that makes story telling a difficult task. The evening was fun but if I do self-reflection, I couldn’t bring the explanation to the level I wanted to. Am I the right person to explain the principles? Insecurity kicks-in here.

After some nights of sleep my thinking started to settle down. How can you call these principles testing principles while not talking about risk and critical thinking? While I do like the thinking behind the principles and even foresee the future of testing going that way – hell – I already have been there – I don’t think the principles are IT! You can’t just read the principles, give a lightweight introduction and expect people to understand and comprehend them – even when you turn on your systems- and critical thinking. You can’t just get away by saying “the principals are an organizational wide view and they act on tactical level”. As also said by Alan and Brent: they require guidance but does this also apply to explaining the principles?

What can improve the principles:

  • Stop calling them testing principles because they are not. The principles relate more how to approach quality. If there is nothing like risk and critical thinking you can’t call it testing principles. If you want to call them testing principles, at least include risk and critical thinking.
  • Stop using the word modern. Some people think modern is now and not the future. They can’t understand how the principles relate to the time aspect and think they can be applicable now for their current situation
  • Make the principles less lengthy and much more to the point, make them stick!
  • Offer a grow path: People tend to stick to their own (narrow) thinking because of their experience. If you have never seen the power of making developers responsible for the safety-net and the power of analyzing the data from production it is hard to comprehend the principles. You are either with or against the principles.

For me; I still love the thinking behind the principles but in the end, I choose not to use them because of their words. Instead of using these principles I will stick to my very own believe: Make myself redundant; both as a tester and a test coach. And yes, sometimes that seems to be impossible 😉