No Testing, No Agile and No Software Delivery

As a part of day 3 of #20DaysofTesting at XING AG challenge, I was expected to read one blog and comment on it. But the blog I have chosen to comment on has rather encouraged me to write a blog instead of just leaving a comment.

While reading some interesting discussion around testing and “100% test automation” thing, I stumbled upon “No Testing” blog by flowchainsensei (aka Bob Marshall) shared by one of the participants in discussion (thanks Nilanjan).

This is an interesting post I must say, particularly because the arguments and ideas presented by Bob made me ponder and encouraged me to think critically about the value of my own profession i.e. Software Testing, yet again.

The blog is bit old and I don’t know if Bob’s opinions have changed but I would like to discuss around some ideas he has expressed in his blog. I must mention that this blogpost is not a response to Bob in person, I have great respect for his work and I admire his writing around Agile/Software delivery. I decided to discuss the ideas from his blog mainly because I still come across people who share similar opinions. This post is my humble attempt to explain what I think about those opinions as a “passionate tester”.

If I have understood Bob correctly, his key arguments are something like below and I believe that majority of the fans of “no testing” idea share them (more or less):

1. It’s possible to deliver a software that ‘just works’ without having to “test” it as such
2. Customers are unkeen to pay for testing
3. Testing adds little or no value from customer’s point of view, then why to invest in it?
4. One of the needs testing addresses is that, “Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.”
5. If there is any possibility that we can get folk’s needs met by some other strategy than testing, which is most economic and most human.

Alternative to testing:

While I tried to think deeply about the above argument in the list, I felt that it is indeed possible and is being already done by testers who understand what testing really is, who know how to test software rapidly, inexpensively and in a way that would still stand up to scrutiny. It is already being done by testers who know how to do “more with less”. The only difference is, they still call that strategy as ‘testing’ but hey, what’s in the name as long as it does what matters?

I would not hold it against Bob (or anyone else with similar opinions) if they want to find alternative for “testing” (whatever it might mean to them) because it’s possible that what they saw someone doing as “testing” was not more than filling excel-sheets with Pass/Fail and being a bottle-neck for deliveries. If that makes them want to find alternative to ‘testing’ or getting rid of it completely then I can totally understand it.

The good part is, testing is far beyond just a process, profession, phase or strategy for most of the thinking testers today. For us (thinking testers) Testing is a performance as James Bach rightly says. And the number of testers who think this way is growing like never before.

Testing is needed so that testers can earn their living:

This can’t be really true anymore, at-least for the testers who know how to add value with their work and what their worth is in software development. I completely understand the humanitarian aspect here but with due respect I deny that ‘testing’ is needed so that “testers” continue to earn their living. This holds equally true for all sort of professions in software field for you never know what would science discover tomorrow.

Today, earning the respect of peers appears an overrated issue to me, to be honest. If non-testers understand how “testing” helps their work then there is not any reason why someone would disrespect testers. How can someone’s ignorance be someone else’s problem? As a matter of fact, I have seen programmers feeling envy of their testing/QA counterparts for the kind of weight they hold in a team and the way testers get treated as project-trusted advisors. I have seen programmers who do not understand the difference between writing a code “that does what specification says” and to “develop a product that customer would like to buy/use”. Does that mean “programmers” have a respect issue? I don’t think so. Respect issue with testers probably gets highlighted because they are far less in numbers compared to their programmer counterparts (1:4 I guess?) and unfortunately, bad testers continue to outnumber the better ones. Slowly but surely, this is changing for better.

Testing adds little or no value from customer’s point of view

The value testing can add to the project can be best summarized by Bob’s excellent definitions Quality and core purpose of Software Development.

According to Bob, the core purpose of Software Development is, “to create elements of complete products or services. Complete products or services, which attend to – and hopefully meet – the emotional, human needs of a variety of interested people”

Bob’s definition of Quality says, “It is meeting the needs of some several collections of people” and I agree with that in principle.

Meaningful testing caters to ensure exactly those and if that’s not a value then what else is? And most importantly, customer or anyone for that matter would understand this value provided by “testing” only if they know that “testing” has a role to play in it. Do we give up on better practices, making better technological choices just because customer fails to understand them? No, instead we help them understand what they really want and how best we (as service providers) can do that for them. Why to give up on testing then if customer does not know its worth?

Customers are unkeen to pay for testing

I feel that customers are unkeen to pay more for “entire cost of software development” and not just for testing in particular. Customers want a quality product at a price they can afford. Whether to do it by cutting the testing short, with no testing at all or by employing testers who know their job very well, is service provider’s problem. And I feel there is a lot of other waste we need to get rid of apart from bad testing. I would highly recommend checking out “Lean Software Delivery” by Matt Heusser if you are curious to know more about this subject.


It’s possible to deliver software that "just works" without having to “test” it

I admit it is possible as long as our "it works" matches with customer's expectations and user experience. But ensuring that they match is hardly possible without doing any testing.

Some years ago, I had asked same question to Jerry Weinberg and his response was detailed enough for me, not to think about that possibility anymore.

I asked Jerry if there is any method/strategy that can eliminate the need of testing or testers as a role. Jerry’s response below:

You're kidding, right?

This is a pipe dream of managers who do not know how to manage s/w development, just like their dream that some magic method will allow them to get rid of developers. "Tester" might not be a job description, but "testing" had better be part of somebody's job description--and taken seriously.

Over more than 50 years, I have watched managers fall for these illusions. Sure, it would be nice to be able to develop s/w without testing, or without developers. Indeed, it would be nice to become a billionaire without leaving your easy chair in front of the TV. But just because it would be nice, that doesn't mean we know how to do it.

The only times when I've seen s/w developed w/o testing, the s/w produced was not usable, and nobody wanted it. So, I guess if nobody wants the s/w, it could be developed w/o testing.

Heck, I could cook a fabulous meal as long as nobody wanted to eat it and live through the experience.

The times are changing fast and the pace with which science is advancing, I sometimes feel, "Would humans be ever needed in future to build software for customers? What if they build a computer that reads the requirements and delivers the software just like a pizza fresh from oven?"

“No Testing, No Agile and No Software Delivery” attempts to flag up these questions. No soapbox. Just open enquiry.