04/05/2023

Standardising quality assurance with IBM iX’s Quality Approach

Author: Boris Arapovic

The IBM iX Quality Engineering team collaborated with developers, Scrum Masters and Product Owners on a blueprint for a Quality Approach to serve as a starting point for all software development projects in terms of quality assurance.

Companies often have several projects running at the same time. Some of them are just starting, others are nearing completion, and others still are ongoing with no end in sight. In this dynamic environment, the quality of projects can vary widely. The challenge for any company is to balance the need for standardised quality assurance with the need to give project teams the freedom necessary to work effectively. The key is to set clear and concise guidelines that provide a sense of direction without being overly restrictive. Defining standards can ensure that all projects meet a certain level of quality.

The Quality Approach

One of the key elements of our Quality Approach is the incorporation of best practices. This helps us to keep our quality engineers and teams aware of our standards and expectations. Another important aspect of our Quality Approach is simplicity. We aim to keep our approach as lightweight and straightforward as possible, including only the information that is relevant. This blueprint is typically introduced by our Quality Engineers in projects, and it ensures that everyone is on the same page when it comes to key topics, such as:

Relevant test types

To make sure that we are testing the right things, we have created a list of test types for the team to choose from. These test types also include mandatory tests that should be considered for any project, such as penetration or performance testing. To make the information easier to understand, we use the Agile Testing Quadrants to cluster the test types. For each test type, our blueprint provides detailed descriptions and recommendations so that the team knows exactly what they need to do. However, it is also possible for the team to take a different path than what we suggest.

Committed test types for automation

Automation is a critical part of quality assurance, and we want to make sure that we automate the right things in the right way. The project team decides on the test types and how to automate them. To help the team get started, we provide them with boilerplate repositories (for example, a boilerplate for UI test automation with Cypress), so they don’t have to start from scratch.

Required test environments

To ensure proper testing of a product, we recommend that our teams have at least two test environments – one for testing newly developed features during a sprint and another for testing full releases. Having multiple test environments allows for thorough testing at various stages of development and reduces the risk of bugs and errors.

Test design guidelines

Our project team members can rely on our Top 10 testing heuristics to guide their testing on a given feature. These heuristics are influenced by Elisabeth Hendrickson’s book, Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing. Teams can use the “Zero, One, Many heuristics” from our testing guidelines. For example, if they need to test a number field – say, for age – this approach involves testing for different inputs, such as providing no input, entering the number 0, selecting a number within the expected range (29) and using a number outside the expected range (1,000).

Bug management

Bugs can be frustrating, but with a proper bug policy, they can be managed effectively. The project team decides on the bug policy, but our teams can use and customise our bug template and “zero bug policy” process provided in the blueprint.

Browser matrix

Testing on different browsers and devices is essential, and we want to make sure that we are testing on the right browsers and devices. The project team decides which ones require it, while the blueprint provides the team with a template and our best practice browser matrix, so they know exactly what to do.

Why do we need a blueprint?

At IBM iX, we understand all too well the challenges of balancing quality assurance and the project team’s freedom. Our development teams are focused on delivering top-quality projects, and maintaining this level of excellence requires a careful balancing act. As a result, we have worked with our Quality Engineering team to develop a blueprint to help us meet quality standards while giving our teams the freedom they need.

What is important to us?

When we created the Quality Approach, we had clear objectives: to incorporate best practices, to set standards, to keep it simple and to make it adaptable to different contexts. By following this approach, we can ensure the quality of our projects while encouraging innovation. We believe that giving our teams the freedom to adapt the Quality Approach to the needs of their specific projects is critical to fostering innovation and creativity. By allowing teams to tailor the approach to their needs, we can ensure that they have the tools and resources they need to be successful.

In the end, the success of a software development project depends on striking the right balance between standardising quality assurance and giving project teams the freedom necessary to work effectively. The IBM iX Quality Engineering team, in cooperation with other Scrum roles, has developed a blueprint for Quality Approach that serves as a starting point for every project in terms of quality assurance. This blueprint covers key topics such as relevant test types, committed test types for automation and required test environments. By following this approach, we aim to ensure the quality of our projects while supporting innovation and creativity.

Share

What else drives us

Composable Digital Experience Platform

Learn more

Industries at a glance

People at IBM iX

Join the Women in Tech Community

How to accelerate hyper-personalisation in marketing with generative AI