Right brain, left brain

Summary: As my journey toward reconciling the two halves of my brain continues, I have realized that my left brain (the analytical half) is building scaffolding out toward my right brain (the feelings half).

The rest of the story:

I smoke pot.  There it is right here in print. Deal with that how you will.

Did pot smoking change my life? Absolutely. I’ll address those changes in later posts. In keeping with my goal of doing things in-the-small, today I want to focus on feelings

My parents were my role models. My home was Ozzy and Harriot supportive. But feelings were 

Posted in Uncategorized | Leave a comment

Better quality from less testing

Alternative titles:

  • Death of the Iron Triangle
  • Attributes Testing for Software
  • Quality Driven Development

Part 1: Using test matrices to prioritize your testing and risk taking

Part 2: Iron Triangle demise: Project constraints are product variables, too

Part 3: Flow stuff: Smaller increments are better


Posted in Uncategorized | Leave a comment

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