English (UK) 
Magyar 
Deutsch The article was originally published in BA Karakter magazine #10 .
Prologue
Representing software quality assurance - or, more simply, testing - I feel somewhat like the odd one out here in the pages of the 5th BA Bridge blog series, even though my instinctive view has always been that business analysts and software testers are, at their core, kindred spirits; or, at the very least, close relatives - certainly neighbors.
I started working at Fundamenta-Lakáskassza in 2012 as an IT Project Manager. At the time, there was no dedicated testing team; only a business analysis team was in place. It was taken for granted that the bulk of testing would be carried out by the business analysts. The testing of a program coordinating the rollout of several IT systems - including the replacement of the central account management system - was handled by business analysts and business users, under the direction of professional external test managers. One outcome of that IT program was the establishment of a dedicated testing organization.
Today, as a project lead at a company providing testing services, I see that every large enterprise has an organization responsible for testing, and even SMEs often have one or two testers or at least a person accountable for testing. I have less visibility into business analysis teams, so this may well be a bias driven by my own availability heuristic, but my impression is that many large enterprises employ more testers than business analysts. I do not have hard data or statistics to confirm whether this is actually the case. But for the sake of a thought experiment, let us assume that companies really do employ more software testers than business analysts. Google Gemini, by the way, seems to support this assumption as well.
Naturally, there are several reasons and explanations for the apparent surplus of software testers. Still, let us entertain the idea that perhaps more testers are needed simply because there are too few business analysts.
The Tester as a Veterinarian
There is an old joke about a veterinarian who falls ill and goes to see a general practitioner. The GP invites him in and says: “Please, have a seat and tell me what your symptoms are.” To which the veterinarian replies: “Well, that makes it easy.”
So when does a tester have an easy job? When there is a good specification. One that is written on the basis that the necessary discussions, analyses, and decisions have already taken place. One that contains clear requirements and in which process branches have been fully thought through and properly resolved. One that already reflects the business need and the end-user perspective, and ideally includes related screen designs and wireframes. In such cases, test cases can be created quickly and efficiently, and we can also expect to encounter fewer defects during testing - although, of course, a great deal still depends on implementation quality and the developer.
In practice, however, our testing colleagues most often encounter situations where "the software’s fur is falling out", "it makes strange beeping sounds", or "it has not had a bowel movement for several days". Cue the head-scratching: why is this software not working properly, what exactly is wrong with it, and what is preventing it from functioning as intended - assuming we even know what the intended behavior is?
Fortunately, we are still more like general practitioners than veterinarians in one important respect: we work with people. So the questioning begins, followed by clarifications with representatives of the business area, ideally with a business analyst - if the project has one - as well as with the developer and the systems analyst. After these discussions, the picture gradually comes together, along with the test cases and the expected behavior of the software.
The BA-QA Balance Upset
At TestIT, we are actively identifying testing-related tasks and use cases where AI can be applied effectively. As a starting point, we asked 10-15 of our testing experts, working across different projects, to estimate how their working time is distributed across various testing activities. In relation to test case design - which includes reading the specification, clarifying requirements, writing the test cases, and having them reviewed and validated - the result was that, while the proportion varies by seniority, it still accounts for a significant share of a tester’s workload.
Share of test case design within a tester’s responsibilities | |
Senior Tester | 30-40% |
Mid-Level Tester | 40-50% |
Junior Tester | 60-70% |
The above findings only reinforced our belief that it is worth focusing on what is now an almost trivial AI use case: generating test cases from specifications. Test case design is a substantial activity for testers, and fundamentally it is a task that large language models can interpret well: a piece of text must be understood and, based on defined criteria, another piece of text - a test case - must be generated from it. One of the biggest obstacles, however, is the absence of a specification, or the poor quality of the one available. It may not be sufficiently structured, it may not contain all the necessary data, or it may include contradictory elements. In agile projects, the specification may be replaced by a user story and acceptance criteria.
Within the framework of a PoC, where we had access to a high-quality specification from which test cases had previously been created using traditional methods, we concluded that the time spent on test case design could be reduced by approximately 60% with the help of an LLM specifically prepared for test case generation. This is only an initial result; we will conduct further measurements in the future, but our assumption is that test case design effort can be reduced by 30-50% overall. This order of magnitude is, however, already a strong enough indicator to suggest that with proper preparation - and, in some cases, greater business analysis effort - the effort required for testing activities can be reduced. From another perspective, software quality can be improved by shortening the testing cycle, thereby enabling more iterations within a given timeframe.
I do not have a solid benchmark for how many QA professionals should be assigned per BA, but the example above shows that increasing the BA ratio has a direct impact on QA activities and, in some cases, a well-calibrated balance may even reduce the total effort required across the entire software development lifecycle.
Ideas for Business Analysts from a Tester’s Perspective
Two ideas have come to mind that could support collaboration from a practical perspective and could be introduced even in the short term, without significant additional effort.
The first is static testing - that is, testing requirements and reviewing the completed specification from a testing perspective before any coding begins or the application is executed. The goal is to identify and correct deficiencies and defects at this early stage. In practice, I see this only very rarely. Our clients typically involve us in testing once the software is already underway. Yet this is a very simple and cost-effective form of the Shift Left approach, i.e. moving testing and software quality assurance activities as early as possible within the software development lifecycle. Dear business analyst colleagues: if you have not yet been challenging your testing colleagues with static testing, now is the time to start.
My second thought is that Quality Gates could already be introduced during the business demand and specification phases. There may well already be good practices in this area, but in many of the projects we are involved in, my experience is that the concept of a Quality Gate begins at release stage - that is, only once code already exists: developer testing, functional testing, integration testing, and UAT. It would be highly beneficial to apply Quality Gates already to the business requirement itself. For example: Is the business need based on adequate analysis? Is it clearly articulated? Has the target user or end-user group been identified? In the case of an existing software product, to what extent is the function intended for modification actually used? And in the case of a specification: Have the relevant business domains approved it? Has the document or user story undergone static testing?
Epilogue
In light of the above, I believe that the foundation of good software quality is strong business analysis and well-defined requirements. On this basis, software testing can be significantly accelerated, and the focus can shift away from understanding the requirements and expected behavior toward validating the quality of the implementation itself.
Effective BA-QA collaboration is essential if we want to reduce time-to-market and keep pace with increasingly shorter release cycles.
I believe that we can achieve our shared objective - delivering high-quality software and business applications that meet end-user needs and can be adapted quickly and efficiently to continuously changing requirements - only through joint effort.
I am confident that exciting forms of collaboration may emerge between us in the future. Even if we were only able to jointly explore the assumption of whether companies really do employ more testers than business analysts - and what an appropriate ratio might be - that alone would already be a fascinating topic.
Author: Gergely Gayerhosz, Delivery Manger of TestIT
