Very Short Blog Posts (33): Insufficient Information and Insufficient Time

Here’s a question I get from testers quite a lot:

“What do I do when the developers give me something to test with insufficient information and time to test it?”

Here’s my quick answer: test it.

Here’s my practical answer: test it with whatever time and information you have available. (Testing is evaluating a product by learning about it through exploration and experimentation.) When your time is up, provide a report on what you have learned about the product, with particular focus on any problems you have found.

Identify the important risks and product factors of which you are aware, and which you have covered. (A product factor, or product element, is something that can be examined during a test, or that could influence the outcome of a test.) Identify important risks and product factors that you’re aware of and that you haven’t covered. Note the time and sources of information that you had available to you.

If part of the product or feature is obscure to you because you perceive that you have had insufficient information or time or testabilty to learn about it, include that in your report.

(I’ll provide a deep answer to the question eventually, too.)

Related posts:

How Is the Testing Going?
Testing Problems Are Test Results

2 replies to “Very Short Blog Posts (33): Insufficient Information and Insufficient Time”

  1. Hello, Michael!

    “Here’s my quick answer: test it.”

    It is very strange answer from my point of view. I think you should give us a context. Because, actually, when you don’t understand initial requirements about something (who will use, what you going to test, how this will be used and so on), you cannot test it in a proper way.

    Michael replies: The nature of a quick answer is that it is quick. Assuming a context is optional with a quick answer. The practical answer takes on more elements of context (but typically a single context).

    For example, feature A will be used by Group of Users B (and you didn’t realized it before you started your testing), but you start test it, like Users C and found a lot of bugs (or didn’t find). This simply means that you waste your time (and company money by doing useless job). You will provide a report that won’t help managers to understand: can we release feature or we need to fix all bugs that you have found.

    Perhaps, the full answer should be like: “Try to clarify requirements with stakeholders and than test it”.

    That’s a important part of the practical answer. Learning about the product includes learning about its context and its requirements, which in turn is part of the process of exploration that’s central to testing, which is why I included lots of links in the post. Perhaps I should have included a link to the blog post that precedes this one—four and more questions that testers can ask not only during planning meetings, but at any time throughout the project.

    Long time ago I have read “Critical Testing Process” by Rex Black and he reference to an article: “Testing in The Dark.” I don’t remember who is author. In this article author provides his answer what to do, when someone give you something to test without requirements and any additional info.

    In the bibliography to that book, Rex suggests that the author was Johanna Rothman in STQE, Vol. 1, Issue 2. I was only able to find an article of the same title by Johanna and Brian Lawrence, dated 2002. It presents an approach for learning about the product that will work wonderfully well in contexts where requirements and the customers are known by some people, but are perhaps not written down.

    Sometimes the requirements and the intended users are less clear. In those contexts, experimentation with the product and interaction with the users helps people to refine those requirements.


Leave a Comment