Uncharted Waters

Nov 17 2017   8:54AM GMT

The Software Testing Pendulum

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Tags:
Development
Software testing

DHH (aka David Heinemeier Hansson, the creator of Ruby on Rails) wrote a blog post in the last week about the value of human exploratory testing. Usage of tools to make software development more sustainable has taken a massive leap in the last 5 years. There are all manner of programming frameworks and APIs available, most for free, to help people test code. There has also been a deluge of build and deploy tooling that helps us move from code to a running, testable environment in a matter of minutes or less.

That tooling created a mind shift (or maybe the mind shift created the tooling?) leading part of the dev world to think that they could build smaller, test more granular via tooling, and get away without much of what we call exploratory interaction. This has worked in some domains, but not so well in others. The testers reading this are screaming “I told you so”.

DHH’s post is short, and short on details, but it is important because he wrote it. Development trends seem happen in a pendulum and this might be the beginning of a shift back.

I’ll start with a brief history. Software development began as a one man band. Developers were responsible for sussing everything out — requirements, code, testing, deployment, you name it. Over time, people realized that, hey, there are a lot of distinct skill sets embedded in that work. Over the next many years we end up with the late 90’s early 2000’s cubical farms and separation of concerns. Those farms had people specializing in development, testing, and all the various business functions. Slide forward in time a few more years and there a few companies returning to the developer plus business function model. Those developers write little bits of code,  test mostly using tools, and deliver as soon as those lines are done.

While people like DHH with massive platforms make seemingly important statements, I have my own opinions. Both of those conditions, heavy tool usage and a human exploratory touch, are required to build good software in a sustainable way. To borrow an analogy, think about testing space as the near shore ocean. There is a gradual increase in depth near the shore, and then a shelf where things drop off and get scary and you can’t see the bottom. The deeper the water, the harder the fishing (or testing). Development practices and tooling help to make the water more shallow so we can find fish (and software bugs) more easily.

Developers won’t find everything that is important, of course. They are focused on the task of building and releasing new software and aren’t necessarily in a mind set to discover the ways it won’t work. This is where people in the test role come in. My take is that these development practices and testers (probably fewer of them, but more skilled, are dependent on each other to make a good product. Choosing only one approach, development practices or a lot of people in a testing role, is just foolish.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: