Imagine you want to build a house for your family, but you don’t know where to start. A good starting point would be to gather all the family members and understand their requirements, must-haves, good-to-haves, etc.

Once requirements are jotted down, they serve as guidelines for blueprint creation whilst architects and contractors determine the feasibility of the project prior to any effort going into building a house.

Since QA Engineers interact with the application regularly and have vast product domain knowledge they can be a driving force to be reckoned within PRD review cycle with the four R’s strategy.

4R’s Strategy Recognise In this phase, QA Engineers understand the problem, vision statement, and target audience. Then they brainstorm stated workflows, which helps in understanding the value that can be added to the business.

Relate This step focuses on connecting with the system’s existing limitations and pain points and visualising the global context from the bounded context.

Relay In this step, the QA’s and product team discuss all the pain points, spanning across highlighting ambiguities, test strategies, and potential risks. Hence, becoming transparent about the impact on existing functionalities within the application.

Reinforce/Revamp After a thorough understanding of business value, potential risk, impact, and discussion; PRD is ready for T-shirt sizing.

Any gaps between requirements and engineering efforts will be resolved and estimations will eventually become more accurate.

If any changes are required PRD can be updated to address feedback provided by QA engineers.

Advantages

1. Engineering Effort Optimised Knowing exactly what outcome to expect from a system and having a thorough understanding of features under development by the engineering team will yield high accuracy and less wastage of resources

2. Time Saved Generally measuring twice cut once approach saves a lot of time as it reduces the risk of error which may incur more time and effort just to fix an error which implies that effort not spent on fixing an unwanted system outcome that might be out of scope adds up to saved time.

3. Cost Saved Time saved results in more efficient engineering operations thus avoiding any cost overheads.

4. Deliverable expectations met It’s a big win to deliver exactly what the end-user wants thus closing in on any gaps between ambiguity and assumptions on the engineering end through such a rigorous review process by QA who happens to have the most domain knowledge of a product.

5. Domain understanding It’s vital to understand Why, Where, and When. Having a clear idea about the target audience and targeted domain and its overall business objective helps in understanding negative as well positive use cases.

6. System Breakpoints identified Limitations and breakpoints of the system highlighted in early stages of SDLC, before development work even begins.

7. Test/Requirement Analysis kicked off Test Requirement analysis is initiated automatically as QA understands the requirements and having pre-existing domain knowledge will assist in drawing reference for metrics of success and failures for testing. It is further followed by test planning test designs, breaking down functional, non-functional flows of the system

8. Precise Technical Requirement Documentation Technical Requirements are clear with concrete implementation

9. Expectation consistent across Engineering team

Disadvantages Prone to failure in absence of async communication within stakeholders. Developers might be blocked on implementation until reviews are finalised. Multiple review iterations are required in case of changing requirements which may in effect take some time.

Statistics In order to quantify the significance of involving QA’s in product requirement document review; We have come up with a unique matrix that shows change requests or bugs reported by the product team or beta users post-development.

Reduction in feedback as QA engineers’ review processes matured and their involvement increased over the course of features 1–4.

Improving trends are the epitome of reduced gaps between product expectation and execution.

This is only possible by adopting the four R’s strategy by QA engineers in PRD review processes from the word go.

No.of Change Requests Reported / Feature Conclusion

In light of the above facts, we can safely say the PRD review involving QA engineers in the early phases of SDLC is ideal. It is also recommended as per software development literature thus throwing shackles off the conventional mindset about diminishing role of QA’s and its value-added within the system. Hence making them an impeccable part of a de-centralised, empowered, and informed Engineering team.

Imagine you want to build a house for your family, but you don’t know where to start. A good starting point would be to gather all the family members and understand their requirements, must-haves, good-to-haves, etc.

Once requirements are jotted down, they serve as guidelines for blueprint creation whilst architects and contractors determine the feasibility of the project prior to any effort going into building a house.

Since QA Engineers interact with the application regularly and have vast product domain knowledge they can be a driving force to be reckoned within PRD review cycle with the four R’s strategy.

4R’s Strategy Recognise In this phase, QA Engineers understand the problem, vision statement, and target audience. Then they brainstorm stated workflows, which helps in understanding the value that can be added to the business.

Relate This step focuses on connecting with the system’s existing limitations and pain points and visualising the global context from the bounded context.

Relay In this step, the QA’s and product team discuss all the pain points, spanning across highlighting ambiguities, test strategies, and potential risks. Hence, becoming transparent about the impact on existing functionalities within the application.

Reinforce/Revamp After a thorough understanding of business value, potential risk, impact, and discussion; PRD is ready for T-shirt sizing.

Any gaps between requirements and engineering efforts will be resolved and estimations will eventually become more accurate.

If any changes are required PRD can be updated to address feedback provided by QA engineers.

Advantages

1. Engineering Effort Optimised Knowing exactly what outcome to expect from a system and having a thorough understanding of features under development by the engineering team will yield high accuracy and less wastage of resources

2. Time Saved Generally measuring twice cut once approach saves a lot of time as it reduces the risk of error which may incur more time and effort just to fix an error which implies that effort not spent on fixing an unwanted system outcome that might be out of scope adds up to saved time.

3. Cost Saved Time saved results in more efficient engineering operations thus avoiding any cost overheads.

4. Deliverable expectations met It’s a big win to deliver exactly what the end-user wants thus closing in on any gaps between ambiguity and assumptions on the engineering end through such a rigorous review process by QA who happens to have the most domain knowledge of a product.

5. Domain understanding It’s vital to understand Why, Where, and When. Having a clear idea about the target audience and targeted domain and its overall business objective helps in understanding negative as well positive use cases.

6. System Breakpoints identified Limitations and breakpoints of the system highlighted in early stages of SDLC, before development work even begins.

7. Test/Requirement Analysis kicked off Test Requirement analysis is initiated automatically as QA understands the requirements and having pre-existing domain knowledge will assist in drawing reference for metrics of success and failures for testing. It is further followed by test planning test designs, breaking down functional, non-functional flows of the system

8. Precise Technical Requirement Documentation Technical Requirements are clear with concrete implementation

9. Expectation consistent across Engineering team

Disadvantages Prone to failure in absence of async communication within stakeholders. Developers might be blocked on implementation until reviews are finalised. Multiple review iterations are required in case of changing requirements which may in effect take some time.

Statistics In order to quantify the significance of involving QA’s in product requirement document review; We have come up with a unique matrix that shows change requests or bugs reported by the product team or beta users post-development.

Reduction in feedback as QA engineers’ review processes matured and their involvement increased over the course of features 1–4.

Improving trends are the epitome of reduced gaps between product expectation and execution.

This is only possible by adopting the four R’s strategy by QA engineers in PRD review processes from the word go.

No.of Change Requests Reported / Feature Conclusion

In light of the above facts, we can safely say the PRD review involving QA engineers in the early phases of SDLC is ideal. It is also recommended as per software development literature thus throwing shackles off the conventional mindset about diminishing role of QA’s and its value-added within the system. Hence making them an impeccable part of a de-centralised, empowered, and informed Engineering team.