Selling Software Quality to the Project Team


In my ideal software development world… “Quality is everybody’s job”. If you could help negotiate and create that world where quality is everybody’s job, what would your Quality Contract Proposal to the project team be? Recently I submitted to my project team something similar to this:

Team Quality Tasks

  • Communication

    • Daily, morning 5-10 minute stand-up meetings for quick progress and issue reporting
    • Team notification of document and code changes

  • Documentation

    • Requirements required
    • All documents are stored in a common area for easy access, check-in/out and versioning (e.g. SharePoint)

  • Code Reviews

    • Large code reviews are scheduled during stand-ups
    • Peer code review before check-in for small or quick changes

  • Use of Development & QA metric tools

Developer Quality Tasks

  • Unit Testing

  • Builds

    • Dedicated build box for build integration.
    • Build and test on check-in.
    • Build and unit test run schedules (e.g. hourly, daily).
    • Automated build success and failure notifications.
    • Build Integration rules

      • Get latest from source control, merge, compile, and unit tests success before source control check-in.

    • Official builds released to test

      • Starts on functional section code completion. 
      • Developer collaboration and agreement on release time and contents.
      • An owner for release to test (owner checks with team to ensure release readiness).

  • Provide “Quality Hooks” that don’t impact performance or usability (e.g.)

    • Use of special image naming.
    • Use of special ID and name attributes.

Tester Quality Tasks

  • Participation in design meetings and discussions.
  • Review and feedback of requirements draft document.
  • Review of Developer unit tests to provide suggestions for improvement as well as get a better feel how/where to provide further test coverage.
  • Testing

    • Functional

      • Testing starts on functional section code completion
      • Utilizes test case libraries for common tests (HTML elements)

    • Automation

      • Scripting starts on functional section code completion

    • Performance, Load, & Scalability (typical and per functional unit if needed)
    • Other

Some of these items may apply to your company or team and some may not. Each has its benefit, each has its cost. In my experience the benefit outweighs the cost. Wouldn’t you agree that this Quality Contract Proposal is a good place to start? Do you think it it may be a little far fetched for your company or current process? How about starting smaller then? Throw the list out there and get the team to commit to 25% of the items. When the project is over, take the lessons learned and infrastructure built from that 25% and use them in the next project, but now since that 25% is tried and true, ask for 25% more. Then 25% more…Get my drift?

Baby steps are okay. Be a salesman for software quality, negotiate that Quality Contract!

One Response to Selling Software Quality to the Project Team

  1. JakeBrake says:

    Hi Brent,

    You might find the following relevant and/or useful in getting people to consider quality ownership.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.