So here is what I did:
From what little documentation I found I tried to create a breakdown of the system, something like this:
E.g. Microsoft Outlook
- Create appointment
- Send appointment
- Modify appointment
From here I start exploring - actually often I start exploring at the top level, I just find what main areas there are, and take it from there.
As I explore every area I take notes, what functionality can I access from there, can I identify flows?
So I build up my "test tree"as I go along, I learn about the system, I identify new areas to explore and take a lot of notes.
I try to limit each "session" to maybe 1½ or 2 hours and then I take a break and start documenting! Yep you heard right, I actually try to keep track of what I have done and what I have learned, I can reuse the knowledge and I can give it to whoever will come after me in this project - I actually like structure!
In the last project we were using HP QC, that was the company standard and there were no excuse for not doing so. So I found a practical way to use it. The top level areas were folders and each of the sub-areas were then test cases. I didn't write steps (of course :-)) but I wrote the charter - the purpose of the test case.
Now I had an overview of the system - now I took another tool in my toolbox - my test design techniques. And yes I LOVE test design techniques and I love the fact that I have received formal training in it (and I am both ISTQB and TMap certified by the way) - I take all the training and knowledge I can get and use it to enhance my toolbox.
An example; I had this dialogue with 4 fields, some with drop down and one with data entry - I used my skills in data combination testing (Classification trees) combined with pairwise and identified all the variations I would need to address if I should say that I had covered ALL alternatives... and then I used it as inspiration. And by the way I attached the classification tree to the test case for others to use in the future.
After a while I had talked to the users, gotten an idea about some of the flows in the system - so I sat down and made a proces flow diagram and discussed with them whehter I had understodd their system right - and then used that as inspiration for a charter with focus on primary workflow.
When I started to test formal releases I of course created a test plan in QC and added all the relevant charters to that - so I could give a status on progress anytime, and had an overview of my test and the defects I had found.
So a little story from my little corner of "the real world" (hmm I will never be able to use that term again after #agileTD) about how to combine some of the "classic testing skills" with exploratory test - and the demands for documentation. Nothing big an fancy... just practical use :-)