QA/BA Specialist at XSolve, interested in user experience. Natalia supports communication and shared understanding between development and product teams. Persistently asks 'why?'.
Imagine: you have a project which you have outsourced to a partner, an external company. They provide a full stack development team to secure the success of the project. Obviously, they are responsible for technical implementation and testing, but how can your in-house Product Manager make sure that the business vision is clearly transmitted to the people who will bring it to life?
A product owner expects to cooperate with an experienced and creative team that will help them to develop the best possible web product and satisfy end users. Confidence in product quality is essential and successful delivery depends on all interested parties understanding each other, sharing an awareness of users’ pain points and goals, and also of the business objectives that inspired the entire project.
This all usually involves two specialists: one to take care of testing and another to support everyday tasks related to requirements. However, what if you could invest in both by adding only one person to your team?
A QA/BA specialist is a functional tester whose goal is also to facilitate everyday work with business requirements in the development process.
The role is designed to support the development team throughout the entire project in two major areas:
1. Achieving development of a high quality web product. 2. Contributing to a shared understanding between the development and product teams.
The QA/BA will help to analyze initial goals and needs, meticulously evaluate project requirements, support the design process, ask tons of questions, facilitate communication between all interested parties, and eventually test the implemented features.
6 advantages that your team and project gets with a QA/BA
Let’s assume that the team’s goal is to create a brand new product or enhance a solution already on the market. Above all else, what is expected from them is creative thinking and the ability to solve problems. Introducing a specialist to the team who can facilitate this process, knows techniques that will help the team dig deeper into the business objective, and at the same time remembers about crucial edge cases brings a lot of value to the general team effort.
To gain a better knowledge and feedback from an experienced dev team on the subject of co-operation with QA/BA specialist, I conducted a simple survey asking about the biggest benefits from incorporating this role into everyday workflow. From that exercise I was able to extract six core advantages of introducing a QA/BA specialist to your organization.
1. Well-organized and maintained requirements
In order to expedite a shared understanding of what has to be done, the requirements have to be clear, precise, feasible, consistent and current. But who has the heart to keep it all constantly up to date?
A QA/BA makes every effort to keep the stories small and independent from the very beginning. They take care of user story mapping, well-described acceptance criteria, and easy access to other necessary elements, like designs, flows, etc. Usually, they can quickly answer developers’ questions about the expected behavior of features or end user activities, and can facilitate discussions related to concerns about the product that is being built.
2. Better understanding during testing
Good requirements should also be testable and anticipate the edge cases across that the development team will encounter. If enough attention is paid to those aspects from the project’s very beginning then the risk of high severity bugs is definitely lower in the UAT phase.
If a QA/BA is part of the team, all members are encouraged to think from the start about how to verify assumptions. Eventually, someone who has deep knowledge about the features’ origins (business goals, user pains and gains, interactions with other parts of the system…) will test them. And the better the understanding of the product, the more accurate those tests are.
3. More valuable decisions, earlier
Why? What about? What if? These are examples of kind of questions that you should hear most often from a QA/BA. But those questions are not only aimed at product owners during requirements gathering, but also at developers during testing or just everyday work when the team needs to tackle problems.
Surprisingly, through my entire career I have heard from the clients that what they value most in cooperation with me are the questions that I persistently ask. Questions help to spot the gaps, avoid risks at early stages, think about consequences and impacts for the entire product, and encourage everyone to focus on creative solutions.
It’s important to note that all of this does not happen at the UAT phase or after production release, but much, much earlier – at the point when the ideas about the product are brought to life.
4. Happy developers
Programmers’ time is golden. Solving problems is what they like. Creating amazing products is fun for them. In many cases, browsing through a wall of text describing requirement specifications, updating every little detail, communicating all changes and maintaining documentation is not what they enjoy the most.
Having a QA/BA as a team member leads to a situation where developers do not have to spend additional time on agreeing detailed acceptance criteria or thinking about all edge cases at stages when the requirements are still vague.
When the time is right, they can focus on evaluating the path to the feature’s goal, fix users problems, provide thorough analysis during refinement and – what they do best – actual development.
5. Efficient communication
Organizations that hire outsourced teams tend to be concerned about the quality of communication with the contractors. Especially when different time zones are a factor. Transparent communication is the key to mutual trust and success.
With a QA/BA in the team, the discussion is constant. They ask about objectives, reasons and decisions, but also encourage the developers to do the same. As a result, nobody is afraid anymore that their questions might be ignored or seen as silly.
Moreover, acceptance criteria do not get lost in the chain of communication because there is a dedicated person to check if the requirements are correctly organized and communicated to the team (and tested), so no one is frustrated that we forgot about something.
6. A non-technical perspective
Creating exceptional products requires that user stories are implementation-free. They should represent the expected change in end user behavior, not technical aspects of achieving the final solution (which is the developers’ role to figure out).
A QA/BA keeps the focus on goals and users even if it is tempting to dig into technicalities. Having someone with a different perspective on the team broadens the horizons and helps everyone to look at the various aspects and inevitable challenges from another angle. The result is that people are inspired to have deeper conversations.
The advantages listed above draw a clear picture of how a QA/BA role can support a team’s focus through greater understanding of the business objectives. By adding a QA/BA person to the development team, you ease the process of eliciting and maintaining business requirements, and securing the proper flow of knowledge and expectations during development and tests. Apart from that, out-of-the-box thinking is encouraged, you introduce a non-technical perspective and facilitate more professional internal and external communication.
Prospective questions and concerns
You might be thinking, “Isn’t it useless or even harmful for an agile team’s self-organization?” or simply, “What is the value of combining the roles, wouldn’t that be distracting?” Here are some common concerns when thinking about hiring a QA/BA specialist.
Are they another product owner or some kind of a proxy?
Definitely not! Why not? Basically, the role of QA/BA is to support conversation between the client’s product team and the development team, not to take over their responsibilities.
A QA/BA can help to elicit requirements, so that they are readable and useful for coders and make recommendations about usability, but they will not have the deep business knowledge required to make final decisions. That is entirely up to the product owner and business stakeholders (although a QA/BA can provide some techniques to support that process).
Will there still be a place for developers to ask questions?
Of course! Adding a QA/BA to the team definitely does not mean that the only role left for a developer is coding. To build a great product it is crucial to combine experience and input from various points of view. And while a QA/BA can ask questions about goals, users, flows and edge cases, they will never deeply investigate technical details and risks that might have a significant impact on the final solution.
What, in my opinion, is worth mentioning is the fact that when, after a few months of cooperation, I asked the team what had changed since I joined, the majority said that they stopped getting frustrated about wasting time on ineffective meetings that were supposed to be devoted to requirements analysis.
Now, we still meet and discuss the user stories and acceptance criteria, but at a later stage, when the vision is clearer and the team can focus on the flow.
What if a BA suggests non-feasible solutions?
Good cooperation is always based on communication and discussion, so although a QA/BA might have some wild ideas, they will never push for them without consulting with the development team and the product owner in the first place.
That said, I strongly believe that even the ideas put forward by a non-technical team member may inspire others to figure out practical technical solutions.
Will the developers still be involved in communication and product design?
Yes, a QA/BA should never take on the role of a secretary or be the only one point of contact between a client and the development team (nor should any other team member). All team members have to be wary of getting lazy and maintain a constant line of communication with the product team.
Why is all this important?
Nowadays, tech products exist in an environment where the market changes pretty fast. For an outsourced team, it is essential to keep pace with the rate of change in order to support clients in running the most successful businesses.
That is why we make the effort to create cross-functional teams that not only provide code, but also have the expertise to support the product’s entire development, including research, testing, user experience and all activities focused on understanding the business pains and needs.
After more than a year of having the QA/BA specialists in the organization to support the team, this is what we noticed at XSolve:
• there is more interest in requirements from the development team members (developers ask about elicitation techniques, attend workshops regarding analytic skills and seem to be more eager to face challenges related to functional requirements);
• product owners get a helping hand in everyday duties related to requirements management and documentation;
• quality of developed products is higher, because the functional testing is more profound;
• communication between development and product teams has improved – everyone is involved in the process of problem solving and it is easier to reach a shared understanding.
Many teams work really well without an analyst, but having a QA/BA certainly helps in demanding projects with a complex business domain.
The support of a person who has more business-focused and quality-oriented competences saves time, boosts creativity, strengthens the entire product team in achieving the common goal, and limits the risk of misunderstandings. And that is, without doubt, essential for tech products’ prosperity.
If you’re interested in this guide that means you are seriously thinking about introducing change in your organisation or possibly, you already have gone through a transformation. Congratulations, you are...