From Nothing to Something

A couple of times I have tried to start on a new project and discover that there is NO test ware at all, and hardly any documentation about how the system works, and I think I have found a way to get a bit of both. In the last project I arrived one month into a three month release (SCRUM based, running sprints with deliveries for each 3 weeks - but not into production) where they wanted to extend an already existing system - and that system had neither test ware nor system documentation. At the same time I only had a few days a week in the project and only two months all in all, so I needed to focus my energy on actually getting stuff done - getting as much test done as I could in the limited time I had with as little overhead as possible.

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

• Mail
• Send
• Receive
• Archive
• ...
• Calendar
• Create appointment
• Send appointment
• Modify appointment
• Reoccurence
• ...
• Tasks
• Contacts

You get the picture :-)

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 :-)