Last weekend we held the final Indianapolis Workshops on Software Testing for 2009. The topic for the workshop was 'managing focus when doing exploratory testing.' The attendees for the workshop included:
We opened the workshop with a presentation from me. I shared some tips for using different alternating polarities to help manage focus. The polarities discussed primarily come from Bach, Bach, and Bolton and their work captured in Exploratory Testing Dynamics. In the talk, I gave some examples of using polarities. Those included:
Not much of it is that ground breaking, but when I put it all together, it seemed like an interesting angle on how one might use the polarities explicitly in their testing. If you end up trying any of them, I'd be interested in hearing how it works. I've found those exercises to be helpful with my testing.
After that talk, Brett Leonard shared his thoughts on software testing in the conceptual age. His presentation was heavily influenced by Daniel Pink's "A Whole New Mind." The foundation of Brett's talk was that exploratory testing is both high concept and high touch. Both are concepts Pink talks about in his book:
High Concept:
High Touch
In his slides, Brett summarized the points to say that exploratory testing is the "ability to create, detect, craft, and combine [...] to empathize, understand, to find and elicit, and stretch." The idea of exploratory testing as high concept and high touch resonated with me - those ideas accurately reflect my view of what exploratory testing is.
Brett went on to tie this into the testing he does every day. He shared how his stories about users drives his focus when he tests. He uses his stories to create a testing culture that focuses on value to the user. For him, managing focus is about setting up so that when you test, you're implicitly focusing on value to the user.
As a side note, in his presentation Brett brought to my attention a new polarity! He described using logic vs. empathy when doing testing. I'll see if I can lobby Bach to get it added to the list.
After Brett, Christina (Tina) Zaza shared an wonderful experience report about how she does her exploratory testing when she's working on projects. She talked about setting up for testing, doing testing, and how she avoids interruptions while testing. For me, the highlights of Tina's advice were the following:
Finally, we finished the workshop with another experience report from me. This time I shared tips for writing more effective charters. I find that often when I can't focus when I'm testing, it's because my charter is unclear. The two most well received tips from that talk were the use of a template to help clarify test ideas or test missions; and the use of group thumb voting on priorities to force discussion / clarification on test missions.
While it was a small workshop, smallest this year, I enjoyed it a lot. It's my favorite topic, so that's not surprising. We captured some feedback for next year's workshops, and we'll be working on a schedule during the holiday season. Based on the feedback, next year we'll have at least one or two hands-on laptop required workshops where we can try some of this stuff.
- Andrew Andrada
- James Hill
- Sreekala Kalidindi
- Michael Kelly
- Brett Leonard
- Brad Tollefson
- Christina Zaza
We opened the workshop with a presentation from me. I shared some tips for using different alternating polarities to help manage focus. The polarities discussed primarily come from Bach, Bach, and Bolton and their work captured in Exploratory Testing Dynamics. In the talk, I gave some examples of using polarities. Those included:
- explicitly defining polarities in your mission
- using polarities to help generate more test ideas
- using polarities as headings or sub-headings when taking session notes
- using polarities when pairing with other testers
- focusing on specific polarities using time-boxes
Not much of it is that ground breaking, but when I put it all together, it seemed like an interesting angle on how one might use the polarities explicitly in their testing. If you end up trying any of them, I'd be interested in hearing how it works. I've found those exercises to be helpful with my testing.
After that talk, Brett Leonard shared his thoughts on software testing in the conceptual age. His presentation was heavily influenced by Daniel Pink's "A Whole New Mind." The foundation of Brett's talk was that exploratory testing is both high concept and high touch. Both are concepts Pink talks about in his book:
High Concept:
"Ability to create artistic beauty, to detect patterns and opportunities, to craft a satisfying narrative and to combine seemingly unrelated ideas into a novel invention"
High Touch
"Ability to empathize, to understand subtleties of human interaction, to find joy in one’s self and to elicit it in others, and to stretch beyond the everyday in pursuit of purpose and meaning"
In his slides, Brett summarized the points to say that exploratory testing is the "ability to create, detect, craft, and combine [...] to empathize, understand, to find and elicit, and stretch." The idea of exploratory testing as high concept and high touch resonated with me - those ideas accurately reflect my view of what exploratory testing is.
Brett went on to tie this into the testing he does every day. He shared how his stories about users drives his focus when he tests. He uses his stories to create a testing culture that focuses on value to the user. For him, managing focus is about setting up so that when you test, you're implicitly focusing on value to the user.
As a side note, in his presentation Brett brought to my attention a new polarity! He described using logic vs. empathy when doing testing. I'll see if I can lobby Bach to get it added to the list.
After Brett, Christina (Tina) Zaza shared an wonderful experience report about how she does her exploratory testing when she's working on projects. She talked about setting up for testing, doing testing, and how she avoids interruptions while testing. For me, the highlights of Tina's advice were the following:
- block off time to test (1 to 2 hours), close out email and IM, and schedule a conference room if needed so people know you're unavailable
- before you start, open up everything you think you'll need to do your testing effectively: applications, databases, spreadsheets, tools, etc... -- this way you won't get distracted or slowed down mid testing
- prioritize your tests - she listed three methods she uses:
- faster tests (or quick tests) first
- higher risks tests (or tests more important to the business) first
- group features together to reduce context switching while testing
- don't stop your testing once you've started to write up defects or to ask developers/analysts questions -- note them while you test, and then do that after your session is completed
Finally, we finished the workshop with another experience report from me. This time I shared tips for writing more effective charters. I find that often when I can't focus when I'm testing, it's because my charter is unclear. The two most well received tips from that talk were the use of a template to help clarify test ideas or test missions; and the use of group thumb voting on priorities to force discussion / clarification on test missions.
While it was a small workshop, smallest this year, I enjoyed it a lot. It's my favorite topic, so that's not surprising. We captured some feedback for next year's workshops, and we'll be working on a schedule during the holiday season. Based on the feedback, next year we'll have at least one or two hands-on laptop required workshops where we can try some of this stuff.