I'm at an organization where QA is basically kept in the dark when it comes to requirements/technical design. Documents are created usually during the Requirement gathering phase, but then by the time implementation is done, that documentation is basically worthless. Then, I'm given tasks to test DEV work that is very sparse in information. This results in me spending a lot of time talking to DEV/BA after-the-fact. Is this common, and if so, what are good practices in this situation?
Add a comment
|
1 Answer
No, this is not a common practice. QAs are and should be kept in light and every communication involved related to the requirements. The sole purpose of the documentation created during the requirement gathering phase is to keep it updated and validate the application according to that document, so this document serves as the single point of information for all DEV, BA and QAs. Interpretation of this document can be differ for different roles and that's where discussion and requirement analysis comes into scope i.e. to bring everyone on same road.
Remember, any defect caught in the requirement phase is easy to track & fix and saves a lot of effort and time for the whole team, so Active Involvement of QAs in Requirement discussion and Analysis meetings/calls/documentation etc. is must and standard process in Industry. QAs has to validate the system at the end and they have to provide sign-off, so if they don't know about the requirements how they will validate. Even in some Organizations QAs are not allowed to talk to DEV, their point of contact is either their QA Lead or BA (this is what we are currently following), because a DEV will tell you what he/she have implemented as per their understanding but not as per what was required (No offense for DEV's please).
I too had worked in such a situation where QAs were not billable to client and hence they were treated as a liability, but they were considered responsible for client issues. So, we acted proactively (my team lead at that time) and involved ourselves in requirement meetings forcefully. Initially we too felt ashamed that why we are getting into meeting where we are not called, but with due course of time, it proved fruitful, when we started providing inputs, asking questions, raising non-agreement flags for some solution we thought are not good for users etc.
So, in your situation too, you need to get yourself involved in requirement meetings/calls/discussions by force, raise continuous concerns for this to your PM, Team Leads or even senior management (if required), because if Quality suffered you will suffer and company too has to suffer (Organization name will be impacted). Prepare Minutes for the meetings, updated the requirement document for the changes discussed, obtain sign-off from the BA and Technical lead. This is part of your job so don't worry what DEV/BAs will think. This may take some time to get it implemented but it is not a big task to achieve.