Adam Goucher wrote today a blog entry on being the gatekeeper as a software tester. Adam writes that it is a bad idea to be the gatekeeper, but there are of course situations where you can’t refuse to play the game of being the gatekeeper in software testing.

The topic line is taken from Lessons Learned in Software Testing. James Bach, Cem Kaner and Bret Pettichord reason pretty well about this. In a private conversation with Michael Bolton we indentified that “ship it” or “don’t ship it” is a business decision and thus far I wasn’t able to make these sort of business decsisions due to lack of particular knowledge and influence about the project, the development methodology, etc. Maybe there is something more to come for me, but in my roughly three years of experience as a software tester, I never was in the position to make these decisions.

Particularly why Adam’s blog entry raised my attention is that I was faced a gatekeeping situation lately at work, and I refused to be the gatekeeper there – for good. Over the past few months we had a big deal to work with in order to get the project off the shelf which we worked on over the complete year. Of course, there is a customer, which has stated intentions to give some of his money to us, if we finish this off properly. We are delivering our software to another company which is then installing it for the customer. None of the three companies – the customer, the company we’re delivering to and ourself – seems to have a proper picture of the business logic of the customer. All we get is data dumps from the legacy system which we then convert and adapt for our product.

Over the project course I was faced with the situation that the data dumps we got were incomplete. We were realizing a change request and needed that data dump, the changes should be delivered by the next business day. The software was going to get shipped and right after sending it to our colleagues we realized there were severe gaps in the data we got. So, what to do about it?

• Be the gatekeeper, disapprove the delivery and wait one week for the next data dump.
• Raise the point to the project manager and let him make the decision about this business issue.

Clearly the first option was never considered by myself, so I stuck to the second option for good. This case should make the point clear why gatekeeping as a testing is no good option to give in. If I had made the decision to not install the change request which was pending for over one or two months, the business would have been blocked, we would have gotten the full blame. On the other I would have gotten the blame when we delivered the software and I let it go through in the gatekeeper role and it did not work properly. On a side note, the project is spread between Germany and Brazil with a pretty five hour timezone delay between the two locations, which makes communication hard.

How would you have reacted? Maybe there is an option I oversaw here or did not consider since it seemed too stupid in first place.