Uncharted Waters

Oct 29 2018   10:02AM GMT

Modern Test Fundamentals – Test Improvement

Matt Heusser Matt Heusser Profile: Matt Heusser

Tags:
Lean
Software
Software testing
Testing

Surfing the Waterfall for Test Improvement

The other day I was talking to Jim Holmes about test improvement. He pointed out that just starting out with Exploratory Testing is only improving one area in isolation. Working on that one system cannot transform the entire organization. Jim isn’t alone, Fred Brooks argued the same thing in his 1986 essay No Silver Bullets: Essence and Accident in Software Engineering.  Brooks borrowed the subtitle “Essence and Accident”, from Aristotle.

I would argue that starting with test can provide the opportunity to improve the entire organization.

Let me tell you how.

Test Improvement In Isolation Is Easy

For most of the 1980’s, the leading theories on test improvement were in fact to improve everything else. For example, to have a complete, consistent, correct specification, to “get involved up front” and get “executive buy-in.” Basically, everyone else needed to change to make the job of testing easier.

If you look at context driven testing, turn your head sideways and squint, you can almost see the subtext of “Let’s stop telling everyone else what to do and start trying to do a really good job at testing ourselves. Along the way we’ll stop asking other people how to do our jobs and take responsibility for making our behavior meet the needs of the customer and team.”

At the time, Context Driven Testing was as revolutionary within test as the Agile Manifesto was for software development.

The best part about that approach is that it doesn’t require getting any buy-in. You don’t need to talk to HR about job descriptions. Many of the ideas and techniques slide right in, or replace the way work was done. And, as Ron Jeffries once told me “You don’t need to ask for permission. It’s not like management really knows what you are doing, anyway.” The outputs of the job don’t change much. Bug reporting, coverage and other forms of communication improve as the person doing testing changes to meet the evolving needs of the team, instead o of following an external standard.

So there you go. Test improvement as a quick win. As Fred Brooks points out, it is unlikely to be a “silver bullet”, as testing is only a small percentage of time and budget.

Keep reading.

Lean Improvement Through The Backdoor

Cycle Time Lean Test ImprovementMy little company, Excelon Development, covers the entire delivery process, but our reputation is in testing. That seems to work out just fine, and most of the software organizations we work with have problems in testing. Testing takes too long, there are too many bugs, and so on. In fact, testing takes so long that the development staff often juggle three to ten pieces of work at one time – some in requirements, some under active development, some in test, some blocked by a question.

The truth is that everything takes too long, everything is buggy, and multitasking is destroying productivity.

In that world, one of the easiest things to do is to radically reduce feedback time from build to bug reports. Radically. Compress it from days to minutes, or minutes to real time, as the testers ride along during development. In lean terms, we radically reduce the cycle time of feature testing.

What we really have is probably a quality problem, or a fixing problem. It only looks like a testing problem because of the multitasking, the delays, and the inefficiency of test. So we make test wildly more productive, which does improve overall productivity a bit. More importantly, removing the test problem makes other organizational dysfunctions manifest.

Let me say it.

Go ahead, start with test improvement. You can make things better without changing job titles or re-orgs or spending money. Be proud of it. Once you are done, the real mess will become clear.

Then, roll up your sleeves.

We still have work to do.

 

1  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.
  • MattGriscom
    I never understood the value of "context-driven" testing as being any different from any other activity in our lives: context-driven driving means that context outside your vehicle includes a telephone pole, so take care to not hit it. Context-driven cooking means considering the context of the meal: how many people? How hungry? What do they like to eat, what do they expect, etc. Context-driven discussions mean that one has to stop talking and really listen to others sometimes.

    Please help me understand: what does "context driven" add to software quality or process, that isn't already there?
    10 pointsBadges:
    report

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: