In a perfect world (or a near to perfect one too), QA team has all the perfectly drafted requirements available for them to test the application against. And if they are even luckier, these requirements will be continually updated too! But for not the so-lucky ones, the requirements can be missing altogether. In this situation, QA is expected to keep checking with the Project Management and Development Team for the updated requirements. Many a times, this is not so much appreciated by the BA, PM or Dev Team. As a result, the QA folks are left out, neglected as the unwanted ones, who dont know what requirements to test the application against.
For the QA folks having perseverence, sending Queries to PM, BA and/or Dev Team is a frequently used option.All the queries are documented in a single list and sent across for resolutions. Many times, the QA Team even mentions their assumption in the query, so that the responder just has to conform the assumption, if the same is correct. In case of discrepancy, the correct answer is then provided and sent back to QA. QA Team keeps on sending these queries until all (or atleast most) of them are resolved.
However, there is yet another proactive way to handle such situation. The QA Team, after interacting with all the teams, prepare what is called a Requirement Understanding Document and get them reviewed/approved with the BA/PM/Dev Team. In case of discrepancies, the QA Team take the lead in modifying the content to make sure the Requirements are clearly documented. This document then becomes useful for the entire team, as the Dev Team develops the application based on this document.
This proactive approach can prove to be effective in getting acceptance from the PM & Dev Team, as they now are looked upon as a part of the team, who are willing and can help the other team members. Not only that, since the QA Team has prepared the document themselves, they know the application and its intricacies (many, if not all) much better.
This is a tried and tested approach which has worked wonders in more than 1 case.
There are other such small things which can be taken up by the QA to help the other Team Members. Some of them are:
- Taking up maintenance of QA Environment and coordinating with IT support team to remove the bottlenecks
- Setting up and maintaining a CI Tool so that some of the automated tests get automatically executed when a new build is deployed
- In case of TDD, QA can monitor the code coverage and wherever required, suggest more Test Cases to increase the code coverage
- If possible, QA can also help by writing unit test cases and help the Dev Team augment the code coverage
This is not an exhaustive list but only some tasks which can be taken by QA. However these tasks can be taken up depending on the requirements of the client. For e.g. many clients do not allow 3rd party vendors to take control or interfere in the IT infrastructure matters. However in smaller companies, if the team has won the confidence of the client, then this could be achieved.
Would love to hear if there are other small tasks taken up by QA, which have proved useful to the BA/PM/Dev Team and added to the success of the team and project.