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.
One thought on “Lesson 12: Never be the gatekeeper!”
I have faced this situation recently. Every day, I got a new build with some new fix for a bug which was not in the scope of patch I was testing. The patch that was supposed to get released in 2 weeks time got delayed because the developers wanted to clear their defect queues and hence started fixing defects which were totally unrelated to patch. In addition to that, newer fixes kept coming on a daily basis. I went up to my manager and informed him that this could go on forever and we cannot release the patch in the near future. I also told him that we did not need to package fixes for bugs that customers had not asked about(unless the bugs were showstoppers/blockers). Ideally, I would have loved to tell this in the 2nd week of testing itself, but then, the so called idea of being a gate keeper stopped me. It took me 1 full months to wake up. Btw, we have not released the patch yet!