R&D Learning From QA
May 13th, 2006[ Software Development ]
A developer primarily talks to the Quality Assurance (QA) team in a meeting about code they’ve written, the ‘how am I going to test your code out’ meeting. Outside of those rare meetings, developers communicate with QA mostly through issues in a bug tracker.
Every software release contains a certain number of bugs. It is generally assumed that the number of bugs is a function of the lines of code written.
This is an oversimplification resulting in the belief that the only way to reduce the bug count is to reduce new lines of code. The real formula is something far messier like:
Where E represents the working environment. This mess includes the personalities of everyone involved in building the software, the level of trust between those people, the state of communications, etc.
Once something is measured it receives attention. The bookkeeping, and counting, of bugs related to the software development process contributes to the myth of the first formula. Posting and fixing bugs presents the appearance of work accomplished regardless of the reality. The goal of most QA departments is to find and post bugs, not find, post bugs and work with the rest of the company to keep a similar bug from appearing again.
The vast majority of bugs could be caught during the development process. They’re not bugs as much as they are change requests, often related to usability or product consistency. I have yet to work somewhere that has an ongoing, explicit goal of decreasing the number of bugs per release? In other words, write better code. I don’t mean finding bugs and making sure they don’t go out in the release, that’s a given. I mean taking it a step further and using bugs as a means of influence to the development process itself.
Position QA less as a quality enforcement department, more as a learning department. Task both the development and QA teams with improving as a single group from release to release. In this scenario, QA and development are very much part of the same team. QA members don’t simply point out what’s wrong with a developer’s work, they talk to each other and determine where things went wrong and if there’s a way that it could be done better next time around. QA moves into a role of teacher and source of learning for developers. It’s not perfect but it’s a start. It demands a certain type of developer, ie one with less ego than most.
Unfortunately I don’t think this learning process can be a formal one. It must be left to the overall project team to find ways to learn from the bugs that were found and fixed. Mistakes become tools to get better as a team.