Collaboration amongst disciplines such as product development, testing, business, marketing is increasingly encouraged in companies, especially with the advent of the agile development models. While collaboration has measurable benefits—faster issue resolution, better understanding of the product and its features, load sharing of team responsibilities (in systems such as kanban)—it also introduces ambiguity around the team members’ roles and responsibilities. Of specific interest to us here is the boundary around a tester’s role and its delineation from a developer’s role.
Quality is becoming a collective responsibility, again, largely due to the agile way of operations. Every discipline—be it business, marketing, design, development, testing, project management, or operations—has its own quality goals both in its execution efforts and in the product that is being built. In enabling these disciplines to meet their quality goals, the test team is collaborating even more with them through various empowerment strategies, such as providing inputs on unit tests, sharing build verification and sanity tests both manual and automated, and helping them with debugging and troubleshooting issues to name a few. While all of these collaboration efforts and group empowerment of quality mean more time for the testers to focus on their core quality goals and an increased product understanding, testers need to understand and mitigate the practical core challenges that collaboration entails
The independence factor around quality assurance is very important in ensuring an unbiased test effort. A decade ago, there was so much emphasis around independent validation, verification, and black box testing—especially during the days of the waterfall methodology—that the test team was slowly alienating itself from the rest of the product team. This isolation was creating problems around product understanding; disjointed test efforts, which did not completely map into the required test coverage; and lack of respect for the test team—creating some product quality and team morale issues.
This situation has changed quite a bit in recent years; again, thanks to collaboration and agile project execution. However, in understanding the bounds of a tester’s role in a product team, it’s important to retain the independence factor. What this translates into is that when testers collaborate and share some responsibilities with the rest of the product team, they have to be very cautious not to assume work that conflicts with their core goals or independence. For example, when testers file defects, the increasing trend is toward asking them to fix some of the lower priority issues that don’t need a lot of troubleshooting.
Say, for instance, that testers are being asked to fix content issues or translation errors, where the fix does not touch the source code, but is purely on the content file level to save time for the developers. The appropriateness of this arrangement is arguable at best. Since these fixes don’t involve any code-level changes and don’t call for any code compilation and build generation, there is one school of thought that says it is very logical to have the testers themselves fix the reported issues and verify them by pushing the updated content files into the testing environment.