It has always been a good interview technique to ask open questions. Then the person being interviewed have to elaborate and talk in full sentences. In contrast to closed questions, that replied to in binary : yes, no, 42 – the red pill . Until now I really didn’t understand how simple yet powerful this questioning technique is in testing. I might have done it all along, for some time :-).
The primary eye opener was the Copenhagen Context 2015  workshop on Exploration Under Pressure by Jon Bach. One of the treats was that they showed us a list of things to find on the ebay.com website. Not specific items, but information about the items. Finding the most expensive item, and by that stumbling over a live production bug in the max value field. Finding the number of blue shoes available etc. What a fun “online scavenger hunt” – we could battle to find the oldest, longest and most odd details etc.
Later the same week eBay Classified hosted a local meetup of “QA Aarhus” with a live demo of how they do testing sessions of their app. They had to host the session twice, due to popular demand, and what we got was an intro to a setting of exploration, thinking loud and doing pair testing. And I got to try my new-found quest to ask open questions. To search for things – but look out of the corner of the eye for oddities and what-ifs.
But how could I apply this technique in my current testing project of migrating an HR solution for a large IT outsourcing company. I did today. A staff member allocated to the project to test during UAT  specifically the processes they use in the old system and to act distribute this knowledge back to the team. For reasons the testing scope in this are had yet not been established, so they didn’t really know where to start – but I did… open questions
- What processes do you have?
- What kind of events do you need to register on an employee
- Tell me more about vacation calculation
- Where, if any, are your current processes described (I’m fallible)
- What has likely changed comparing the old and new solution
I asked them to go as deep until no new learning could be achieved, but not to detail it in scripts or discrete steps. Because from here we have test cases – test ideas – “a question that someone would like to ask (and presumably answer) about a program”
: Binary replies can be checked, open questions are testing. Testing is “Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.” http://www.satisfice.com/blog/archives/1509
: I have seen how deep the rabbit hole goes…
 Let’s pretend there is such a thing as a “user acceptance test”
 Disclaimer: I was part of the program committee, and by chance most speakers hosts their own testing conferences. See more on http://copenhagencontext.com/blog/2015/01/meet-jesper-at-the-copenhagen-context-conference-venue/
8 thoughts on “Asking Open Questions”
For a tester, its very important to ask questions and have clarity, a tester should never and ever assume anything. Sometimes,in agile agile environment,there will be no clear requirements and specifications.
In such cases, its very important to have clarity on the
application by asking queries.
[…] Not all my projects are thundering successes… Different early decisions have set the scene – but still the play, so to speak, have been full of lessons in what testers find – when asked open questions: […]
[…] on looking to check as many as the simple binary questions in a tool supported way, and work on the open questions for your […]
[…] https://jlottosen.wordpress.com/2015/03/24/asking-open-questions/ […]
[…] experiment from me side to divide the requirements (and hence the tests) into the piles of Closed and Open Questions. Perhaps there is even three piles – Rapid Software Testing has: human checking, machine […]
[…] Asking Open Questions […]
[…] code. Plenty of best practices around ci/cd for web systems. Obviously it depends on how well the knowledge about the system is codified – but you can work on that within your org/team too. It’s more tricky of the source code of […]
[…] of inquiry applies when you are a principal tester or even a senior advisor in testing. Asking open questions and approaching a challenge with exploration proves better than command and control. People are […]