The Quality Maturity Model

The Quality Maturity Model

Republished with permission from Kristin’s excellent blog, thinkingtester.com.

One year ago, the company I work for adopted something we dubbed the “Quality Maturity Model”. It’s a model to help teams measure how they are doing with behaviors that support creating quality applications. The project has been a big success, so I’ve decided to share some details about it with the world!

We started out by coming up with a definition of quality. Using this excellent blog post as a jumping-off point, we defined the seven Attributes of Quality at Paylocity. A quality application is:

Valuable: It meets the customer’s needs.

Functional: It does what we say it does, and we can measure those interactions.

Reliable: It is available when needed.

Secure: It protects customer and company information.

Performant: It responds within an acceptable time.

Usable: It is easy and intuitive to use.

Maintainable: It is easy to test, deploy, automate, monitor, update, and scale.

After defining these attributes, we created a list of behaviors for development teams to help ensure those attributes are part of our products. For each of the behaviors, we determined what a minimum version of that behavior would look like, what a standard version would look like, and what excellent would look like. From there, we created the Quality Maturity Model.

Here are some examples of the behaviors defined in the Quality Maturity Model:

Valuable: Team identifies and investigates customer needs.

Functional: Team creates, executes, monitors, and maintains reliable test automation.

Reliable: Team actively monitors the health of their applications and takes appropriate action as needed.

Secure: Team creates and adheres to a security strategy following security best practices.

Performant: Team consistently meets SLO standards for their product.

Usable: Team ensures the product is usable on multiple devices and supported browsers/platforms when applicable.

Maintainable: Team manages and owns their deployments following the release management process.

We rolled out the Quality Maturity Model to all the teams and asked them to identify which of these behaviors they were already demonstrating. From there, we asked teams to create quarterly goals to adopt more of the behaviors. Quality leaders were each assigned a group of teams to meet with monthly to help answer any questions and hold teams accountable.

After a year of working on the adoption of the model, we’ve made significant progress! Here are some examples:

A team committed to having the whole team own the test automation. The team works together to make sure that tests aren’t duplicated; for example, if a unit test already covers what’s needed to test a feature, there’s no need to write a UI test. This saves the team significant time in test creation and maintenance, freeing them up to focus on new features.

Another team made sure that the whole team knew how to use the UI automation framework. A developer was able to undertake a complete regression test on the UI work he was doing and fix all the bugs he found without involving anyone else on the team.

One tester on a team created a reusable test plan so the developers would be able to determine what to test. When both the testers on the team were on leave at the same time, the developers were able to carry on with feature development and testing with no problems.

A team was able to use the progress they made in test automation to speed up their release times from once a month to twice a month.

If you are looking for a way to enhance the quality of your product, minimize escaped defects, and speed up your delivery time, the Quality Maturity Model may be a great way to help. I recommend starting a discussion with the leaders at your company about what quality behaviors you’d like to see in your teams!