The Dotted Line in Role Delineation between a Developer and a Tester


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.

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.

User Comments

John Ruberto's picture
John Ruberto

@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

March 31, 2013 - 1:58pm
Nabarun Mondal's picture
Nabarun Mondal

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.

March 26, 2013 - 4:29pm
Richard Taylor's picture
Richard Taylor

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.

March 27, 2013 - 5:59am
Rajini Padmanaban's picture
Rajini Padmanaban

@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

March 28, 2013 - 1:06am

About the author

Rajini Padmanaban's picture Rajini Padmanaban

As Sr. Director of Engagement, Rajini Padmanaban leads the engagement and relationship management for some of QA InfoTech's largest and most strategic accounts. She has more than twelve years of professional experience, primarily in the software quality assurance space. Rajini actively advocates software quality assurance through evangelistic activities including blogging on test trends, technologies and best practices, providing insights on software testing to analyst firms such as Gartner, IDC. She is also an active speaker in the Star conferences run by SQE and was recently a keynote speaker at the QAI STC. Her writings continue to be featured in TechWell, Sticky Minds and Better Software Magazine amongst others. She can be reached at

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!