Exploratory test plans? Martin Jansson
How would a test plan be constructed that is for exploratory testing? I would assume it is different from a traditional test plan?
Would we use concepts such as entry/exit criteria for test? I would never say No to a build to test. Skipping entry/exit criteria. I guess it also has to do with the role of testers. Do we act police or are we a service?
Resources needed? Do we ever know how many testers we need? We can give a vague number how many we want to be to full comfortable, but can this ever be fully accurate? If we aim to test as much as we can in the defined set of time, we will do so with the amount of resources that we have been allocated. I guess it also has to do with how you are organized as a team and what your mission is. If the team is running several projects and tracks at the same time it is even harder to determine how many resources that are needed. Do you really want to allocate testers to a certain percentage in different projects?
What is to be tested and how? Well, do we ever know that in advance? We should be able to list tons of test ideas, but isn’t that just our initial idea of what is to be done and that will change as soon as we sink our teeth into the first build.
Do we get the test plan approved and then use it in the project? A plan is just temporary. It will change many times for sure. Planning is better than the actual plan. No matter what project I work in I am able to do planning incrementally, using scrum or whatever tool that is available.
I vote for that the traditional test plan as an unnecessary artifact. One would perhaps not want a generic plan either around exploratory testing?
How do you plan your exploratory testing? What do you focus on? What resistance do we meet from management when presenting our exploratory plans?
If you develop a test plan designed to meet a test approach there is a big chance that you miss what is important.
Instead, Exploratory Testing should be a means to an end in order to reveal the information sought in the best way possible i.e., the test approach might be more suitable for meeting certain information objectives than others.
Then the test plan can deal with when and where we should use Exploratory Testing and why we choose that approach. For other parts of the application or in other phases of the project, there can be other test approaches that might be more appropriate in order to do the job well.
So in order to answer your questions “How do you plan your exploratory testing? What do you focus on? What resistance do we meet from management when presenting our exploratory plans?” I would like to back up for a second and think about why the exploratory testing approach was selected in the first place.
If this approach would be best in order to meet your stakeholders’ information objectives, then you have your motivation right there! But if the approach was chosen due to other reasons than that, you will end-up in a situation where you need to motivate something that might not be defendable (at least in the eyes of those who pays for the effort).
The test plan should be connected to your test strategy and test mission so that the test plan is a plan for how to carry out them in practice. And if the test mission and strategy are firmly established with management, there is a larger motivation for the selected actions in the test plan (note that this is no guarantee for creating a good test plan, but it should take you a long way…).
I think it can be suitable with a short test plan for exploratory testing.
Write the most important things on one page/screen, and there is a good chance stakeholders will read the whole test plan, and comment on things they think are important.
Another lightweight approach might be to use James Bach’s Low-Tech
Testing Dashboard – http://www.satisfice.com/presentations/dashboard.pdf
(especially see slide 4 and forward).
This way you combine test plan with test results and it is “in your face” for team members and management.
I think we should see the test plan as a set of different tools, we should use different ones depending on what context that it works in. The one page test plan would be quick to present and to get feedback on and the dashboard might be an ongoing plan continuely changing. In that case it might be best to identify different ways of communicating what, how, why etc you intend to test.
The exploratory test plan would in that case be context dependent.