When we started developing CloudSwing we decided to develop CloudSwing as if quality actually matters. By quality i don’t just mean that the code functions as designed. High quality products also meet the needs of the business and customers.
In the past there has been a sense of disconnection between the business, QA and development parts of our team. (An all too common situation in my experience.) If quality actually matters there must be good connections between all the stakeholders and quality must be considered at every step of the process. We don’t have a product manager, or a large QA team2. That means that if quality is going to be considered at every step it is going to be because the developers are doing it, there is no one else at many of the steps.
Our solution is to acknowledge developer responsibility for all aspects of feature development. That unification reduces the chances of things being overlooked. It does change the workload of developers, though. Now developers must:
- elicit requirements from all stakeholders
- write testable acceptance criteria
- develop automated acceptance tests
- implement the feature
- verify all acceptance (included pre-existing ones) pass
- verify that the feature, as implemented, matches the desire of the champion
- deploy changes to production
This has lightened the load on QA to the point that our one QA resource can keep up with four developers. QA still has a lot of responsibility:
- verify the acceptance criteria make sense
- verify the acceptance criteria is testable
- verify the acceptance criteria cover all important variations of the feature
- verify the acceptance tests cover all important variations
- refine acceptance tests
- verify all tests pass in a production like environment
- perform visual inspections in various browsers
- accept features into the production branch
We have been using this version3 of the process for a while now. I think is has worked really well. In fact, during our last retrospective our QA guy stated that he thought our quality management processes belonged in the “Good things” category. I think that is a first i have ever heard a QA person be so positive about processes.
Only time will tell if this approach produces significantly better results but I am very optimistic. So far it seems to have created a world of difference.
In practice the process is more fluid that it looks in the diagram. Developers are empowered to do what it takes to get the job done. Including not following the process. However, not following the process requires an affirmative defense when QA asks “WTF?”.
The QA team we do have is super top notch, though.
It has taken a lot iterative refinements to get to this version of the process.