Project QAs get truly in front of quality by analyzing requirements and writing test plans for those requirements before the user stories get to the development team. The idea is to understand the overall requirement, break it down to small stories and write good quality test plans on stories, so that the developers do not have to waste any time on unnecessary and undeserving tasks like chasing requirements and/or conflicts with existing functionality, etc. Not only do these issues kill the efficiency of the whole team and not just developers, but such issues are way less expensive if caught early.
Below are the high level responsibilities for QAs in projects, followed by processes for each of them. For a more detailed view of responsibilities and expectations for QA team, please click here.
Test Planning - Writing test cases and deciding execution strategy
Participating in Design Reviews
Testing Projects and Enhancements and making sure they are fit for release before signing off
Goal: To bring the focus for quality, and facilitate building quality into the system earlier in the process.
Activities: QAs complete research and analysis on each story due for the coming sprint, in the current sprint (as per information available by Thursday eod, before current sprint ending) and have test plans available prior to Sprint Planning [or Beginning of Next Sprint work]. Each user story should go through the below before going to the developer/designer.
Analysis of UAC (User Acceptance Criteria).
Test Plan Creation.
Review of Test Plans if required.
Prompt Communication - If a story has red flags impacting potential of meeting DoR, the QA must note details of research/findings on the user story for review and notify SM as soon as possible.
Requirements changing too much or too often - We understand that agility in operations is important, but a user story changing frequently after QAs start analyzing it OR changes to a point that the entire test plan needs to be rewritten can cause efficiency loss and may result in failure of QAs to meet their goal.
Story/UAC too technical - QAs can and many times do encounter user stories that require technical analysis by a developer and developers' input to develop any kind of test plan or strategy about the story whatsoever. Such stories might require inputs from the team's developers and a little room should be kept in planning towards any such unplanned roadblocks.
Slow or No follow-up on concerns raised by QAs - For all of this to succeed, it is important that all major concerns raised by QAs get addressed promptly by respective stakeholders.