Musings on Simplifications and Adoption of Methods

In the last days I have been thinking a lot about my ideas and thoughts on methodologies. This was triggered by the discussions around ISO 29119. When thinking about it, I found myself back at my starting position rather quickly: there are a lot of methods to learn, most of them have their time and their place and it is about finding the right mix and selection.

So how to select? By trying out methods, by learning them, succeeding and failing. This is how I learn, and I assume that is true for many people.

Another question I pondered was to understand, as to why many people, whom I think of as most accomplished in the field of software testing and software quality, are that strongly opposed to ISO 29119. They are most likely the ones who know most about the methods and tools available.

And I went back to the way I learn. And when looking back, I learned by example. By emulating, by following a script, a schema. By following a script, a step by step guide you learn a method without actually deeply understanding it. Just over time, as you use it more often, experiment with it, observe what happens when you deviate, you learn not only to use that method, but to inherently understand the method. And the more you understand it, the more you will forget about the script. The more you understand it, the more you will use the method based on your understanding of the underlying principles. And the more you understand it, the more you will see the shortcomings of the script, the simplifications, the things left out just to make it palatable.

This reminded me to the discussions between Kent Beck, David Heinemeier Hansson and Martin Fowler on TDD. There one of the arguments of DHH was that the methods of TDD would at some point actually hurt the design. Kent Beck on the other hand argued that he works from first priciples and therefore it should not hurt the design.

And throughout the discussion one thing became evident: that the mastery of a technique will also come with the knowledge of its shortcomings and therefore with the knowledge of what to do when, not to use a simple if that approach.

When publicizing methodologies, or more importantly, popularizing methodologies, things tend to get a little bit more complicated. To enable others to learn, simple schemas are created, which are easy to follow. Examples are created, as to show how the application of a method can work. Often the underlying principles are omitted for the sake of simplicity and clarity. And, sadly enough, the simplifications can win over the underlying principles.

It is a fairly easy to understand and easy to explain rule to write testcases in a way, that the function you test is completly isolated, independent of other parts of the code. This will affect the design, as the developer will write his code to make that as easy as possible. The problem is: if the design for the test wins over the design for the function of the program, something is actually wrong. This is even more true, as the “rule” which requires these design changes in itself is wrong, because it is overly simplified and was never intended in that way.

I find the situation similar with “agile” and “SCRUM”. Many people obviously do not know, that these are actually two different things. Many of the same people would shout “no, we have no rigid processes, we are agile, we do SCRUM” while following the book slavishly, meticulously and to the comma, applicability nonewithstanding. I see some irony in there.

So I wonder: might it be the case, that the more we learn and understand, the more we abhore the scripts, the schemas, the oversimplifications? Might it be that with all the background knowledge we see all the errors in them and want to prevent “beginners” to start “with a flawed script”, even though we started that way ourselves?

Or is it just the way that we do not want some people to sell oversimplifications as “the real things” to people starting the craft?

I for myself am not completely clear about it. But I tend to think it is the latter, as it is one thing to start with the basics, and to teach a script at start, and another to teach the script as the whole and only truth.

I conclude that everybody should remember that the world is a compex and complicated place. As a physicist I have learned, that even simple models are helpful and can allow for predictions. But as you learn more about the systems you model, you learn about the subtleties, the higher order effects, the non-linearities and so forth. And as a physicist you learn to remember that you talk about a model, not the truth. A model, which has its use and has its boundaries.

The world is complex and complicated. Easy and straightforward solutions therefore will only bring you that far. Therefore always remember to dig deeper and beware of oversimplifcations.

This post is also available in: German

One thought on “Musings on Simplifications and Adoption of Methods

  1. I think you have hit on a good point there. A standard is a good place for the novice to start. But once you have experience and skill a standard becomes to restraining and almost dangerous.
    When I started out I was testing wildly, testing by instinct. After a year or so I decided to get some training. This testing lark seemed like a hoot, so let’s get down to doing it proper like. 14 years ago the ISEB was the certification to have. On the course I learnt a lot. Mostly the correct terms for the work I was already doing. I also found that some of the ‘theory’ didn’t quite line up with the real world. Which is why I had some ‘discussions’ with the trainer. I did eventually learn what the exam wanted and passed. From this point I know knew the basics and had a foundation to build on.
    Later and I naturally progressed and became a lead and then a test manager I decided to looking into solidifying my test manager status. After around 10 years of testing I was told by a couple of trainers and colleagues that I knew too much and was too good to take the ISTQB Advanced Test Manager exam and would struggle because the theory was just out of line with what works in reality. After reading half the course book I tend to agree. So I stopped.
    I’m not saying I’m the perfect test manager. In fact I know I don’t know half of the testing craft. Our craft is ever evolving and changing; which is one of the reasons I love testing. Every project is new: new solutions that need new ways to test; new people with new ideas that help to grow and improve the job at hand; new technology that can aid or corrupt testing and so on.
    As I typed this out the first time, before losing it, two things sprung to mind:
    Firstly: What’s the difference between a text book written by the opponents to a standard, and the standard they oppose? The work ‘Standard’ and it’s implications. They can both be used to instruct someone in one aspect of testing and provide useful information to launch/mature a tester.
    Second: I thought of a good way to explain how to use a standard.
    A standard is a good way to stabilise your wobbly tables. If your test process is wobble, use a standard to stabilise it; if however you employ experience and skilled test professionals, let them do their job and use the standard to stabilise the wobbly coffee table down the local café.

Leave a Reply

Your email address will not be published. Required fields are marked *


Time limit is exhausted. Please reload CAPTCHA.