Ad Hoc and Exploratory. What is the Difference Between Theory and Practice?

Ad Hoc and Exploratory. What is the Difference Between Theory and Practice?

Recently a lot of attention is paid to such terms as exploratory testing and Ad Hoc Testing.  From my modest point of view I support this trend. I want to share the experience that we have received and continue to receive, researching and testing simultaneously.

First, I overestimated the weight of those factors that are crucial for the testing team dealing with Ad Hoc Exploratory. Previously, I thought that the knowledge of the domain and expertise of software tester are of the main importance. After the team of testers had worked for several months researching and testing in practice, I realized that much more important in this case the way how an expert on testing takes his job. How such software testing is interesting to this person.

From my experience I can say that a senior test engineer who is not interested in Ad Hoc, in principle, will find much less defects than junior test engineer with a "twinkle in his eye".

Secondly, you must have a clear understanding of what purpose has a team dealing with such types of testing. Management needs to understand what goals the team engaged in exploratory or ad hoc testing.

  • Either this team is ahead of the main group of testing
  • Either this team goes in parallel with the main group of testing and its purpose - pinpoint strikes on key functional areas of risk in the developed software
  • Either this is the main test team, and their goal is to make sure about the maximum coverage testing functional areas in a minimum time
  • Or these guys who get the assembly after the main test, and their goal is to find something that they could not find using already written and passed test cases.

Thirdly, it should be competent control of management’s expectations. Pretty hard to work when someone clearly said: "The quality of your team is measured by number of defects found per week." When this metric is the only gauge of how well this team is - it can lead to a decrease in the effectiveness of people and even to actually demotivating the team.

Knowledge Center
Knowledge Center
Subscribe

*- required fields