Beta This is new guidance. Complete our quick 5-question survey to help us improve it.

  1. Service manual
  2. Technology
  3. Quality assurance: testing your service regularly

You need to test your service regularly to make sure that it:

  • is easy to use for anyone who needs to use it, regardless of the device they’re using
  • is stable, secure and works quickly, regardless of how many people need to use it
  • can be iterated quickly to meet changes to user needs or the political environment

This is called quality assurance (QA).

Meeting the Digital Service Standard

You must continually test and improve the quality of your service so that you meet the Digital Service Standard and pass your service assessments.

You’ll have to show that you’re checking:

  • security, legal or privacy issues that might affect your service
  • the value and performance of the technology you’ve chosen to build your service

Involving the whole team

The service manager has overall responsibility for maintaining the quality of a service. However, because quality relates to every part of a service, the service manager should make sure all members of the team know how to:

  • set goals for quality and measure the service’s performance against them
  • identify problems with any aspect of your service
  • take action to fix any issues and improve quality

Testing for quality

You won’t know how good your product is until you test it in simulations of both normal and unusual conditions (eg when your service has lots of visitors or is attacked).

Testing for quality helps you:

  • build the best system you can
  • make sure your service does what your users need it to do
  • build your service at a cost that is acceptable to your organisation (cost being money, business change, risk, etc)

How to do testing in agile

As part of using agile methods, you need to test in a way that confirms the following as quickly as possible:

  • your code works the way you expect it to
  • your service is protected against malicious attacks
  • iterating your code won’t introduce bugs

When you’re testing your technology, automate as much of it as possible. For example, using a continuous integration system (where your tests form part of your codebase) means you’ll test your code automatically every time you make a change.

Getting fast feedback at a time when it’s useful means you can respond quickly and make changes when you need to. You can also spot bugs before they develop into bigger problems that are more complicated and expensive to fix.

Types of testing

You should run different types of test depending on what you need to check, for example:

Balancing technical debt

‘Technical debt’ is any compromise you make on quality to develop something quickly in the short-term. The extra effort (or ‘interest’) required to improve what you’ve built is something you’ll have to make (or ‘pay back’) in future.

As your technical debt grows, your code will become more difficult to work with. This means adding new features will get harder, take longer and introduce more bugs.

If you decide it’s necessary to compromise on quality so you can deliver something quickly, your team needs to understand the implications of taking on technical debt. You should also agree a plan for keeping it under control.

Learn one of the ways GOV.UK managed technical debt.

Working with QA specialists

A QA specialist can help you:

  • coordinate all activities related to QA testing
  • give teams the training and guidance they need to build quality into their work

You may find it’s useful to hire experts from outside your team, especially for some types of testing, eg penetration testing.

Find QA specialists on the Digital Marketplace.

Testing other aspects of your service

QA activities usually focus on the technical aspects of your service. However, you should take a broader view of quality and also consider the usability of your service.

You’ll need to regularly test and iterate the content and design of your service so that users can complete it easily first time.

For more on this, see: How user research improves service design.

You may find these guides useful:

Published by:
Technology community (technical architecture)
Last update:

Guidance first published