I am new to Agile but have been reading a lot about Agile lately and suddenly it has become a buzzword for me. Not that I had not heard about it before but it’s only recently that I am actively following it by way of group discussions, reading articles, etc. In fact, a lot of understanding has come purely from sharing real-life issues that we face in our projects and then by discussing the same issues in the Agile context. In other words, we do a ‘what if’ analysis of the issue thereby enlightening ourselves on how Agile could address the issues posed by traditional development methodologies like ‘Waterfall’.In one of such discussions, we came across a scenario where in some project (following Waterfall methodology) the Test team is reluctant about sharing the Test Cases with the development team, huh? Yes. And the rationale behind that is very simple – ‘KRA’ or the team’s performance in terms of the number of defects raised; more the number of defects logged better is the performance. It’s sad but the whole objective of testing in this case is completely negated as the test team is focusing primarily on finding defects as opposed to contributing towards improving the quality of the end product.
Subsequently, one of the question that was raised in this discussion was that if the test team creates the test cases and shares the same with development team then how & what the test team will test since the chances of finding the defects will become almost zero. Sharing the test cases, in my opinion, could become the biggest strength of the project team as it would surely lead to increased customer satisfaction in turn. So, instead of focusing on finding the defect, the tester could focus on improving the quality. Just like transitioning from traditional methodologies to Agile requires a mind shift, the way Agile looks at testing requires a big mind shift as Agile focuses on collaborative development and testing is considered an integral part.
In fact, Agile says that you should test early & test often thereby reducing the chances of failure at a later stage. So definitely, unlike in a Waterfall setup, the test team isn’t expected to wait till the entire feature is developed which will only increase the rework effort. But instead, the test team is expected to collaborate with the developers, share their views, test cases, etc. and ensure that the developed code is an output of a collaborative effort which has addressed all the potential failure scenarios in advance. Also, we have seen that as a tester one is ideally interested in failing the build and send it back for fixing but that shouldn’t be the objective, right?
Often, the culture that an organization has established plays a very significant role in how a project team works. An organization, in general, should define KRAs which encourages the team to work collaboratively and dissuade them from working towards individual performance only. As Henry Ford has said —
“Coming together is a beginning. Keeping together is progress. Working together is success.”
Here, the developer is getting benefited as the code quality has eventually improved but what about the tester?
If the code quality is good, the customer will find it difficult to find defects which will result in higher satisfaction &; confidence in the project team (remember project team includes developer & tester too). And if the team is credited for the product’s success, both developer & the tester will share the credit and not just the developer. Similarly, if the customer has reported critical defects in the delivered build, both the developer & the tester should jointly share the responsibility, introspect & implement the learning in the future iterations. Remember, it’s about working collaboratively instead of playing a blame game. Or as Agile says “We are all in it together.”.
You may be thinking – how will the tester’s performance be measured if he/she has raised hardly any defects?
The answer is – who cares? The collaborative effort resulted in a positive feedback from the customer and if the quality of service was rated at ‘4’ out of ‘5’, both the developer & tester have performed at ‘4’ I would say. And since the tester has been regularly testing the builds, the cost of fixing went down significantly. This is again a major contribution towards a successful release & increasing the customer satisfaction.
But what if the developer claims that his code was indeed better quality and he should be given the credit for the success?
In that case the developer needs some coaching as he/she is not ‘Agile’. If the tester has actually not contributed significantly, then it’s a different issue which needs to be handled differently.
Lastly, in Agile, separate testing team is considered an ‘antipattern’.
