A Business Analyst’s Best Friends: The QA Lead and their Team
Successful BAs position themselves in the eye of the project storm. They are the calm, center point of a complex group of interrelated people, roles, and processes. BAs are in a prime position to ensure—when the project storm settles—that all pieces are connected and aligned to maximize value to the organization. In order to do this, BAs rely on strong relationships with many friends.
In January, I set the stage for a monthly series that describes the BA’s best friends. This month’s BA friends are the QA lead and their QA team.
How does QA benefit from a BA?
QA teams need BAs to provide clear requirements with context. QA teams need context in order to plan their testing strategy; by context I am referring to the set of circumstances, environment, and facts that surround a particular project, requirement, and/or solution
The QA Lead and their team members want to understand context for the project and for the requirements:
- Why is the project important?
- How does the project fit into the big picture of the organization?
- How does the requirement fit into existing business processes?
- What business scenarios trigger a requirement?
For example, BAs might provide a requirement to add a new button to a system screen, a screen mock up, or a lengthy list of outlined text requirements. The QA team cannot test these requirements properly unless they understand why/when a user would update the button and what events should be triggered by the new button, what capability does the button provide? What is the acceptance criteria for the requirement/story/design? How/When and in what situations will we know it is working?
What makes a top-notch BA from the QA team’s perspective?
Obviously, the tactical BA requirement skills are critical, but top-notch BAs bring a variety of soft skills to the project environment. The QA Lead appreciates BAs with these top-notch soft skills:
A BA with effective communication skills increases the efficiency of the QA Lead. If the QA Lead trusts the BA to communicate delays, issues, requirement changes, priority changes, etc., then the QA Lead can focus on testing resources and doesn’t need to waste time trying to chase down the BA or PM for project updates.
BAs are responsible for creation and maintenance of the requirements package. Obviously, requirements are the primary input for test plans and test cases. QA teams want access to the most recent requirements. They do not want to get lost in the chaos of version control issues. They want to know when requirements change and where/how changes are documented. They want to know when and how outstanding requirement issues are resolved.
Respected and Knowledgeable Partner of Subject Matter Experts/Business Users
The QA Lead and the QA team members rely on the relationships the BA has with business users and SMEs. The BAs knowledge and partnerships are critical when QA teams need quick decisions about priorities, issues, and defects.
What frustrates a QA team about the BA role?
The QA team wants testable requirements from the BA. This sounds simple and obvious, but how would you define “testable”? Here are some tips for producing testable requirements:
- Invite QA to participate in the requirement process. Including the QA team early in the elicitation process will help them gather context and will ensure the requirements process meets their needs.
- Be precise: Avoid pronouns like “it”.
- Be specific: Avoid terms like “many” or “all” or “most”. BAs need to list groups that are applicable or not applicable.
- Identify Links or Dependencies: Be sure that QA understands the dependencies between features or requirements – visual models are a huge piece of doing this right!
- Break it down: Be sure the requirement has been decomposed…it’s not divisible…can’t be broken into smaller requirements.
- Describe Scenarios: If a requirement is only true in a specific business scenario, then describe the scenario in the requirements for the purpose of testing or link requirements with specific job functions or processes.
How to say no to a QA Lead?
Points of tension between a BA and the QA Lead tend to center around changes that would impact resources and timelines. Too frequently, QA time is cut short because of delays in analysis, design, or development. Often requirements change or features are added when system testing is already underway.
Here are a few examples of why and how a BA might say no to a QA Lead:
- QA wants final requirements, but they are not complete yet. Be sure to proactively communicate any delays. Help the QA lead understand the impact of moving forward without complete requirements. Help them understand which pieces are incomplete, what is likely to change, and if some testing can move forward without a complete requirements package.
- QA needs more time to complete testing. If the deadlines are negotiable, then it might be appropriate for the BA to work with the QA Lead to advocate for more testing time. If the deadlines are firm, the BA can help the QA Lead prioritize test cases by business need and risk level.
- QA wants to save time by doing a thorough system test but skipping integration and regression testing. In some project environments, this might be acceptable and even common. If it introduces too much risk in your project, then you need to help your QA Lead understand the risks. If the QA Lead is willing to accept the risk, then you may need to escalate your concerns to the project manager or project sponsor.
How to influence a QA Lead to get what you need?
To influence the QA Lead a BA needs to understand how the QA Lead defines success. If the BA can frame their needs within the QA Lead’s definition of success, then the BA will have a better chance of getting needs met.
QA Leads want a successful testing cycle. In most cases, this means nothing major breaks when the system goes live. Other components of success might include: meeting deadlines, quick issue resolution, quick and correct defect resolution, and effective workarounds for unresolved issues.
If a BA needs to add ten new requirements to the QA workload, the BA should be prepared to communicate the priority, risks, and dependencies of the new requirements. The BA should be prepared to discuss how the QA team can be successful despite the new requirements.
How to communicate the value of the BA role to a QA Lead?
When initiating a project with a QA Lead, discuss expectations. Ask them what success means. Let them know about the skills and experience you bring to the project…especially the soft skills that will help the QA process run smoothly:
- Requirement prioritization
- Issue resolution
- Risk management
- Defect Resolution
- Relationship Management with business
- Problem solving and critical thinking
What do you think?
- BAs: How do you make sure your requirements are testable?
- QA Team Members-What are the characteristics and skills that the best BAs bring to a project team?
Don’t forget to leave your comments below.