Why a QA should know the business domain and the architecture.
Whenever I get started on a new project, I first learn the business domain and the architecture, and only then start to look into the stories.
Some of the managers I worked with find it unnecessary, thinking “ What would a QA do with an understanding of the architecture?? QA should just go to User story and sign it off after validating the Acceptance Criteria (AC)”.
In my experience, knowing the architecture and the business domain helps a QA identify much more hidden errors in the whole end to end flow, can give you more understanding and confidence on the product when you know it all. Such insights also help ensure user satisfaction.
A QA should have expertise in the business domain and in the architecture on which the Application-Under-Test (AUT) is built to ensure quality & functionality to the User.
What does it mean to know the business domain / Architecture and why :
So, there is a technical perspective & a business perspective. Dev handles most of the technical perspectives & business as well depending on the AC.
But, when a QA combines both and then writes the cases, then there are chances of finding the errors rather than checking just the response code.
Understanding the domain helps us simulate the end user’s actions and workflows . This applies throughout the life cycle of the product.
How it helps the QA & business in turn :
User satisfaction :
Understanding and having the knowledge at the back of your mind helps ensure that the User is satisfied with the app.
Your app could be a social media app, or Legal, or healthcare..
The QA is supposed to test the app as an end user, and not just verify what the specification of API says, or acceptance criteria are defined. Read more about exploratory testing.
QA can play a role to challenge/ suggest the AC / specifications by gradually gaining expertise and insights in the business domain and the customer experience
Early feedback :
The issues can be identified earlier by understanding the exact business requirements of the end user before the client reviews the application
By understanding the business domain, the QA can understand the actual risk/impact of the unstated scenarios.
e.g. If you are in the banking domain, you should know which and how different regions/ countries have different account number formats, the laws/regulations for the same, and why some country expects a data in specific formats.
Finding the most common but easily missed defects:
Even if QAs are not the final gatekeepers, they should know how the app should behave in different situations.
The domain knowledge gives the ability to find the most common but easily missed defects.
These days with all the unit testing, reviews and processes in place by Dev’s, effective testing no longer comprises of just keying in some wrong data.
Understanding the architecture and the workflow, will help find the hidden errors
e.g. in any end to end flow, if you understand the architecture and verify the responses from all the systems in between, you can understand the error app is giving in a much better way and can find more issues around complex build component.
Finding the root cause is easier :
This can help dig in more and explain the defect better – as in which exact component of the system has issues rather than saying there is an error in the AUT.
With domain knowledge & knowing the architecture of the system, testers will be able to make better user-driven choices and create a solid experience for their specific functions.