A system can be a great communication tool between teams.

The problem with many Quality Assurance teams nowadays is the emphasis on early automation. The entire process is tuned to automate everything and anything as a significant form of testing.

To summarize today's problem in QA, Testing = Automation.

A traditional approach to Software Development has evolved to be more agile. The more I think about the teams I have worked with and the approach to QA in each of these teams, the more I realize that it reflects a traditional design process.

A design process, specifically a digital product design process is iterative in nature.

Every product is unique and so is the process by which it takes shape. Though the core steps, irrespective of the terminology remain the same. A product design process can be summarized as:

• Research

• Analyse

• Ideate

• Test

For a Quality Assurance Team, the process mirrors the product design process while the output is a set of deliverables that highlight the system's adherence to the specification.

Typically, a Quality Engineer goes through the steps:

• Understanding the requirement

• Analyzing the target system and user

• Designing the tests

• Execution of the tests

The two approaches work in an iterative mode until the desired outcome is reached.

One question is at the core of both of these teams. In the case of Product Design, it is -

When does the design process end?

In the case of Quality Assurance, it is -

When to stop testing?

At their core, both these teams and their processes are looking at the same goal - The End User Experience.

As a Quality Architect, there is always a struggle to highlight the ideology behind a Quality Assurance team to either the developers or to the management.

Maybe if the world of Quality Assurance worked closely and in accordance with a product design process, the overlap of ideologies can paint a pretty picture of the relevance of a QA process.