Insight: Interview with Bharat B - QA perspective on requirements definition
Bharat B has been a senior Test Consultant for over 12 years with experience in Testing Workday, epos, Salesforce, Oracle Financials R12 EBS & ERP, SAP FICO, SAP SuccessFactors, SAP CRM & SAP ERP projects.
Requirements rework can be costly and result in project delays. Bharat shares his personal experiences from a QA perspective to serve as an aid for the BA to ensure the definition of good quality business requirements.
Q: What is the difference between a BA and a QA?
BA = Business . Works with client to map out their business processes and define business requirements for a project.
QA = Quality Assurance (Testing = Verification + Validation). Develops and executes test scenarios to ensure delivered work meets the defined business requirements.
Q: Why do QAs need BAs?
BAs are essential as they provide the QA Team with clear concise requirements and context allowing the QA team to build their test strategy. The BA will typically provide the BAU or ‘As Is’ flow outlining touchpoints into the process which allows the testers to build the required test scenarios and scripts.
The BA also identifies priority requirements so that the QA team understand focus areas
The BA is also responsible for managing any change requests that have been identified during the QA phase or any gaps in requirements that have been highlighted by the QA Team
Q: When should the BA start working with the QA?
Ideally the BA should liaise with the QA Team as soon as they start refining a user story. This ensure the QA Team can input into the definition of the requirement and can flag any potential downstream impacts or highlight duplicate functionality that has been developed and tested in the past.
Q: What are the key challenges experienced by the QA Team in relation to requirements:
· The requirement is too large or complex to be tested at one component level
· The requirement is not specific and vague – includes words such as ‘most’, ‘nearly’, ‘many’
· Has not identified dependencies or downstream impacts
· The requirement is not complete e.g. actors, functionality, frequency, time dependencies, data, platform, operation not defined.
· The requirement has not been signed off by the business and could therefore change
· Updates to the requirement have not re-shared with the QA Team
Pitfalls that BAs must avoid
· Do not change signed-off requirements based on feedback from the QA Team. Always consult with your business stakeholder/SME/Product Owner before changing the requirement
· Do not commit to scope changes by the business once the requirement has been signed off. These should be channelled to the Product Owner to manage
In essence, open dialogue with the QA Team from the moment a user story/requirement is passed to the BA will lead to a reduction in user story’s requiring re-work, and/or delays whilst the BA works to re-clarify the requirement with the business.
Learn more about Bharat’s experiences: linkedin.com/in/bharath-b-859708186
Why not share your thoughts on the topic: