Don’t Aloof Yourself from the Product Team in the name of Independent Testing

0
140

The term “independent testing” has been going through an existence crisis in waves. Back in the nineties, there wasn’t much recognition for this term. In the early 2000s, testers started getting a facelift where the product team acknowledged the need for independent testing. Later in the decade with the increasing adoption of Agile methodologies, testing was brought into the folds of the product development effort to a large extent. Testers were participating in code reviews, paired development efforts, testing from the early stages of the product life cycle and so on. While this helped give the tester a lot more recognition for the work he did and improve the quality of the product under test, in teams where the concept of independent testing was not fully understood, this started posing a serious threat to the concept of “independent quality assurance”. In a concerted effort to ensure the sanctity of independent QA is not lost, in the recent years, the testers themselves are beginning to speak up for independent testing. As a testing professional, while on one side I am comforted to know that the independence factor will not be lost; on the other side, I am concerned that testers may incorrectly push themselves to a zone, where they aloof themselves from the rest of the product team. That is a dangerous spot to get into, as it has a number of negative outcomes such as: identity crisis, adverse impact on product quality, disconnect and lack of collaboration with the product team to name some core ones. At this juncture, there are a few tips I would like to share with the testing teams and also point you to a couple of my blogs to throw more light on how we should strive to retain our independence yet not isolating ourselves from the product team:

1. Identify clear areas of collaboration (example, reviews, regular status meetings, design and product architecture discussions, roadmap definitions, common bug bashes, user requirements analysis etc.)
2. Identify clear areas of independence (example, execution, requirements mapping, test coverage definition, specific portions of defect management)
3. Ensure everyone in the team understands and agrees to the above and customizes the list as needed for their specific teams
4. Revisit this list periodically to ensure it still holds good

While the above are just a high level set, the two articles below should give you, the tester, a much better view into how to re-define one’s role to truly achieve the “ideal state of independence in QA”.

http://www.stickyminds.com/article/dotted-line-role-delineation-between-developer-and-tester
http://www.stickyminds.com/article/new-gives-and-takes-software-tester-s-role

NO COMMENTS

LEAVE A REPLY