Max Kosyakov's Wiki

Blindfolded Carpentry

Radical Summary: Software developers are responsible for software quality end-to-end. Testing each task using a separate QA tester is wasteful and often harmful.

Elaboration

Imagine a blind carpenter who is making a table. But since he can’t see, he has to send the table to another person to assess, whether the table is finished yet. That other person looks at it, and says either “No, not finished, keep working” or “Yep, good enough, it’s done”. One cannot do woodworking, the other cannot see. So they keep passing the table to each other.

This is what is observed in a lot of software development organisations1: developers don’t close the task, they pass their results to another person who does the testing. This is extremely wasteful and in most cases is counter-productive. Human — human communication is weak and unreliable, requires a lot of effort, allows information loss.

The blind carpentry approach often co-exists with sansara issue tracking.

Chicken-And-Egg Approach

Let’s try to fix/optimise this process with a classical QMS/ISO9001 approach:

  • introduce formal rules for bug reporting,
  • introduce formal rules for developer’s hand-off procedure,
  • create training materials for new hires, current employees,
  • conduct periodic training for the team members,
  • hire a supervisor, who will ensure that the formal procedures are followed,
  • oh! by the way, we need to ensure competency, so we need to provide certification for developers and QA testers before they work on the actual software.
  • … and just shoot me before you hire another Scrum Master to “help” with “agile transformation”

At some point, these management consultants will stumble upon the cornerstone question:

  • When exactly must a developer pass work to a QA tester?
  • What are the criteria for this transition?

It would look something like this:

Generic definition of done:

  • all requirements are satisfied,
  • no prior existing functionality is broken.

Perfect! Before developer can pass the work to a QA, the developer must test everything. Makes sense! In order to start testing, we need to test it first.

Solution

The solution seems to be fairly simple: the developer is responsible for the quality of the software. No hand-off, work transitions, no communication bottlenecks, no wait time.

The while (not DoD.satisfied) { develop; test; } cycle is internalised in each engineer’s personal workflow. Each engineer can then optimise their work and summon all the help they need, but information loss and waste are minimal. A lot of organisations adopt this approach and it works well.

Hmm… But if the developer has already tested that all requirements are satisfied, and nothing else is broken, why do we need to have another person do exactly the same work? (spoiler: we don’t)

Independent Quality Assurance?

Why do we even have an idea that we need an independent quality assurance? This idea looks very foreign to the engineering world at least. How come we don’t trust the task assignee to ensure the quality of the result? If the assignee doesn’t care, why do they come to work at all?

Maybe this idea came from low-motivated factory workers who can waste a lot of raw materials on low quality production before it is noticed. Maybe we cannot trust them since they don’t associate themselves with the result of their work.

For engineers, however, quality of their work is at the core of their motivation. If an engineer doesn’t care, maybe they should not be an engineer. Babysitting engineers with another “independent” tester feels like a patch, not a fix.

Space for QA as A Separate Role

In larger projects there’s integration and verification work that can fall through the cracks of individual tasks. In the V-model of system development a dedicated technical team may be required to automate verification of higher level of design: architecture, fitness for business, etc. This engineering team is tasked to maintain high-level QA routines to test expected (and discover unexpected) emergent properties of the developed system, to provide feedback to architects, business analysts and other stakeholders.

Footnotes

  1. In the third decade of the 21st century, we still observe organisations employing QA personnel that tests tasks after developers. ↩

Backlinks