Developing software as if quality matters

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

New feature development process1


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.


  1. 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?”.

  2. The QA team we do have is super top notch, though.

  3. It has taken a lot iterative refinements to get to this version of the process.

7 thoughts on “Developing software as if quality matters

  1. I have been enjoying this process and I think that there is closer collaboration between dev and qa. It seems like the team as a whole has higher confidence in the product than I have experienced before.

  2. One concern/question I have is the placement of responsibility for writing the acceptance criteria on the developer. There is a feedback loop to the business, but I like to see the business own the writing of the acceptance criteria. Shouldn’t the business know best what constitutes accepting the development of the feature?

  3. Susan, i understand that perspective. If you are in an organization where the business actually has the capability and capacity to produce acceptance criteria i’d says that is great. I have rarely, if ever, worked in such an organization. My experience is that the business and users usually have a quite vague conception of how what they want should fit into the product. They know what they would like to accomplish (the goal), but they are less certain, or concerned, about how it should be accomplished. When this is the case they are probably not able to write testable acceptance criteria.

    If you have a very capable product management team i would consider using them to produce detailed feature requests with high level acceptance criteria. If they are able the product management team could even include proposed concrete acceptance criteria. The development and QA would, obviously, make any modification necessary to make those testable.

  4. Great flow chart medium… I bet it captures brain storming better than Visio.

Comments are closed.