But, that’s not my job
A tester met me last week who was very unhappy with the way his Development team is operating. In particular he had complaints about getting little or no information when new features are implemented. He talked in length about how the requirements are only in the heads of their business guys and some how magically transferred to the programmers and testers are in dark when it comes to verifying those requirements. I listened patiently and then suggested: “How about you write a user story or draw a model for them. Then discuss with the business guys”. He quickly replied “but, that’s not my job”. I looked into his eyes and smilingly said “producing quality is every body’s job”.
(the original photo is here: http://www.zazzle.com/thats_not_my_job_trucker_hat-148625291198305783)
I agree that taking ownership of other people’s job can create problems but when there are gaps, it is best to fill that gap by lending a hand. The ‘that’s not my job’ attitude causes problems in every situation but it is more so needed when products are delivered at high rates. If you make it clear to the team so as where the job belongs and then do the job saying “I can help while you are busy/looking at high priority items/don’t see value/etc.”, the job gets done and some day the responsibility goes to the right place.
Here are some things that I have done in different teams as tester, though they were not supposed to be testing’s job:
Moving Defects to Testing’s plate: There are some rules to manage Defect life cycle and one of them is that Programmer/Develeopment Manager/Project Manager should move the Defects to be taken up by Testing team when they are ready. But in my recent team, there was a gap and piles of Defects were getting in the waiting queue. I stepped up and am starting moving Defects to testing regularly though I know (and the team knows) that this will be done by Project Manager one day.
Writing unit tests: The established fact is that Programmers should be writing unit tests for the code they write and testers should focus more on scenario testing or workflows. In the API testing project I’m involved these days, at times we are handed over a new API that has no tests. Rather than hitting that API back to the programmers’ face, we do the friendly act to write the unit tests and then write scenario tests. The team knows the value put in by us and they know they need to do it on regular basis.
Model the feature or even a product idea: As I mentioned above, at times I have modeled the new feature for the team if I got no User Story/ FS / SRS / all those fancy acronyms. That can be done through any language but I have found mind maps and conceptual maps more easy to work and explain the models.
Have you been through situations when the rest of the team is not doing their job? How have you handled those situations?