Let us examine the consequences of “Developers Own Quality”.
Quality is already in the code at the time when it is delivered to the QA team
In other words, the code meets all functionality and performance objectives. The obvious consequence – as suggested by Extreme Programming (XP), and Agile Software Development – is that, in addition to writing code, developers must also test it. More importantly, developers own the results of these tests.
Too often, I have heard developers claim that their task was complete once they had provided Unit Tests along with their code. Writing unit tests is a good thing, it is an important and necessary step, but it is far from sufficient. Rather, developers must take a results-oriented approach to testing, and ask themselves: do my tests PROVE that my code works?
Beyond a comprehensive suite of unit tests, which validate basic operation of the code, two main areas must be addressed: (a) integration and (b) performance.
Integration testing leads us to another XP and Agile best practice: frequent integration releases (or milestones) to ensure that all newly contributed code plays well together. For example, two developers will have often a different interpretation of an API. While each may have done the right thing in their own mind, and pass their individually created tests, the code, once integrated, will not work.
So, why ask developers, rather than QA, to test integration and performance? It is simply a matter of efficiency.
The process of releasing code to QA, having QA set up their test environments, find a bug, make sure it really is a bug, file a bug, assign the bug, re-run the test for the developer, wait for the fix, verify the fix, verify that the fix did not break anything else that worked before, and finally close the bug, is just too long a process. It should only occur in exceptional circumstances, or in controlled situations (more later).
To me it is also a matter of pride. As a developer, I need to be confident that I deliver solid work-product to my teammates. Finding a serious bug in my code (whether functional, or performance), once I have released it, should be a major embarrassment. I often tell my team – jokingly – “If QA finds a Severity 1 or 2 bug in your code, you owe me fifty bucks!”, as an illustration of the level of confidence and pride that one should have in one’s code.
In summary, comprehensive testing, is part and parcel of development. A developer who is proud of his/her code, and proves that it meets all functional, integration and performance requirements, is not only an efficient developer, but someone who makes his/her whole team efficient.
I agree. If the answer to “Who owns quality” is anything other then “I do” it’s wrong. The trick is getting people to translate those words into actions. I don’t like acting as the quality police giving demerits for low unit coverage or the introduction of warnings found by static analysis. Besides those are just metrics that are easy to capture. What about the unmeasured 99%? If you have ideas on promoting a culture of quality I’d love to hear them.
Great point.
First and foremost, quality has to be a state of mind. We agree that sometimes it is a challenge to ensure that all developers have, or acquire, this state of mind. This is why I talked about pride of one’s code. If the pride is not there, then I don’t think there are any tools, or metrics, that can inject quality back into the product.
If engineers don’t get it emotionally, then maybe they’ll understand that, overall, it takes a lot less time to do it “right the first time”. The back-and-forth exchanges with the QA team end up sucking a lot of time.
Finally, and I’ll address this in an upcoming post, saying that the developer “owns quality” does not mean that he/she writes all the test code, or runs all the tests. This can/should be done in partnership with the QA team. Similarly, the tools, metrics and exit criteria should be decided by the project team. They can vary on a project by project basis, and even by milestone within a project.