If you have spent any time immersed in the world of software testing, you have probably come across James Bach. James is a noted thought leader, author, blogger, speaker, proponent and developer of exploratory testing, creator of the Rapid Software Testing ™ methodology, and all-around disrupter.
James is known for his outspoken criticism of the Agile development and testing methodology. In fact, in a sea of conferences, publications, and people singing the praises of Agile, James and his comrade-in-thought-leadership, Michael Bolton are among the few with a different tune.
The website description of James’ brainchild, Rapid Software Testing, sheds light on the software testing philosophy James ascribes to:
“The philosophy of rapid testing…is not like traditional approaches to testing, which ignore the thinking part of testing and instead advocate never ending paperwork.”
The description goes on to state that the Rapid Software Testing methodology is designed to eliminate superfluous work and use testing to accelerate a project’s progress through heuristic-based exploratory testing.
Given that RST and Agile were developed at roughly the same time, it seems natural that both methodologies would address issues common to the software development and testing world at the time. But how closely parallel are these two methodologies today?
Chelsea: What do you think of the Agile movement and do you find it to be compatible with RST?
James: [The Agile movement and RST] are certainly compatible. But there is also a big tension between them. Agile came about because of the same kind of forces that caused me to create RST. During the 90s, we were trying to break out of these long-standing patterns (i.e.: since about 1972) of falsely rational, reductionist, mechanistic ways of developing software. In my community we called that the “factory school” of software development. Waterfall is one example of factory development, but there are other factory-oriented variations as well.
There is a strong tendency to move towards factory styles of work. Agile is very prone to this as well. Managers, i.e., non-technical capitalists, want control over their capital. Often, it is us humans and our creative thinking that threatens control. Factory-style work helps to consolidate that control. Waterfall is certainly an expression of that work method, but Agile, unfortunately, has become about that control all over again.
The original spark of Agile was to say, “how does software development actually work, and by understanding that, how can we work with another process that can control what we are doing, but integrate our humanity into it?” One thing that drew me to Agile in the 90s was that it was all about humanism – understanding how we work and incorporating it into the development process.
One thing that Agile has going for it, is that it understands learning. It has learning theory built into it, whereas waterfall completely ignores learning. If you look at the factory-style models of development, at no time will you see anyone admit that anyone has to learn anything at all. The assumption is that if you are handed a document containing the specs, you now know and understand. It doesn’t work that way! First I have to read it, and highlight it, and question it, and show some models to the client to see if I understood what they wanted – these waterfall type processes always seem to assume that this happens instantaneously and telepathically.
So Agile came along to turn that upside down, and to make learning – and for that matter – error, a central part of the process. Waterfall says “do it right the first time”. Agile says “make it so easy to correct your mistakes that we don’t mind making them”. That way we don’t need to do it right the first time because we don’t know how to do it right the first time.
RST is based on the same issue: reality. I was looking at how people actually test software – not how they pretend to test software. At first there seemed to be a lot of affinity between Agile and RST, but there is also a big difference. Agile was created by developers, for the convenience of developers. It was not created with an understanding of what good testing is. It was created in part, with the intent of throwing away bad testing. As Cem Kaner puts it, Agile was created partly by firing all of the testers.
But that type of testing was also the type of testing I was trying to get rid of – that is, to create a whole bunch of test cases, document up to your eyeballs, and then slavishly follow these cases, hoping to find the bugs.
Unfortunately, Agile seemed to very quickly bring “factory thinking” back. Whenever you allow a process to entrap you, and you forget that humans are in charge, you are back to factory thinking. That is the basic difference between the factory mindset and the humanist mindset.
I hear from people in Scrum who talk about being trapped by the Scrum process – the cards, and the sprints – and really, it is an age old problem. The problem goes back to Socrates and even before: people create processes, and then they forget that they created the process and have the power to change it.
Chelsea: It is easy to become slaves to a process. It seems to be cyclical in nature, doesn’t it? We see humanity doing it over and over: striving for a certain freedom, finding it, systematizing it to make it safe, becoming a slave to the system, and then pushing against it until we break free again.
James: If you analyze the history of technology development that way, you will see a lot of that. But this isn’t just a silly little mistake we keep making. It’s deep. Even if you know this dynamic is going on, and you see yourself becoming entrapped in a process, you cannot just throw it away. It’s the same way I cannot just get married, and then a couple of years later say, “well there are some disadvantages to this, I guess I will just get a divorce”. You think, “well now I have kids and we share a house – making that break is really complicated”. It’s the same with these testing and development processes – once you have become entwined with the process, it’s not so easy to make a change.
Making that change is possible, but it takes time and skill. It requires discipline and a knowledge of self. Now many people don’t ascribe to this sort of philosophical thinking and they just want to cut the Gordian Knot and say “ok, well we will make everything Scrum”. But if you don’t work to solve the problem, you are just precipitating that factory thinking.