Is document a dirty word in Exploratory Testing?
Posted on 27. Jun, 2008 by Anne-Marie Charrett in Software Testing, test consultant
I went on James Bach’s Rapid Software Testing (RST) course because some of the concepts and ideas that I had read about exploratory testing and RST appealed to me.  I liked the idea that central to testing is a critical and context-driven approach and I also wanted to put intelligence back into testing.
Iwas curious though, as on some blogs I read it appeared that exploratory testing and traditional testing were mutually exclusive. You are either a champion of traditional testing techniques and provided multiple test documents or you’re in the maverick camp which threw out all documentation and just ‘tested’.
I was relieved to learn that for rapid software testing, this is just not true. I was relieved because I LIKE DOCUMENTS. I like them because in certain circumstances I find them helpful.
Because I have to confess, sometimes I forget to test parts of an application. Even worse, sometimes I don’t want to test the hard areas. Â
A document gets me to test all areas and to test the parts that I really don’t want to test. It helps me remember the results of what I’ve tested because sometimes I need to know that information.
What James Bach reminded me, was that the ultimate goal of testing is very simple. It’s to test an application with intelligence and thoughtfulness. The goal is not to create endless documents on testing. Instead, documents can sometimes be handy tools to assist you in testing.
I don’t think I will ever totally give up on my documents. They are my friends. However, I will make sure that in future, these friends can stand the test of relevance, accuracy and brevity.Â
6 Responses to “Is document a dirty word in Exploratory Testing?”
Leave a Reply
- Back To Basics: Automated Testing
- I have a dream..a software testing dream
- In search of the ultimate bug tracking tool
- Bug Tracking Tools Explained
- Four Stages of Testing Competence
-
Shane MacLaughlin: The analogy to survey becomes even more interestin...
-
Anne-Marie Charrett: Thanks James, thats an interesting insight into th...
-
Simon Morley: I've been doing a lot of talking with our PTB rece...
-
James Christie: I think I've the opposite problem. On any particul...
-
James Christie: I'm not really comfortable with the idea of testin...
Jonathan Kohl
28. Jun, 2008
No, it is not.
-Jonathan
Bruce McLeod
28. Jun, 2008
I have found when switching to exploratory testing that you still need documentation. What I personally find best is when you have the test case open as you go, and document what you have just done, as opposed to what you have to do.
After all results of exploratory testing still needs captured and recorded against requirements. Few customers are ever happy with “it’s tested, you just have to trust me that it is.”
Bruce
Venkat Reddy Chintalapudi
01. Jul, 2008
I don’t think so. But the focus of Exploratory Testing is to explore the software application as if like an end user and see if there are any issues in that context.
The application must be intelligent enough to guide and navigate the user. Afterall most of the users won’t be going through the complete user manuals to work with them.
Venkat.
Anne-Marie
02. Jul, 2008
Thanks for your comment Venkat, though I believe that the context of what you’re testing is not just limited to the end user but depends on what your stakeholder’s are looking for.
For example, the context of the testing may be its compliance to a standard etc.
Estella Moreno
10. Jan, 2009
hi
asgkyr5xs4xf5ke9
good luck
Michael Kelly
07. Apr, 2009
I recently wrote an article on documentation, and as I was writing it I found that I do more documentation then I thought I did. As also realize that my current testing team does WAY more high-value documentation in the form of charters and session notes than I’ve seen at most companies I’ve worked at. My current team writes up a lot, but it’s all new information (very little opportunity for copy and paste) and it’s all focused on solving problems or creating opportunities for tester feedback.