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 is 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 much 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 fewer defects than a junior test engineer with a “twinkle in his eye”.
Secondly, you must have a clear understanding of what purpose has a team in 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 the 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.