How can the tester be certain they will be the next person to do the testing? Maybe it is a contractual requirement for the organisation? If the task was titled ‘develop an acceptance testing suite’ would it be more palatable? Why not use a repository tool that allows for less admin and smarter test development?

I agree that documentation for documentations sake is silly but but not all documentation is silly. What is a ‘drool proof paper’ tests is relative to the reader. Exploratory testing is a useful tool as is acceptable testing, art is in the balance between both. Ideally testers should be but one party in the definition of acceptance criteria but if they are the only one then the so be it.

If formal V-Model testing was the answer to the short comings of a purely exploratory based approach to testing, does it not seem silly that a purely exploratory based approach is the answer to the short comings of formal V-Model testing?

Jumping into solution mode I personally think if the tester was really using their brain then they would use a screen recorder as they performed the exploratory testing. Document your tests and capture the results as you perform them.

Nice post. I agree that an unbelievable amount of time is wasted in the software testing industry documenting (often poorly conceived) tester instructions. I was interested in creating a survey of successful testing approaches to documenting tester instructions and gave a recent presentation at STPCon about how different teams have balanced the need for some written instructions vs. the desire to avoid spending too much time documenting instructions / micro-managing testers.

For what it is worth, I’ve posted my slides from that presentation here if anyone would like to review them: http://www.slideshare.net/JustinHunter/documenting-software-testing-instructions-a-survey-of-successful-approaches

- Justin Hunter

If the test resulted in a formal issue report, then what I would do personally is just reference that in my test notes – along the lines of “This idea resulted in this issue report, go have a look if you have reason to be interested”

If it did not, result in an issue report, (fixed on the fly etc) then I would write a plain english statement in my notes decribing the issue and the sorts of behaviours likely to produce it – on the basis that exactly the same issue is unlikely to crop up in exactly the same way any time soon – but hey, we had a productive test idea that we should at least consider re using in the future.

The only circumstances where I would produce anything like the script described above was if we decided to put an automated check in place for this specific issue, or if there was something so unusual, or so valuable about the bug and the way we found it that I felt writing such a script was the best use of my time.

Fortunately stuff like this is an open topic of conversation where I work – and since I am test manager, I get to ask all sorts of awkward questions when scripts like the one described above cross my desk (which they do from time to time)…

cheers

Andrew

I’ve often captured lists of test cases (test ideas if you like, NOT scripts) whilst performing ET.

Often reviewing is will suggest patterns, gaps and new tests that I hadn’t considered. It can also be useful if the test team’s mission includes change detection (not the most cost effective use of a testers time, but this form of regression risk mitigation is sadly needed on many projects).

As such, I’ve incorporated this as a session output of our local variant on SBTM. I avoid turning these test cases into idiot scripts though – the costs far outweigh any real benefits.

–Iain

One quick way of doing it (and its in-between the lines here) is the stealth testing method that Brian mentioned at KWST. To the outside it looks scripted but on the inside there is just so much more going on. The actual quality of applications produced should not be achieved by the commonly documented testing process. The only way I can explain that is by a lot of stealth testing going on and I believe that is the case.

But why then is it so difficult to just accept this into common process (or less thereof)? Why do we need to jump the hoops like shown above. Is it just the engineering narrow-mindedness that everything needs to be pre-planned? I have been on projects where 70% of test effort was wasted because change at early stages (when test scripting was underway) was immense. If we would have had those 70% back during execution time we could have done the most elaborate Exploratory Testing with -in my firm belief- way better results. Or we could have done with 50% of the effort and saved hundreds of thousands in effort could have gone into BAU support & defect fixing if needed.

This is not a challenge for test or testers but a problem for project managers and stakeholders to address. They need to think about what they are doing and not behave like sheep with a motto similar to “Nobody ever got fired for buying IBM”.

Cheers

Giraffe Tester: Can’t see the small details, but has the perfect view for of the overarching situation.

Hare Tester: Strong, confident, capable.

Turtle Tester: Disappears into their shell, doesn’t seem to be doing much, then suddenly produces amazing results when the Hare overestimates their own abilities.

Andrew R – enjoyed your comments.

I’m revising a test estimate at the moment, and looking at how to squeeze as much out of my team in the restricted window I have.

I’m reviewing risk. I’m thinking of the business stakeholders and the trust they have in me and the team l lead.

We’re in a V-Model/Waterfall-esque culture.

I haven’t considered fun.

I’ve got SME’s in my wider team, I have ex business users as my core team. My team will be guiding SME’s through Business Confidence Testing. It sounds like we have some of the hallmarks of your article (involving the SMEs in the way we’re going to test).

We have a fun environment, but I think that has been by culture rather than science.

I’m going to look at fun in the future … and see how I can get some in there for this estimate.