Developers and testers are two sides of the same coin

It has always been my firm belief that 'Developers and Testers both are equally responsible for the overall code quality.' I have seen people being surprised when I say that. "Saurabh, How can testers be 'equally' responsible for the developer's mistakes ?"

It is not about taking responsibility for the developer's mistakes. It is about how most often the relationship between these two halves is developed in the team.

It seems like somewhere we are comparing developer-tester relation with student-examiner. Testers are not there to examine the programming skill of the developers. Instead, I feel developers and testers are like batsmen and bowlers of the same cricket team. They have a common goal, just the different ways to achieve it.

Many times in my professional career I have seen that the annual appraisal of testers is completely focused on the number of defects raised by the tester. Whoever has raised the maximum number of defects, gets the highest pay raise. I have seen testers carrying reports extracted from the testing tools for their annual appraisal discussion to show-off their work.

Let's see in a brief, how it exactly happens -

Tester tends to log as many defects as he/she can because if you on a larger scale ... all the testers are competing with each other on this one quantifiable criterion. On a longer run, this tends to a scenario where testers tend to bombard developers with defects ... causing a shortage of schedule.

This results in forcing developers to apply quick fixes because they have to fix all the defects in time ... It doesn't matter how. As everyone is in hurry to maintain the three weeks sprint, nobody cares about the 'Code Review' ... which ends up in Technical Debts.

However, I certainly don't think this is the right way ...

I don't think it is really a management mindset issue ... they need to have something to compare ... They are just looking for simple rather than the right criteria. It is not about detecting defects, it is about preventing them.

The problem with prevention is that you can never measure the impact 'prevented' ...

This leads to people to let the impact happen, then fix it after enough escalation ... and become a hero.

However, the software has to pay the price of this common human attitude.

I strongly believe that if you are saying that something is not right ... it is your moral responsibility to tell what is right and why.

Therefore, lets see how I always prefer to do in my team -

Team Structure -

• I have always advocated a 'Developer-Tester pairing' in a team. As I believe they both are equal shareholders of code quality, they also should have an equal headcount in the team.

• I observe their team-work over the period and try to bring together those developer and tester who work best with each other.

• I even try to make them sit next to each other for best coordination. This helps improve the testing knowledge of the developer as well as development knowledge of the tester. Over the period, they both start discussing architecture together ... ;)

• It is a long term and never ending process.

Requirement Structuring -

• I believe that requirements have an inherent tree structure. We just have to learn to visualize it.

• Whenever I get a new change request of any size, I always convert the BRD & SRS documents into a requirement tree and HKEH prioritization. I try to break it down to the atomic level.

Scope Definition -

• The next step is the high-level estimation.

• Based on the estimation, define the scope for the current sprint.

• Based on business requirements, I will call the 'Developer-Tester pair(s)' for discussion.

• I assign a requirement sub-tree to one pair.

• I prefer to keep the root with me.

Requirement Understanding -

• They are supposed to go to their desk, study the requirements individually and visualize what they are expected to do.

• They both need to sit together and share their understanding with each other and come to one common vision.

• The next step is to share that vision with me.

• No touching to the code until both of them are at the same level.

Strategizing -

• The developer will come up with the design and the tester will come up with the 'Black Box Test Cases'

• They will share the details with each other and figure out if the design can fulfill all the 'Black Box test Cases'

• At this point, the developer knows what and how things will be tested and the tester knows what and how things will be developed.

• The developer moves ahead with coding and the tester starts preparing for 'White Box testing'

This kind of process helps to minimize surprises to the developer and tester as well as reduces the number of 'Blood Boiling Points' for everyone in the team.

And ... when it comes to annual review ... I evaluate the pair and not the individual. I don't count the number of defects logged, I count the number of clean deliveries and the number of preventable production incidents that were not prevented.

Believe me, that helps in developing a 'Win-Win' understanding between the developer-tester pair and my software doesn't have to bear the load of 'Competition-driven Technical Debts'