Closing the Gap between Quality Assurance and Business Analysis
In the traditional software development life cycle, business analysts (BA) and quality assurance (QA) team tend to work in isolation or with very little collaboration between them. However, BA-QA collaboration has now become a necessity to cope with the rapidly changing dynamics of business.
If you know how to close the gap between quality assurance and business analysis, you will be able to greater business value to your client by delivering the right software product with fewer delays.
In this article, we list some steps that you can implement in your organisation to improve BA-QA collaboration on any project.
Effective Communication and Collaboration
Effective communication and collaboration from the beginning of a project are essential to bridge the gap between quality assurance and business analysis.
It can be really helpful if the person leading the QA team or another representative is involved during the requirements gathering sessions and discussions. BA can collaborate with the quality assurance person and give them a general idea of what needs to be built, why it should be built, and what problems shall it solve for the end-user.
In many projects, requirements become clear gradually. The business analyst can keep QA in the loop, and inform them of any requirements that are incomplete or likely to be changed. This constant communication will prevent the quality assurance team from investing efforts in useless requirements, and therefore enable them to schedule their tasks more effectively.
Business analysts can also collaborate with the quality assurance team by helping them rank test scenarios based on their priority and impact on the project.
Provide Testable Requirements
Another important way to bridge the gap between quality assurance and business analysis is to provide requirements in a way that gives the quality assurance team all the information they need. It’s true that a business analyst will often write down a business requirement themselves, but this can that can be incomplete from a tester’s point of view.
It is the responsibility of business analysts to provide requirements that can be tested.
A testable requirement clearly defines what is expected from the system, and does not leave anything open to the tester’s interpretation. It should describe the system’s response to all possible scenarios of a particular requirement. A testable requirement does not contain vague terminologies, instead, it provides clear limitations and specifications.
For example, The user shall be able to enter a maximum value of 8 numerical digits. This requirement clearly defines that the input data type is numeric only and the maximum length of the input is eight.
Provide Context for Requirements
The main skill of business analyst is to understand the business requirements of clients and why a particular requirement is important to the client.
Consequently, the business analyst should also be able to provide a suitable context for the requirements being tested to the quality assurance team, especially any dependencies and links between different requirements. Business analysts may use data flow and flowcharts to represent this information effectively. This enables quality assurance team to understand the functionality clearly and completely.
The business analyst can provide other useful information to quality assurance team. For example, a business analyst can explain what triggers a certain functionality, what would be the system behaviour on the basis of different inputs, what should be valid data type and length in input fields. As a result, the quality assurance team would be able to create better test cases and make sure that the functionality meets all the business requirements.
Provide Updated and Organized Requirements
We know that business analyst is mainly responsible for maintaining the requirements documents and its versioning. It can be very helpful for the quality assurance team if business analysts keep requirements organised. This means that the quality assurance team should have access to the latest version of the requirements. If requirements are not well organised, there is a good chance of missing dependencies between the requirements.
Besides organising new requirements as they’re added by the team, there is also likely to be some updates to previous requirements at some point during the project. These changes should be maintained in such a way that all information related to one requirement is located in one place, otherwise, it is possible that the quality assurance team continues testing the obsolete requirement, oblivious of the changes requested. In addition to costing you additional effort and time, thus will affect your project schedule and product delivery too.
Maintain Requirements Traceability Matrix
Employ a requirements traceability matrix to align your business analysis and quality assurance. This powerful tool helps you track a requirement from its origin onwards to the design, development, and testing stages. It is also useful to track all changes made to the requirement over time.
It is recommended to use a requirements management tool that will help you bring quality assurance and business analysis closer together. An ideal tool should allow you to log down all your business requirements, and give you the ability to create test cases for each requirement added. In this way, all your requirements and test cases will be linked, which in turn ensures full test coverage of your product.
Recap
Effective communication between the BA and QA gives software testers a general idea and context of the product being developed. This enables the QA team to cover all functional and nonfunctional aspects of the product from the user’s point of view.
The quality assurance team will be able to deliver a quality product to the end if the project is backed up by well-written and testable requirements. Furthermore, business analysts should manage requirements in an organised manner in order to guarantee that the quality assurance team is working with the latest and up-to-date requirements.
Using tools like the requirement traceability matrix and requirements management apps can help your team keep track of requirements and change requests throughout the project with greater ease and convenience.
About the Author
Ulf Eriksson is the co-founder of ReQtest, an agile software management platform developed in Sweden. A huge fan of applying Agile to professional and private life, his book Beyond The Hype: Software Testing Explained includes lessons from 20 years’ experience in the software industry. Ulf is the author of several whitepapers and articles about testing and requirements management, and he is regularly invited to speak about these subjects at international conferences.
