A few articles that I read recently and one specifically in the recent past is the motivation for this post. When a defect is identified in production, it is not uncommon for somebody to question why it happened (of course, if nobody is questioning, that would be a bigger issue)? Also, it is not that uncommon to hear developers pointing fingers at testers. In turn a tester may say it's your code and you messed it up, my dear developer!

No software can be 100% bug-free, we all know that. But the kind of issues that we are talking about here are the ones that are avoidable. The kind of issues that you see and say -- ah! as a developer I should have taken care of proper null checks OR I shouldn't have made that assumption about a scenario, etc. As a tester you may think I should have used a different set of inputs OR I should have better tested the boundary conditions, etc.

Several years ago I was first shocked when a developer friend of mine said 'why should I test, that's the job of the QA group'. That was his response to my innocuous  inquiry on 'you just committed some code to the repository, are you done with unit testing?'. Situation, based on my own experiences, has improved from those days.  There is some awareness in terms of unit testing and in terms of the developer's responsibility.

Having said that, there is still a belief that QA is more responsible for the quality or somehow testers can magically achieve quality. Don't get me wrong, there is significant benefit that can be achieved with testing. However, a false expectation to start with is -- if you don't do your job well in terms of designing, implementation, code reviews, etc. but you expect the quality can be improved downstream by testing (and more testing). On the flip side it may not be fair to a developer if a tester says -- the primary artifact is the code, and it is your problem not mine.

I'm fortunate enough to work with some wonderful testers. Some times I wonder whether it is some kind of "genetic trait" that they could come up with some of the scenarios that I would have otherwise missed. At the same time I have seen some mediocre testers who are laid back shrugging off any kind of responsibility. To be fair, we have this kind of people in every functionality of the software development.

The following points may make some sense in this context:

  1. Competence: Without competent people any set of constraints or processes would fail. You may not have super stars in your team but you need a majority of people working with little or no managing, knowing their job responsibilities well enough. This may sound too basic to get into this list, but in reality competency is one of the core issues of software development. For testers, it is very important to train and provide enough support to help them catch up with the pace of new technologies used in the development.
  2. Work as a team: A whole-team approach is a more desirable one. The individuals involved have only one target set -- achieve better quality. Find issues sooner in the development process and effectively address them. If an issue arises at a later point of time it is everyone's responsibility. In Agile Testing book Lisa Crispin and Janet Gregory aptly said:

    When the whole development team takes responsibility for testing and quality, you have large variety of skill sets and experience levels taking on whatever testing issues might arrive. Test automation isn't a big problem for a group of skilled programmers. When testing is a team priority, and anyone can sign up for testing tasks, the team designs testable code.

  3. Management failure: If there is more frequent bickering in terms of who's at fault, a possible reason could be that the managers are somewhere losing their grip on setting constraints. As Jurgen Appelo pointed out recently:

    The good-to-great companies built a consistent system with clear constraints, but they also gave people freedom and responsibility within the framework of that system. They hired self-disciplined people who didn't need to be managed, and then managed the system, not the people.

  4. Root-cause Analysis: A very important step in my opinion that is frequently been discarded; many places it is not even considered. Regardless of who made the mistake or which part of the process has leaks -- the focus must be on learning from those failures. Only when you understand what went wrong you can plan accordingly on rectifying it. I have written earlier about root cause analysis. Here is another nice article on Five whys that I stumbled on recently. Do not treat the symptom, treat the underlying cause which will take care of the symptom.

Please feel free to provide your inputs (in the comments section) as to what worked for your organization, how you perform root cause analysis, and anything else that adds value to this discussion.

photo credit: purpleslog

Be Sociable, Share!