Should a QA and BA partner in requirements analysis?
- 1. Requirements Analysis and the QA A BA’s perspective on the QA’s role in requirement elicitation and analysis
- 2. Should a QA play the BA’s partner in crime? A self-confessed,QA reliant, BA criminal’s rantings
- 4. Should a QA play the BA’s partner in crime? A self-confessed,QA reliant, BA criminal’s rantings
- 5. Should a QA play the BA’s partner in analysis? A BA’s wishes
- 6. Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed.
- 9. BA does: ● Deep domain+product knowledge to make decision about what to build ● Explores and evaluates options that are best fit ● Delivers considered options broken down into requirements and implemented BA has: ● Analysis modeling ● Elicitation ● Long range business planning ● Help team explore needs - users, actions, data, rules, interfaces, quality, design and implementation
- 10. QA does: ● Deep domain+product knowledge to make decision about what to build+how will this break ● Explores and evaluates options that are best fit+say what will and won’t work ● Delivers considered options broken down into requirements and implemented+stamp quality QA has: ● Knack of exposing tacit requirements ● Uncover unsaid business rules ● Impact- “What won’t work”/“What will break if you do this”
- 13. Not just
- 18. We’re in this together..validating requirements ● Correct ● Complete ● Feasible ● Testable ● Ambiguous ● Consistent ● Functional ● Non-functional
- 19. We’re in this together.. measuring success ● Analyze each requirement end to end ● List down user journeys from test perspective, verify with BA ● Create scenarios based on user journeys ● Clarify queries and functionality along with BA from stakeholders ● Suggest improvements to solutioning based on stakeholder input ● Track and close defects
- 20. Challenges for a QA ● Scope creep/frequent new requirements ● Ambiguity in requirements ● Ambiguity in role ● Communication of assumptions ● Conflicting customer views