Follow up Questions from the Webinar on “Testing without requirements” with Michael Bolton

The following is a guest post by Michael Bolton a consultant and trainer, specialized in Rapid Software Testing, a skill set and a mindset focused on high-value testing that is fast, inexpensive, credible, and accountable. (More about the author below)


A little while back, I presented a Webinar for PractiTest. There were some follow-up questions.


Kenya asked:  “When you identify an issue that you believe would improve the project/product, what do you do when stakeholders tell you the issue you identified is too small or insignificant? I am sometimes very discouraged about bringing up every low severity issue I find.”

On one level, there may be no reason to be discouraged. As testers, we don’t commission, design, code, or support the product, and we don’t manage the project. Managers and developers often decide not to fix small problems, which gives them time to fix bigger or more important problems. I’d recommend that you report anything that you believe is worth mentioning. You don’t know for sure whether you’re seeing a trivial issue or the first symptom of a disaster.

On the other hand, no one, including you, wants to waste time and effort on formal reports of bugs that aren’t very important, so avoid reporting formally on every low-severity issue that you find. One way to manage this is to report your low-severity problems informally by mentioning them in passing before you turn them into formal bug reports.

It’s not your job to decide if something is a bug. You do need to form a justified belief that what you’re seeing might be a threat to product value in the opinion of someone who matters, and you must be able to say why you think so; you must be able to cite good oracles, that is, your means of recognizing a problem, or else you will lose credibility. For more on oracles, look here:

All that said, if you’re consistently receiving feedback that you’re focusing on things that don’t matter to your clients, you might want to recalibrate. Maybe, by saying that the problems you’re reporting aren’t significant, your client is suggesting that you should pay attention to things that matter more. Try diversifying the elements of your strategy, the set of ideas that guide your choices as you test. You’ll find some hints here:


This is related to the question Christophe asked: “What is a good sign that as a tester your own inferences are getting in the way of your work?”

If you suspect that your own inferences and biases are getting in the way of your work, they probably are. Feedback will help you find out more about that. Consider asking for feedback from your manager, fellow testers, and developers. Try analyzing the bugs that escape your notice, and see if there are consistent patterns of bugs that you’re missing.

Study cognitive biases and logical fallacies, and apply critical thinking to your own work.


Marat asked: “If the tester’s job is to shine light on the most important problems, where should I direct it, if the problems that pose the greatest risk are not in the product?  For example, in large-scale organizations, the approach to Agile software development is somewhat shaky. As a Test Lead I find myself investigating/fixing processes; the problems in the product are the least important.  I can’t just bring information to higher people, only direct interventions were helpful.”

Problems in the development and testing process lead to misimplmentation, bugs, delays, and other problems that affect the business and its customers. Making management aware of those problems and their effects is the responsible thing to do.  It seems to me that you can bring information to managers at any time as part of your ongoing reporting.

It also sounds as though you might be interested in moving into coaching or management work. That’s a fairly common move for ambitious people in a testing role. If you decide to do that, the good news is that your testing experience, skill set, and mindset will help you to a significant degree. Critical thinking is a key testing skill; good critical thinkers, who reflect on how they might be making mistakes themselves, tend to make good leaders.


There were several questions on the theme of requirements.

Conor asked:  “What do you say about the feeling that testers are then just doing the job that requirements people should be doing a better job at? To be clear I believe that testers should do this as well but how do we reflect the effort that testers do in this area where there are a lack of requirements?

“In the end the time lost figuring requirements out can eat into testing time and how do we reflect to stakeholders this time lost? I am not saying we shouldn’t do it, I would like clarification more how do we capture and reflect the effort we put in these cases?

Similarly, Kenya asked: “I don’t have enough time in my sprint to test as is. How do you plan for the time it takes to resolve requirements uncertainty?”

One good first step is to recognize that it’s not easy for any one person to identify all of the relevant requirements for a product and make them explicit. I don’t know anyone who is perfect, and everyone has some strengths and weaknesses. That’s why we work in development teams. Requirements, like software, are not simply gathered or typed out; requirements are developed. And as with software, it takes time, effort, and people working together to find errors, omissions, bugs, and misunderstandings. Review of requirements and discovery of problems about them is part of testing work. Meanwhile, be careful of suggesting that someone “should be doing a better job”.

If you discover problems in requirements, report them. If you see consistent patterns of missing requirements, discuss those patterns. If you have a feeling that requirements problems are disrupting you, try keep track of your time for a while, and get a sense of how much time you’re spending on dealing with those problems. Discuss that with your team and your managers.

In addition to my blog post linked above, have a look at this one.


Valerie asked:  “Couldn’t a lot of requirements-related issues be rectified prior to testing by handoffs including the testers and the stakeholders/product owner or those people who have an impact on result of product end result?”

Sure — although I’d want to think in terms of reviews rather than handoffs. Participation in review is an important way for almost anyone to help the project.


About the Author

Michael Bolton

Michael BoltonMichael helps people solve testing problems that they don’t know how to solve, and helps them learn how to do that for themselves. He is primarily a consultant and trainer, specialized in Rapid Software Testing, a skill set and a mindset focused on high-value testing that is fast, inexpensive, credible, and accountable. He also writes extensively about testing and software development on his blog.

Follow on Twitter: @michaelbolton

Follow on Linkedin:


About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

No comments yet.

Leave a Reply