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.

Michael Bolton brought up a series of blog entries on Testing vs. Checking recently with follow-ups here and here. He perfectly explains the differences between the mindful job of testing and the checking attitude. While both have a reason to be done, checking is too often confused with testing. From my experience this has a negative impact on how testing and testers are perceived by the organization around them. If people in the organization get told about testing and indeed have checking in mind, the lowered expectations about testing gives a negative impact on respect towards this mindful and thought-provoking activity.

Michael defines testing as a sapience based activity. You need the human to perform it. On the other hand checking is a pure act that anyone can do – even the computer. Based on my work experience, usually we think up new test cases, which we then start to automate and put into our revision control system and have them run on a regular basis. The former, the invention of the test case, is a testing activity. You need a human for this, since we are not capable of automating this step in our software development cycle. The latter, the mere execution of the automated test is a checking activity. Any computer can do this, and mostly we have this even done in our continuous integration server without required attendance of a human. If something goes wrong, well then we could have a problem and need a human to investigate in the test result and whether or not we have a problem with this outcome. This again is a testing activity.

This is not everything we do as testing activities, of course. There are documentation reviews, bug reporting, etc. that also needs to be done on our course. These also require a sapient to conclude. (I thought about automating that bug reporting in the past directly when an automated test case fails, but didn’t do it – so far.)

Matt Heusser noticed recently that there are few blog entries on testing recently. Personally I have cut my blog posts in the last two weeks down since I had to work on my submission for the Agile Testing Days conference in Berlin in October. There is bunch of blog entries I would like to point my readers to that I have piled up since then. In case you’re seeking for new testing blogs to read, Matt has compiled a list of worthy blogs in his entry on best new software test writing.

Finally I would like to point out to Joe Harters blog. Yesterday he made a great first post. Worthwhile to read and a great story on how to teach testing to your colleagues.