Testing is blocked? Martin Jansson

Sometimes when I read status reports or hear project managers talk about testing, I hear that “testing is blocked”. What do they mean by that? When I delve deeper in what they are talking about I sometimes see that the progress on workpackages for the testing team or testers in a team have been combined with the result of a test case such as pass/fail/blocked. But that is hardly the truth? As a tester we do a lot of things, not just running test cases (if we even do that form). If we say that one test might be blocked in the sense that it does not provide value in testing further there. That does not really mean we are blocked? Is a blocked test when you cannot get the answer to a certain question you have about a system? Does it mean that a specific test could not be done, but perhaps a similar one be done that would provide as much value?

If everything around you is blocked and there is nothing you can do as a tester, then you can perhaps say that “testing is blocked”. But what about preparing for coming tests? What about automating some of the things that you have found? Did we then mean that we were blocked in the sense that we did not come up with any ideas on things we could do? Well, perhaps you can look at various test idea triggers that can get you going?

Progress in performed test related workpackages and the result of testing are two different things. Combining them does not really give a good picture of what is happening. So, before stating that “testing is blocked” consider if you actually mean that you have no progress or that you are unable to test in a certain area. Based on what you inform and how you communicate, stakeholders will make decisions based on that.

I usually tell my stakeholders that they should not worry about me or my test team being blocked in progress, there is usually something valuable to do. Still, if I say that some tests cannot be performed or that they are blocked, where the result of those tests are important they need to assist with removing those obstacles.

During a daily stand-up meeting in a test team I was part of, nearly all testers reported that they were blocked and that they had no progress in their test cases. We had a long list scripted tests that needed to be executed according to the test project manager. I investigated what they actually meant when they said that. Interestingly, most of them had a test cases that wanted them to go in a certain direction through the system. What was blocking them was bugs. They found lots of bugs, but did not feel they had time to report them because they really needed to gain progress in those intended test cases. At that time we had to work overtime if we did not have enough progress in our test cases. I asked them to instead of trying to run the test cases they use the test case as a test mission or charter to guide them where to go. When they saw fire or smoke, they followed that trail and documented (session notes) what they saw and what happened, but also log all bugs they found. From then on not one reported being blocked in the daily stand-up meetings. The flow of reported bugs increased and the progresss was fine (in the sense that test cases were executed as far as project management thought). Stating that you are blocked might in fact be how you work that does not enable freedom and creativity.

If we were to measure something as a manager of testing, would we then see a decline in testers reporting being blocked when using methods such as SBTM instead of scripted tests that report pass/fail/blocked?

Comments are closed.