SM on Gun-toting leftist for sanity…
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.
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:
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.
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.
Small is beautiful. I’ll expand on that tomorrow.
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…
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:
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|
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”.
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.
I just saw a story about how writing can be therapeutic. God knows I can use some therapy. Retirement isn’t easy… or is it?
Today is a drinking day. I’m retired. I’ll drink when I like. But also I’m a park host and want to serve our guests.
Cindy is in California with her sister for a.two-week vacation. Huh? A vacation from retirement? Perhaps it’s just a side trip.
Ooos… I gotta go run tell Alex that we moved to Owyhee Lake State Park.
For more from me, watch this space….and twitter and LinkedIn and FB.
Good, I an edit after publishing: Test case fails because it found no problem. Still, it was a good test to run. Should it go back into the testing queue? IMO No, it should be deleted in favor of production use. <EOM>