Pair questioning - no murks; all are igniting sparks.

I have been practicing exploration of the systems that exists and don't exists, from the day my mother taught me to learn, while I was learning by writing on the walls of my house 22 years back. Started the exploratory testing of *systems -- software applications when I got my first job. I practiced pair questioning with my mother while I was writing on the walls and floor of my house, on black slate with piece of chalk, in the books -- when I observed my mother writing down in a little book for all the things that need to be done, that were done, how it was done, how to do etc.
*systems -- independent entity interrelated (or not interrelated) to make unified whole. In this context, referring a software application as model of a system.

From my school days, I write my explorations, findings, results and many more in a book that I carry with me. The below snap is the book where I write all my test ideas, exploratory ideas, questions, data, diagramming and all other that I get for my craft works (testing), which I do for the employer of me.

Picture: Photo snap of the book I use for writing down all my craft works stuff.

I had and have been in pair questioning (testing) with tester's, which gave us floods of thoughts, ideas and questions. For the first time I did pair questioning along with a person who wrote the system's model.

Before questioning by sitting with developer colleague, I did modeling of the system that will be questioned by us, collected information's about what to question (test mission), collected the supporting information's in written form that were available if any, thought of strategies for how to design and execute the questions simultaneously and make use of the information which will be yielding from this, and how to make use of the information's which we get from all these investigation's with the heuristic that were thought and those were used, by writing down all these in the book which is in above snap.

Later, I explained with an illustration to my developer friend, how we will be working and what strategies we will be using for the test plan that was plotted and agreed by both of us with TEST MISSION that was set.

I use SBTM (Session Based Test Management) approach by modifying it for my project contexts from past one year. My credits to Bach brother's -- James Bach and Jonathan Bach for giving such an exploring approach that can be tailored for the, set test mission. This approach is working fine for me, not sure for others.

I am unable to put or present here the replica of what we did, as I am not supposed to disclose the project details as I too have signed NDA (Non Disclosure Agreement). But the few things I can share here is the SBTM approach I used and use:

• Test Mission: To identify the possible ambiguities and critical information's from the sub model "abcd" of the model "PQRS".
• Approach: Session Based Paired Exploratory Testing.
• Testers: Mahesh and Ravisuriya.
• Environment on which model is tested: Name of the OS, Version of OS, Kernel name of OS, with hardware-software configuration of machine and environmental conditions where the model was questioned at the time of test execution.
• Model and areas of model being questioned: abcd.
• Installation type of model: Type of installation by which the model was installed for use -- Fresh or Upgrade or Repair. Uninstall -- if being tested for uninstall of the model.
• Set session duration: 60 minutes.
• Start date and time of questioning the model: 29th April 2009 9:01 AM.
• End date and time of questioning the model: 29th April 2009 10:23 AM.
• Observations and information's: All the inferred and observed behavior of the model, which was driven by context-driven approach.
• Investigations: All the investigation results conducted for the above observations and written information's.
• Opportunity: Any other questioning (testing) we did which yielded us with very helpful and critical information(s) in this set session with spent time duration for it, apart from the framed test mission.
• Issues encountered and remedial workaround: If any seen issue(s) and existence of workaround for the observed, inferred and investigated issue(s).
• Interruption: Will have reason and time duration of pause or stopped time when questioning of the model under test was ended.
• Remarks or Notes: Comprises the conclusion of the session that was completed or not completed with the reason and area of improvement in questioning.
• For more information's: Contact extension number and email-id of testers participated actively in set session.

We spent more than 60 minutes which was set, since we diverted and branched our exploratory testing as we found some crucial and critical information's -- this was an opportunity which we recognized and made use of it; but came back to the framed track for the test mission that was set and accomplished it.

Plenty of information's were found during this pair questioning (pair testing) session. And, it was learning and also a fun session with developer being a tester and questioning the model under test. There was no murk in the session, instead all the murk were igniting spark.

Decision makers were able to infer the information's briefed in the document that described the above said questioning session and took the decision.