The Essence of Testing: Interview With James Bach, Part 1
The Essence of Testing: Interview With James Bach, Part 1
An expert in exploratory software testing discusses the right kind of mentality and culture it takes to achieve true testing sucess.
Join the DZone community and get the full member experience.Join For Free
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. Throw any of the popular software testing buzzwords his way – Agile, DevOps, Exploratory Testing – and you will probably get an answer unlike anything you’ve heard before.
There are plenty of people talking about Agile and DevOps. Conferences and testing publications are full of rhapsodic praise, best practices, digital transformation tips – and rightfully so. The popular Agile Manifesto written in the 90s sparked a domino-effect of ideas and testing methodologies that have since revolutionized, and often improved, the way we develop and test software.
However, James and his comrade-in-thought-leadership, Michael Bolton, take a different approach. Rather than ascribing to a process like Agile or DevOps, they ascribe to critical thinking. Within their philosophy, any work in any organization should be born of creative, solution-oriented critical thinking. How often does that actually occur in reality? Less than you would think.
Taking all of these thoughts in hand, I asked James to weigh in.
Chelsea: You have stated before that Agile is not necessarily designed to be compatible with software testing. Where do you think the disconnect lies?
James: The essence of testing is the attitude that says, “You think things are ok, but it is not necessarily so.” It’s a tester’s job to believe that things are probably not ok. If they don’t, they’ll fall asleep and not do their job, which can have disastrous consequences. So you have to cultivate this belief, which is a sort of faith, that there are bugs. You don’t know where they are, but they have to be somewhere.
Unfortunately, Agile leads you to cultivate the opposite type of faith: that things are probably ok. So even though Agile often promotes the task of testing, they don’t promote the intellectual attitude that is a necessary precursor to good testing. That’s why Agile and I don’t get along very well.
A lot of Agilists don’t understand the techniques, tools, and creative, wandering aspects of test design and testing. Most Agilists are focused on development, so they have never studied testing. This can very quickly lead to that factory thinking that says, “let’s create a bunch of tests, put them into an automation tool, and just run it.”
There are many examples of testing tools that were not created by testers or for testing. They were created to turn testing into a programming activity. You see that a lot these days. And it’s not black and white because there is a good reason to want to turn testing into a programming problem. You hear people saying, “we have such a big system, we have to update it twice a day, there just isn’t time for manual testing – let’s use a tool, write a bunch of test cases, and just let the machine run it.”
But the problem is that you could make the same argument about programming. You could say, “we don’t have time to program or code our system, so let’s just create a tool that writes the code for us.” That doesn’t really work. You can do a lot by using open-source code and pre-existing libraries. You can actually get along by not writing a lot of code, but there are tremendous downsides to that in the area of security, quality, performance – everyone is looking for shortcuts. There are some good shortcuts out there, but they pose their own dangers. If you are going to take those shortcuts responsibly, you need to be aware of what those dangers are.
I think the downside of the start-up culture is that there is a tendency to ignore all the risks and rush headlong into something new, regardless of whether it is well thought out or secure. Why didn’t they make it secure from the beginning?
The nature of a tester is to say, “it might not work,” while the nature of an entrepreneur or creator is to say, “well, let’s try it anyways.” It goes against the tester’s nature, but it is an engine of change.
Chelsea: It’s a catalyst. Without that thinking, nothing new would necessarily be made. That friction creates the electricity that drives innovation forward.
James: So the solution – a difficult solution that requires a lot of emotional intelligence – is to realize that the tension between that spirit of risk cultivation (the entrepreneurial mentality) and responsible spirit (the testing mentality) must be maintained. It is not easy to maintain that tension, but it must be maintained in order to be successful in a responsible way.
Chelsea: What do you do when that entrepreneurial spirit and the responsible spirit are co-existing in the same person? How does that person move forward when they are constantly wrestling with their own tension?
James: I have defined my own personal driving heuristic as “alternation.” By that, I mean that I sometimes rock like a metronome towards, “I’m going to take a risk!” and then I rock backwards a little later and say, “Ok, I want to calm things down now – I need to consolidate what I have and make sure I am protected.” I think that is how they co-exist – in a sort of braided fashion, where there are two types of thread and they are braided together. That creates a strong fabric.
I think this is common – I think it is how we humans lurch through life. You need to reach a point in your life where you realize that when you live life “forward” there are a lot of missteps and that is ok. That’s the way it is. And if it is that way, you can stop worrying about it.
I guess the theme of this whole conversation is temperance. Temperance is not a “one or the other,” it’s a blending, a bringing of things together that are not necessarily compatible but you can make them work and hold them closely together.
*Reposted from the Tricentis blog.
Published at DZone with permission of Chelsea Frischknecht , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.