BQAs: Why We Combined the Business Analyst and Quality Assurance Roles

Written by Erick Dimistracopulos

Quality assurance has a bad reputation. Despite being a vital part of the development process, some argue that if developers were writing good code in the first place, then QAs wouldn’t be necessary. Yet constant testing is vital to ensure things work as they’re supposed to.

Part of the problem with more traditional quality assurance is that the role isn’t integrated enough into the process and, as a result, many bugs and issues that could have been caught early in development aren’t discovered until the end of the project. This leads to teams having a hard time finding the root of the problem and when they finally do, fixing it requires big structural changes that are time-consuming and costly.

This is why we have rewritten what quality assurance is at Rangle and morphed the responsibilities into a BQA role.

What is a BQA?

BQA is an acronym for Business/Quality Analyst. It’s a combination of business analysis and quality assurance expertise, a role we created to ensure the final product satisfies business objectives and user expectations. A BQA is a much-needed bridge between the client’s business needs and the technical capabilities of our team.

It’s a broad leadership role that extends far beyond traditional QA responsibilities. Rather than being involved only at the end of a project, our BQAs are involved from the beginning. Naturally, they are responsible for leading software testing, but their job also involves a high degree of critical thinking and requires taking a strategic, deliberate approach to product development and testing.

The traditional way of applying QA involves waiting until the end of a project to begin testing. By introducing BQAs into the process at the start, developers write better tests from the get-go, resulting in fewer bugs, less rewriting, and better overall code quality. This proves to be cost-effective in the long run while also ensuring products are delivered on time: the best of both worlds.

As a BQA I help developers write better tests, better stories and help refining them to make them more understandable and--you guessed it--testable.

What are BQAs responsible for during a project?

The role BQAs play is a lot broader than the traditional “QA” role. BQAs do test the software that is being developed (after developers have done their testing), but they also do many other things:

  • Develop the project’s quality strategy. A BQA works with the PO to understand the project’s needs and helps formulate a strategy for achieving the necessary level of quality, ensuring that such strategy is aligned with Rangle’s delivery process and the needs of the client.

  • Monitor and continuously refine the quality strategy. As the project is running, the BQA watches for quality problems and works to fix the process. In other words, Rangle’s BQA does not just detect bugs and report them to developers for fixing. Rather, he or she aims to understand why such bugs arose in the first place and to find a solution to the root cause.

  • Help identify likely quality problems ahead of time and assist in story creation. BQAs analyze specific requirements, watching for gaps; they also participate in story creation to ensure that acceptance criteria are sufficiently clear.

  • Help developers test their software. In the ideal world, all bugs would be caught by individual developers before each feature is delivered, since this makes it possible for such bugs to be fixed right away, without the unnecessary communication and context-switching overhead. To get closer to this ideal world, we ask our developers to test their code thoroughly and train them to do so efficiently. However, each project is different and quite often the developers will face situations where assistance from a BQA is be essential.

  • Validate features. We aim for a process that would ensure that software delivered by the developers is as free of bugs as possible. However, we find that it is still important for a BQA to take one final look at each delivered story. In some cases it would be appropriate for the BQA to take the responsibility for the more demanding testing, e.g. running the application on a wider array of devices.

  • Perform regression tests. A certain amount of regression testing should be done by developers upon completing each feature, but the BQA would often take on the task of a more systematic regression testing.

  • Provide feedback on usability. By spending a lot of time with the software, BQAs can identify usability challenges and suggest possible improvements.

  • Write automated tests. When appropriate, our BQAs can write automated tests to reduce the need for manual testing.

By combining the expertise of business analysis and quality assurance, we help ensure that the final product satisfies the client's business objectives and the end user's expectations.

If you have any questions or would like to discuss how the role of the BQA fits into our Rangle Flow don't hesitate to shoot us a message!