Definition by Dave:
Developer Driven Quality is a system of software development in
which the software developer assures near zero defect quality of a product.
Holding Developers Accountable
The traditional model of throwing software “over the wall” to QA pushes
responsibility for software quality to a group least empowered to affect it.
Testers can merely report what they find, they cannot pro-actively avoid defects.
It is unreasonable to hold QA staff accountable for software quality when
it was not they who control the manner in which the software was created.
Developers, particularly architects and managers, control most aspects of software
quality in an organization. Tracking individual programmer defect rates and
addressing them one developer at a time will show an immediate change in behavior.
Value Defect Avoidance
It sure is great that your QA team can find all 205 bugs that exist in the software.
It sure is great that we can track and assign and fix and retest and apologize and
document and re-deploy the software and pretend that we are doing a good job.
You might think that holding developers accountable is a simple process of tracking
defects assigned to an individual and then shaming them publicly. Uh, no.
Our goal is keep defects out of our software in the first place,
not to identify and fix defects before we ship.
What Can Developers Do Differently?
While there are whole books on this subject, I will highlight what I think are the
three most impactful things that developers can do for themselves to add quality to
their software. These things do not require whole other departments or cooperation
from QA. These are simply things that developers can do today (literally today)
that will improve their software that is open in the IDE right now.
Code Reviews
Code reviews are undoubtedly the cheapest and quickest way to improve software quality,
but the manner in which they are implemented is the most important aspect of ensuring
that they work. For code reviews to prevent defects from entering our repository, they
must occur before the code is committed. By definition, this means
that reviews should be frequent and ad-hoc. Code reviews are more likely
to succeed in a team with a culture of collaboration.Ship It! by Jared Richardson and Will Gwaltney provides an excellent model for
code reviews. Bottom line – do not check in your code unless another set
of eyes has seen it.Test Driven Development
You know it. I know it. It feels like a waste of time. It isn’t.
While we all know we should be doing TDD, but we aren’t. Why not?
Excuse #1 My software in maintenance doesn’t
lend itself to unit tests (see Designing for Testability below). It
isn’t modular. Sure, I know better now, but this software already exists.Refactoring your software is a huge component of making it better. We all know
that we write it cleaner the 2nd time around, so go ahead and do it. The next
time you have a defect to fix in your code, DO NOT check it in without a unit test
to prove that the defect has been fixed. This will require you to figure out
a way to get the test to run. This may require refactoring the design.
This is a good thing. Just do it.Excuse #2 Writing the unit tests takes longer than
writing the code.If your are doing it correctly, you are right. The base assumption is that defect
avoidance is preferable to defect detection, therefore this is a good thing.
Just do it.Excuse #3 That’s what we have testers for.
OK, so let the testers extend the unit tests in a separate name space just for them
within the unit test binary. This gives you the best of both worlds and now
“testers” can automate their regression testing in the form of unit tests,
making the process repeatable upon demand. I know of one product that currently
takes >40 work hours to test in a black box manual test scenario and this product
could be re-factored to be unit tested in minutes.Use your testers on new and evolving software, not proving that your current products
still work. Testers are wasted when we ask them to spend their time regressing
that same functionality for the 5th time. Let them engage new features that
don’t have automated regression yet.This is a good thing. Just do it.
Designing for Testability
The next logical step toward ensuring that defects do not enter our software is to
design with automated testing as a foregone conclusion. To easily apply automated
tests, our software must give access to the tests. This means using abstraction
layers for functionality and writing software layers to be as thin as possible.If you think this way when you put software together, it will engender good design
as a side effect.
Bottom Line
Asking developers to implement techniques that have a proven positive impact on software
quality is not asking too much from them. If developers will simply do these
things for one week, relationships with QA members will improve to the point of maybe
even eating lunch together.