Friday, March 7, 2008

The border of the mind of testing

If you are a frequent reader of my blog you already know that a lot of things slipped through my mind and makes me bring it in relation with testing. And write those thought down on this blog.

In this case it is not just a though, rather a question. What is more important: the mental status of the team or following the rules you defined to measure quality?

As in lots of projects a procedure is defined how to handle issues which are found during testing. If requirements are written down unambiguously. If test cases are defined according those requirements. If issues are logged according those defined rules. A process like issue registering can go quite smooth. Though, this is not always the case. Issues are rejected by developers. Testers think they are misunderstood. An issue tracking tool is used as communication tool. And people get frustrated which leads to in-productivity.

As issue tracking is also used to measure the quality of a system under test. Are you allowed to disregard the defined procedure and decide that the tester and developer should communicate first with each other face to face to obtain mutual understanding of the issue and define together which way to go? Are you accepting the risk that in this case a developer convinces the tester that it is not an issue and therefore it is not logged? By allowing this to happen, what is then the value of a test case and what is the value of the figures you get out of a issue tracking tool?

Is this a border we are allowed to cross? And what borders are there further?

As said earlier, this blog is not one of writing my thoughts/ideas. It is more about raising some questions hoping you can help me with this.


  1. I have had face to face conversations with programmers and we sometimes came to the conclusion that it was not a defect.

    I still registered the defect, but also the conversation I had.

    If needed for the future use the decision made was registered.

  2. Hello Infratester,
    This is kind of what I meant. Do you register an issue while accepting the answer of a developer that it is no defect. Since it becomes part of registered issues it is also counted in the total of discovered issues. I’m curious which status you are using in this case. Status “Closed” can be interpreted as being solved. Status “Rejected” can be interpreted as wrong test case. Though, it might be a flaw in specifications.

    Is registering for the future wise full in an issue tracking tool? Or should it be also logged under another category?

  3. I would set the status to rejected, but make sure it would end up in the issue log of the project. That way it is more visible and the responsibility of the project to make a decision.