Why product quality should always be a shared responsibility

With the average 90 day drop out rate for apps hitting over 70%, it’s more important than ever that you can offer seamless user experiences, fast loading times, and bug-free apps. And to implement this well, quality needs to be an integral part of your development process.

The evolution of QA

How many testers does it take to ensure that you produce a quality product? The answer varies depending on who you talk to. In some organisations the ratio of developers to testers might be 5:1, in others it will be closer to 2:1. Often, QA Engineers are thought of as the people who just write and run tests, and if you look back at the traditional Waterfall software development model, then it’s easy to understand why.

In this model, testing is a separate and later stage, and development hands over the product to testers once they believe that they have finished with their work. As you can imagine (or might have experienced yourself) there are significant drawbacks to this approach:

• Slow feedback cycles. Saving testing until last means you risk discovering serious product faults late in the development cycle, leading to go to market delays, as issues have to be sent back to the developers for rework. Or you can have the opposite problem: deadline pressures outweigh quality concerns and testing is rushed or skipped altogether. Bugs and issues are discovered post-release, which can damage a product reputation.

• Disconnected responsibility. It goes without saying that catching design flaws and defects early on in product development will save you costly rework time. But by keeping the development and testing processes separate, you also lose any vital inputs a QA would bring to the product development approach that could catch potential issues before they are even developed. It can also relieve developers from taking a critical view of their own work, or contemplating where issues might arise in their programming practices.

Agile approaches

As an alternative to the Waterfall approach, Agile practices are often adopted. As Gary Hamel once observed, “You can't build an adaptable organisation without adaptable people - and individuals change only when they have to, or when they want to.” This often means that although an organisation intends to become agile, people often fall back into old habits, and the development process can then resemble an incremental waterfall model. Features are still developed without much interaction and collaboration with the QA Engineers, and handover still happens at the end of the process.

Although this resolves some of the issues of the Waterfall model by shortening feedback loops and bringing feature testing into closer alignment with feature development, there are still issues:

• Slow resolution times. Features are still being tested after they are developed. The feedback loops might be shorter, but by the time issues are raised, developers will have to switch contexts and abandon new feature development to solve the issues.

• Bottlenecks hindering progress. Developers and QA Engineers are still waiting on availability of each other in order to make progress

Other interpretations of Agile have led to further advances in bringing QA practices and development closer together, these include:

• QAs developing the test scripts for a feature whilst development of it is still underway.
• Utilising Test Driven Development (TDD) approaches, so that tests are written inline with development code.

Both of these processes speed up testing timeframes, and can ensure that testing becomes a more integrated part of the product development process, but neither of them truly integrates QA into a lean product delivery team, or requires the wider team to take on responsibility for overall product quality.

Integrating a QA mindset into product development

In the International Software Testing Qualifications Board (ISTQB) foundation course the subject of Tester’s and Developer’s mindsets is discussed. It shows that successful developers and testers often have different mindsets.

“A tester’s mindset should include curiosity, professional pessimism, a critical eye, attention to detail, and a motivation for good and positive communications and relationships.”

“A developer’s mindset may include some of the elements of a tester’s mindset, but successful developers are often more interested in designing and building solutions than in contemplating what might be wrong with those solutions.”

Source: ISTQB syllabus

Therefore integrating a QA mindset into product development, first starts with bridging the gap between development and QA practices.

Making quality a shared responsibility

Most problems boil down to communication problems. Overall quality can be improved by looking at when in the software development process developers, QA Engineers and other team members communicate and how they are encouraged to work together.

When we looked at the evolution of QA, we saw that communication was often at the end of a task. When a developer finished their unit of work, they would then communicate with the QA engineer and potentially offer a summary of that unit of work to allow the QA engineer to proceed with their unit of work or vice versa. In order to improve this relationship and communication, a more collaborative approach needs to be adopted, which often starts with reviewing team structures and responsibilities.

In traditional engineering teams you would typically have specialists for each area. A queue of work might go through an architect, a database expert, the front-ender, the back-ender, and then eventually the QA.

By making QAs, or for that matter any role within the team a segregated specialist, you create dividing lines of responsibility, and mental siloes around who should problem solve which element of a project. Individuals are less likely to step outside their comfort zone to help or invest in a wider problem, and quality will also be seen as a separate step or something added on solely by the expertise a QA brings to the team.

A better approach lies in creating small multidisciplinary squads, where individuals are encouraged to be T-shaped. Each team member can still bring expertise or champion a particular area, but they are not solely responsible for this specialism. In teams that function this way, quality - in the same way as everything else - becomes a shared responsibility. QA best practices are built in from the start, and both developers and QAs work simultaneously on enhancing the quality of the product.

What it looks like in practice

A product delivery team will be made up of a small squad of developers, designers and QAs, each offering input and support from their specialisms.

All team members are present throughout the entire life cycle of a feature and so can decide on expected behaviours and outcomes, both happy paths and negative paths. There are no hand-offs or communication bottlenecks, decisions are made quickly, progress is fast.

As behaviours are decided before work has begun, test scenarios are created in the form of Acceptance Criteria, enabling developers to write the functional regression tests (as well as unit and integration tests). The ability to run tests and implement quality checks is held by all, overall product quality is enhanced

QA engineers act as champions for quality, providing guidance, keeping up with QA best practices and enabling all members of the team to learn and develop their own QA skills. You end up with a team that is empowered to make better software development decisions.

The bottom line

The simplest and most cost effective way to ensure the quality of your final product is to integrate QA practices from project kick off. The QA is a specialist role, but they add the most value when working cross-functionally across a wider team, and when quality becomes a shared responsibility, rather than a cause they are left to champion on their own.