A farmer had a plot of land he wanted fenced in and a limited budget for fence materials. He asked his three friends, an engineer, a physicist, and a mathematician, to propose solutions. The engineer being the practical sort took the full budget and bought the largest amount of fence and laid out the fence in a circle. Happy with his practical solution, he said, "friend, that's the biggest area enclosable with your budget." The physicist scoffed at the engineer's lack of "thinking outside the box" and laid out the fence in a straight line saying, "I presume the fence to extend infinitely in each direction. There, I've fenced half the world." The mathematician calmly took a 5-foot section of fence and built a circle around himself. Once encircled, he proudly announced, "I declare myself to be on the OUTSIDE."A local shipping company has a slogan on one of its trucks that made me laugh out loud inside my motorcycle helmet on the ride in to work this morning. "Thinking about boxes is our business, thinking outside of them is our passion." It got me thinking about the trope of a phrase "think outside the box" as if it were something a person could do all of the time. To me, the logical conclusion would be that all you've done is redefine and then reoccupy the same old box, that is creating a mental construct and living within it.
~ Nerdy joke I heard somewhere.
I was reminded of a recent conference I attended where engineers working in the space where mobile, agile, and QA intersect self-organized a series of 24 panels on topics in that space. Not one panel was on the topic of high quality manual testing. Most of the topics had to do with automation. I had previously commented on that fact to some colleagues who understood the implications. In the days since the conference I have frequently returned to the notion that in all of this thinking outside the box we're doing, we may actually be neglecting the very valuable work to be done inside the traditional box of manual testing. The elephant in the room was the question of how manual testing fits in mobile, agile QA.
Looking back now, I'd like to have raised several questions within that topic to see if people actually needed to spend perhaps a wee bit more time within their boxes before venturing into the untamed wilds of Automationland.
- What is your strategy for truly agile test planning?
- How do you identify testable risks versus untestable risks?
- For that matter, what is your strategy for triaging risks in an agile manner?
- How do you estimate costs for manual testing?
- When should you use strict test cases versus more open-ended exploratory tests?
- How do you message to clients what has been tested?
- What kinds of reports make the most sense for your test scopes?
- What is the best way to organize manual testing in the context of 1 week sprints?
- How do manual testers best discover what to test in new builds?
- How can manual tests establish confidence in product quality over time?
And so on.
Re-examining the box from the inside is not the same thing as "thinking outside the box" unless you, like the mathematician in the referenced joke, prefer to arbitrarily define the box based on the context of what you're trying to solve. So if you're reading this and you are in the business of doing QA on mobile. Consider whether you're placing too much hope on automation to solve the remaining problems found inside the manual testing box. I promise you a little creativity will uncover plenty of room to improve before you simply jump into a whole new box with its own set of problems to solve.