When a topic, especially a process based one (For example: Creating a traceability matrix or test documentation review, etc) is discussed in the class, the immediate question I get is: “Who does this? The QA lead or the team member”
This is great proof that beginners have a difficult time understanding the scope of work, roles and responsibilities. They only have a vague idea about this and are often looking for ways to validate if their understanding is accurate or not. And, if you are thinking this is only an issue for newcomers, you are wrong. Lots of managers/leads/coordinators also find the role definition/delegation of work to be an issue due to lack of clarity in this area- what to do yourself and what to delegate is often a dilemma for the QA leads.
Just like some of you might think, I was wondering too that, “What if they don’t know, to begin with? Won’t they figure out as they go?” Yes, they do. But lots of time, efficiency and quality are compromised in the process.
To avoid all that, we have outlined the major tasks that are part of STLC and the respective responsibilities in the form of the below table:
Team lead’s responsibilities for different QA activities:
| STLC activity | QA Team lead Tasks | Team member tasks |
|---|---|---|
| Project Kickoff- Start | Create and present the project highlights to the QA team and other stakeholders | To assist and let the team lead know of any improvements or inconsistencies |
| Test Planning | Create, Maintain, manage and enforce Test plan Risk analysis and management | To provide inputs on areas of the test plan document, such as: Scope Assumptions Risks Milestones and any other area that the team member has an input on. |
| Requirement gathering | Divide work based on modules of the application and choose team members as point of contacts for each module Decide on a time when this is to take place Let the team be aware of what is expected as an outcome (e.g.: list of requirements in a condensed point by point manner, understanding document, etc.) | Be in charge for your individual module Gather requirements through BRD/FRD review or walkthrough meetings Present/document them in the format expected, within the time allocated for this activity Provide suggestions or alternate point of view in case of incompatible formats or unachievable time lines |
| Test scenario creation | Work allocation Query resolution Template finalizing Setting deadlines Participating and contributing to test scenario creation | Create Test scenarios for the module allocated to you, with in the set timeline and in the format already agreed upon. Seek resolution either from the team lead or from the respective technical |
| Test case documentation | Work allocation Query resolution Template finalizing Write test cases | Create test cases and data, when applicable |
| Traceability Matrix creation | Create template and share the guidelines on how to create a TM Work with the team and contribute to it | Contribute to the creation of the TM for the modules that you are individually responsible for |
| Test documentation review- internal | Set rules on what basis the review is to happen Set time lines and responsibilities be one of the peers and involve in the review process | Perform review based on the rules set and provide non-personal comments on your peer’s work |
| Test documentation review- external | Notify the BA and/or dev team that the test documentation(test cases) is ready for review and send the work product | On Standby to incorporate any changes suggested during the review process |
| Test readiness review | Create the review checklist Perform the review and present results to the Project manager Basic Sanity and smoke test and determine- are we ready we test? Give a go ahead to the QA team for testing | Wait for instructions on readiness Perform basic smoke and sanity test for the modules that you are individually responsible for |
| Test execution | Set test execution guidelines after seeking the team’s inputs Work on test execution Help new testers with catching on with the current application Report defects Review the defects reported by the team members to make sure that they are valid, not duplicates and complete in the description Escalate any showstoppers and make decisions on how to proceed in such situations | Execute test cases, set appropriate test case statuses and report progress Notify immediately of showstoppers or issues impacting testing timelines Report defects comprehensively |
| Reporting | Send daily status reports to all stake holders Represent the QA team in any status meetings Collect metrics based on overall testing statistics | Assist the team lead in all the tasks being performed |
| Test closure | Evaluate the exit criteria for when to stop testing Share the results of the exit criteria evaluation If the exit criteria is all satisfied, make the test closure report and send it to the stake holders providing the official QA sign off, include a list of known issues Collect details about the overall project- its successes, areas of improvement, lessons learnt, best practices implemented, etc and present them in the project retrospection meeting or document. | Assist the team lead in the test closure tasks |
| UAT | Gather the acceptance criteria from the UAT users to understand the parameters for their evaluation Share the acceptance criteria with the team and work with them on collecting or creating UAT test cases If necessary, train the UAT users on the application If necessary, be on standby for any assistance during UAT If necessary, perform some tasks during UAT and present the results to the client or UAT users for their go/no-go decision | Create/gather UAT test cases Perform or assist in UAT – when need be |
For all the processes mentioned in the above table, follow the below links for more information:
- Test plan creation
- Requirement gathering and Test scenario writing
- Test case writing
- Test documentation review
- Traceability matrix creation
- Test readiness review and Exit criteria checklist
- Status reporting
- UAT
A few tips for QA team members:
1) Do NOT create your Test cases, defect reports etc. with the expectation that if there are any problems with it, the team lead will find and fix them for you. Each individual is responsible for their work product and its quality. A team lead’s review is customary as an additional checkpoint and most often high level in nature.
2) Expect little to no hand-holding on a daily basis. No team lead should tell us what to do, every single day.
3) Communicate ahead in case of any concerns, red-flags or issues.
4) Unless your process restricts you from doing so, if you have any questions regarding the functionality or technicalities, please get in touch with the developers/BAs/other technical teams by yourself, without relying on your team lead to relay the information for you.
Tips for QA team leads:
1) Consider team’s opinion on timelines, schedules, effort estimations and planning
2) Establish strong processes so the team can work independently with minimum or no supervision
3) Keep the communication channels open and be approachable
4) Be a team player and share responsibilities
Also read => How to build a successful QA team? Leadership in Testing Part 1 and Part 2 here.
About the author: This article is written by STH team member Swati S.
That is a quick wrap up on team lead and team member tasks and duties in a typical QA team. As always, please share your experiences, comments and questions below.