Quality management elevator speech

“So, what do you do?” asks the company president.

Influential people ask these things. It’s a valid question and deserves a solid answer AND it is a great opportunity gain a strong ally.  She truly wants to know my general approach to managing quality… software quality assurance is, after all, still a rapidly evolving field.

Here’s my short answer… my hierarchy of quality building blocks:

  • Build the powerhouse
  • Get the house in order
  • Stop the bleeding
  • Minimize the losses

What do we do first? Stop the bleeding.

If the bleeding stops, we find the cause and eradicate an entire family of errors. And that tends to get our house in order.  That’s a good day’s work.

If  the bleeding won’t stop, we minimize the losses.

And we build the powerhouse whenever we have earned the opportunity.


Posted in Uncategorized | Leave a comment

Tester location scenarios

Tester location scenarios

Image | Posted on by | Leave a comment

What Testers Do

A recent tweet claimed, rightly, that we testers lose effectiveness when we cannot describe what we do and what we are doing.  I agree.  And toward having a general response to that “What do you do?” question, I submit the following…

What testers do

What we testers do – given enough knowledge and wisdom – is create new paradigms that will help us better explain and manage quality.
5 – create paradigms
4 – extend state of the art of testing
3 – create and manage quality systems
2 – master best known practices
1 – test code and documentation 

We don’t manage bugs. We don’t test the things that don’t need testing.

Posted in Uncategorized | Leave a comment

Quality in-the-small

Summary: Quality driven dev, when dialed to 11, can quickly reduce error rates to near zero.  At least that’s the theory.


Big Bang fails too big. Frequent delivery fails more often and provides better learning opportunities. That’s a huge improvement. Quality-driven dev, which focuses agile dev on salient quality factors, can further improve dev results. 

Operational definition of “quality”

    Q(total) = f (q1, q2, … qn) 

That is… for any cycle, quality is some function of the salient quality factors in your context. 

Knowing your context, *you* are responsible for defining quality for your customers. If you want someone else to define and manage your quality, you are sinking not swimming.

If this sounds like a heavy responsibility, relax, here is a theoretical life preserver:

  • Atomize and timebox your cycles
  • Select ONE QF as the driver
  • Ignore other QFs (!)
  • Make your code change(s)
  • Run your acceptance tests for that QF

If you have concerns about potential side effects (e.g. a focus on security may have affected performance), then explore or rerun the tests for this other QF (in this example, performance).

The theory is that as cycle time approaches zero, the risk associated with ignoring secondary QFs also goes to zero.

My recommendation is to try this at home… or at least with an engaged customer.

I’d love to hear your results.

Posted in Uncategorized | Leave a comment

Quality: Velocity’s other factor 

In the real world, velocity has two components: direction and speed.

In software development, speed is all. And that is wrong. We need direction and QDD supplies it.
The general idea behind quality driven development (QDD) is that we can direct our efforts toward one important quality attribute for a small time box and accurately predict our results.
Turning the dial to 11.  Suppose we have very short time boxes. We can focus on one quality attribute for the time box (limiting cognitive WIP). 

The rhythm is this… choose a quality, ask some questions, specify some test cases, modify some code to pass those cases, and take a break. 

Suppose our time box is 25 minutes and suppose security is the most important attribute at the moment.

Questions: What would give us better security? SQL insertion prevention? Smaller attack surface? Fewer null address derefs? 

You decide. Only you know the relevant measures in your contexts. Work together.

Big Idea

Small is beautiful.  I’ll expand on that tomorrow.

Posted in Uncategorized | Leave a comment

QDD – Quality Driven Development

QDD – Quality Driven Development for planning and tracking

Okay all y’all software quality folk and teammates.  I want to propose another approach to evaluating software quality in real time before, during, and after development and deployment.  Follow me on this… I’d like your feedback.

TDD – everyone knows what Test Driven Development is, right?  It goes like this…

  1. adopt an automated test framework, then
  2. iteratively
    • add a test,
    • run the test batch,
    • add just enough code to pass the test,
    • rerun the test batch, then
    • tidy up the code.
  3. post / publish / push into inventory
  4. respond to customer/production feedback

TDD can provide great feature/function test coverage when coupled with exploratory testing.  And that once was the goal of QA… but that’s for another post.

QDD – this is a new term in our industry… at least when used in this manner.*  The QDD process:

  1. adopt a time-boxed development rhythm,
  2. iteratively
    • identify salient (most important) qualities
    • plan their measurement
    • select landing zones (upper and lower limits)
    • evaluate and manage the risk associated with the other qualities
  3. constantly evaluate attainment
  4. post / publish / push into inventory

Here’s an example sprint-level QDD plan:

Quality Goal Measurement Metric Minimum Limit Maximum Limit
Salient qualities for this sprint UX Customer delight “Recommend?” Top Two Boxes 50.00% 90.00%
Reliability Product issues MTBF 4 hrs 10 hrs
Affordability Sticker shock GSR “Cool” “OMG”

Note: We introduced in the several McAfee business units as GQMFURPS.

I believe QDD provides a medium that yields team alignment and useful decision-support info.  Helping teams set QDD goals – and tracking progress against those goals – seems like a worthwhile use of your QA resources freed up by TDD.

I further believe that QDD is a subset of QDx.

Please share your thoughts.

Note: See also Vic Basilli’s GQM+Strategies and Rebecca Wirfs-Brock and Joe Yoder’s writings on transitioning from QA to Agile Quality.

* Funnily enough, one site lists “QDD” as “Quality (QA) Driven Development”.

Posted in Uncategorized | Leave a comment

Nice game, Mick.

My best ballgame.

Baseball, for those who play, is a wonderful past time.  I had the pleasure of playing third base in a classic game.

T’was the 1968 season.  Mick Johnson was pitching for Newberg High School.  We were playing St. Helens at home.

Newberg was not a baseball powerhouse in those days but with the Swede Johnson family, we had very strong pitching.  Jerry Johnson spent some time in the Houston Astros organization after going undefeated his senior year at Oregon State University.  I had his autograph pinned the my wall as young teen.  Brothers Mick and Steve took Mt. Hood CC to nationals and finished fourth one year.

Anyway, Mick was spot on that spring day 1968.  And I watched from feet away.

The first St. Helens batter hit a Texas Leaguer into center. Our center fielder apparently didn’t know the game had started… the ball dropped about 20 feet in front of him.

A single.  That’s all that St. Helens got that day.

The next batter hit a slow roller to Dave Beecroft at second.  Dave, steady as always, fielded it cleanly and threw him out at first.  The other runner rounded second and headed for third.  John Gander, our first baseman, fired the ball across the infield to me at third.  Tag, you’re out.

That’s better… two batters, two outs. Go Tigers.

Mick got the next batter… and the next 18 batters.  Other than that first bloop single, Mick threw a perfect game.

For my money, it was a perfect game.

Posted in Uncategorized | Leave a comment