Often, the main focus of quality assurance is testing software and fixing defects. However the acts of assuring your development processes and practices are equally important.
A strong quality assurance practice helps government departments provide citizens with products and services they can trust. There are numerous ways to strengthen a quality assurance programme, from hiring quality analysts with top market skills to performing assurance in an agile environment. There are also many common mistakes made when thinking about the wider aspect of quality assurance, with my top four listed below.
More on quality assurance best practice can be found in our recently updated Service Manual documents.
1. Outsourcing your quality assurance
External quality analysts, who look at your product from the outside, can be objective but they don’t have the same insight as internal analysts. This insight provides a depth of understanding that is vital when ensuring quality. Also internal quality analysts will make sure that assurance takes place across the development team, throughout the development process, and this leads to a stronger overall product quality.
2. Assuming agile working provides assurance
Just because your team is agile doesn’t mean that they will necessarily produce products of the highest quality. Sometimes this is assumed because an agile environment by its nature performs continuous checks and tests on a product. However, you’ll still need the discipline of quality assurance in your agile project to agree and meet standards, provide assurance feedback and assert assurance best practices.
3. Being rigid
What’s ‘good’ for one project may not suit another. Creating rigid assurance principles that apply to all projects is a waste of time and won’t work, e.g. a multi-supplier programme of work will likely have very different needs to a small single supplier project. (Think centralised online issue management tools, vs Post-Its on a wall.)
To add value, your quality analysts need to understand the ins and outs of your development project, such as your user needs, why certain technology is being delivered, and which agile method is used. Otherwise, your project’s assurance may not fit the process you are using and may not add value.
Whilst there are cases to be made for best practice principles, you’ll need to make these flexible and adapt them to fit different projects, teams and business areas. Assurance can help projects be successful, rather than ensure things are done in a particular way.
4. Using assurance as a proxy for good practice
It’s easy for a development team to solely rely on the assurance team to identify and fix all their product issues. This puts undue pressure on the assurance team and often leads to problems in the product’s development.
Encourage a culture where team members take responsibility for the quality of everything they do. The assurance team may be the vanguard of your approach to quality, but lots of your project’s testing tasks can be undertaken by anyone with the right skills. This encourages team ownership of quality and helps all team members gain knowledge of the assurance process. It also frees up the assurance team to perform additional areas of analysis, such as market comparisons of product features.
Don’t forget to sign up to the Government Technology blog.