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.
The other school of thought is that even such small fixes interfere with the test team’s current work and these tasks don’t really align with their quality goals and, hence, should not be taken up. In an ideal world, this second school of thought is what would make sense, but in the current constraints that we operate within, where everyone shares each other’s work with the goal of releasing a product at the agreed time, cost, and quality, it is worth looking at individual scenarios and evaluating whether or not it makes sense for testers to take them on, as long as the tester does not lose his independent view on product quality.
An even stronger example of where such conflict of interest shows up is testers’ working with developers in creating unit test suites. Clearly, developing and using unit tests are the development team’s responsibilities. It is perfectly fine for testers to provide input to the developers on designing unit test cases, help them with any tool issues they face, and define parameters around exit criteria for a build to be released to test. These are scenarios where the tester is empowering the developer to focus on quality without losing his own independence factor in the test effort. If a tester were to extend this help to creating the unit tests himself, he may soon be tempted to touch the source code to fix any defects or bugs that the unit tests report. This is a clear case of trespassing into the developer’s boundary of operations.
Another classic example where sometimes bounds can be crossed is that of static code reviews. While these reviews have great benefits, e.g., helping the tester better understand the system, catching certain bugs—especially architectural and security—early on, this is an area where the tester is so close to the source code that it is important to intentionally watch and avoid any role trespassing that may result not just in bias in the testing effort but also conflicts with the developer, adversely impacting team morale.
Giving a tester access to the source code has benefits, including better understanding of the system he will be testing, enhanced test coverage, potentially finding bugs sooner than run time, and providing a holistic view into the system. However, it is important to consider the possible encroachment into another person’s role, potential loss of testing independence, and randomization in one’s core tasks. By randomization, I mean the tester will gradually be pulled into non-test tasks, and so he will lose focus on his core tasks. He will be randomized with things that he should not be spending time on. Understanding both sides of the coin will help maintain a healthy balance between the roles of developer and tester with the two collaborating on the right set of areas to ship a product of exceptional quality.
User Comments
@Nabarun : Your experience with SDET profiles does not match mine. To be effective, the SDET needs to be as good as the SDE, only the focus is on test instead of features.
One example where this collaboration works is where:
SDET create
Interesting article.
The problems are not really that of philosophical arguments, but of practicality.
You do not have even 1% developer in Industry who can write good tests. Sorry, none. Used to be earlier some, now None.
That is why we need testers. But then, can these testers write code? The answer is unanimously NO.
Sorry, does not work.
Now, there is this SDET profile. These are set of developers posing as testers. They are not really good at testing. They were, once, decade ago.
Now, as none comes in the test discipline, what people are doing they are recruiting bad developers as SDET, not good at coding, but can write workable code. They think a *working code* is good code. NO, a working code is just an excuse of prototype modelling. Hence, it won't work, some time later, and then... you patch.
So you wanna do static analysis with them?
I will even give you an example. How many developers went through a course on Unit testing?
What is the flaw in the code like if ( a + b > c ) { // flaw??? a, b , c integers.
can any tester find it? Sorry. None. Almost none.
So, then you have these great work force joining hands to collaborate. Let them do it. In the end, a great idea, like collaboration would be utterly destroyed by bad understanding from the both sides.
And we are talking Agile & TDD here. That wont work. Instead of going back to the basics, and training more formally on what historically the weakness are, no amount of collaboration, or non collaboration can bring anything fruitful.
It is not the idea, but the execution would fail, because at the lowest level people are lacking on the complementary skill set what makes them great on what they do.
Congratulations, Rajini, on a delightfully well-balanced and well-argued contribution to our professional development. It should be mandatory reading for every IT manager, whatever development lifecycle they work with.
@John - In my previous gig, I used to be closely involved with the technical/test training group. The gates/checkpoints for someone entering the SDET track need to be very stringent. The typical route I have seen is for STEs entering the SDET path after t