Don't test that

Here is the story. We received a customer complaint that she is able to access some data that she was not supposed to. On reading the customer feedback it seemed to me that this was something we usually test for since the access control system is one of our prime sales pitch. So I asked the tester in charge of that particular feature to investigate the allegation. She came back reporting that she was able to reproduce the issue. She seemed tense, realizing the gravity of the situation. By the way, I usually never blame my testers when a problem is spotted in the wild, no matter how serious it is. She knew this, so her nervousness wasn't about fear of blame, but rather about why she overlooked this very important problem. I remained calm to prove to her that we were not playing the blame game. They know the drill for what comes next. I usually ask a series of questions about how we overlooked the issue, and then we start talking about how we can try to avoid missing similar problems in the future. She knew the questions I will be asking, so she wanted to cut the conversation short, by saying that she wanted to test it but the programmer told her not to.

You as a tester just discovered some serious problems with a new feature and report it to the programmer. The programmer shrugs off your claims and tells you not to test those scenarios since those are not important in his opinion. What do you do?

There is a dilemma here. On one hand, I can't accept the fact that I or any of my testers will intentionally blind ourselves from certain problem scenarios. On the other hand, if we do test the forbidden zone, we risk pissing off the programmers, and being accused of not utilizing our time crunch adequately. Being rapid testers, deadline stress is the norm.

There are a couple of ways I play this game. If I feel that these tests are actually very important to test right away, I try to convince my testers or the programmers with scenarios of the kind of problems I expect. Sometimes I would take examples of similar reported scenarios from Customer Support.

If that does not work I go for Plan B. When a programmer says "Don't test that", I take that to mean "Don't test that NOW". So instead of testing those right away, I would wait until things calmed down. What that means is that if we do not anticipate serious problems in the areas we are testing and we still have time before the release (which is pretty rare) we would go ahead and test the forbidden zone. Otherwise we would wait until after the release.

There have been cases where we did not return to these problems due to time constraints or plain forgetfulness and the worse happens, i.e. the problem is reported by the customer. In such cases my testers and I TRY (emphasis on try) not to scream "I told you so". When we decided not to test these scenarios it was a combined understanding between the programmers and us. However it is important to bring this new information to the attention of the programmers and their superiors so that we can avoid making similar strategic mistakes. So instead of gloating over our hunch I would say something like, "Although we agreed that this was not important enough to test, it seems we did not anticipate the current scenario". You have to admit that it was a hunch, since we couldn't come up with any credible scenarios to prove otherwise.

Blame games do not appeal to me. I believe being a Test Manager, it is important to trust the skills of my testers. They must be good since I hired them and have been working with them to improve their craft. I intentionally avoid a signoff process of their test strategies. I play more of an advisory role recommending test ideas I feel were overlooked or complementing them on a plausible intuition. I would even help them in coming up with scenarios to communicate with the programmers or reproducing unreproducible problems or be their peer tester or speed up their testing efforts. They realize I am a facilitator rather than a lawmaker. There will be times I would disagree with them, but my disagreement is not authoritarian. They always have autonomy over their testing. This in no way suggests that if an issue gets overlooked in a product I will use them as a scapegoat. I think that was clearly expressed in this writing.

I understand this is an unconventional way of managing a Test Team. Many managers I know prefer that their testers spell out all their test cases and get those approved by them. They would rejoice when they were right and the programmers were wrong or take punitive measures when issues popup that should have been tested (in their opinion). Many would argue that this is the only way to have control over what is being tested, and to ensure that issues don't go overlooked. However I feel it is only an illusion of control. I fail to see how a Test Manager can know more about the test subject than the tester who spends more time studying it, exploring it and experiencing it. It is inevitable that problems may be overlooked, but when it does I will be there trying to understand it with my testers. I also make it a point to take into account when the stakeholders are satisfied with our testing, and I have found that there are more cases of appreciation rather than dissatisfaction over unnoticed issues.