During the debriefing of a test event we had earlier this year, one friend genuinely dropped that she had a D’oh! moment, rather than an A-ha! one. I was intrigued, I appreciated the word play, but is now that I finally get her.
I facilitate meetups and testing camps, I attend various testing and development related conferences; eventually today it stroke me.
The value of such events is not just in the presentations takeaways, the skills exercised during a workshop, in the discussions, in the solutions or ideas that one has on the spot, as these happen. It’s not just that. It’s also about the questions that hunt a participant after the event, the introspection that it sparks, and, my recent discovery, the new learning that it triggers. I know, some of you may be thinking: D’oh, Simina, of course it triggers new learning!
I left Stockholm feeling empowered. As testers, we are part of a friendly community, our work is meaningful (I think it is no longer perceived as a second-hand job), we are faced with continuous learning and solving puzzles or challenges is part of what we do. Empowered, but also puzzled: what will I do differently once I get back to work? With no straight answer popping up, I went back to the sessions I attended for review and follow-up. In this post I will share some insights after going back to the first keynote and the session voted for do-over.
Embracing uncertainty in BDD & Cynefin
Questioning is a skill that Liz Keogh seems to appreciate in testers. As an advocate for having conversations with the team when developing a product, she mentioned that she finds testers’ work really valuable, especially if they are involved in the discussions before the coding happens. The “should” from “Given a context / When an event happens / Then an outcome should occur” is a sign of embracing the uncertainty and an invitation to question the scenarios, something that we, testers, do well. With this and some other ideas, Liz stroke me as developer that understands the role of a tester; I may add that she does that better than some testers or even test managers I’ve met. So, given the later, endorsements for our craft coming from her are helpful.
After her keynote on Tuesday, I wanted to follow up on Cynefin. So I ended up spending several hours watching her talk about it and reading her blog. Down the rabbit hole I went!
Each of the four domains from the model have different, specific set of actions: categorize the obvious, analyze the complicated, probe the complex and act in chaos. So when dealing with a conflict it can be helpful to ask if we are performing the appropriate actions – e.g. are we dealing with problems from the complex realm and we are treating them as if they’re complicated? Looking back retrospectively, I could find an example or two when this happened to me. But as a perspective, for a content-driven tester as myself, this model can be useful in estimating complexity, identifying which ways of approaching software would work and take the corresponding actions. This is what I took from Liz’s presentations and blog.
Embracing uncertainty & Ask Questions
Reviewing Zeger Van Hese’s infamous talk on becoming a software skeptic was a natural continuation for Liz’s advice on embracing uncertainty and questioning.
One good thing about having the recording available is that one curious tester could replay it, pause it and resume it at their own pace. That’s what I did. As I was completing my notes from the session, I was able to reflect on its content. One epiphany I had was related to an old Discovery commercial, pledging that ignorance is bliss:
Of course ignorance is bliss! I know now from Zeger’s talk that scientists don’t have a problem admitting what they don’t know; Richard Feynman himself didn’t have this problem either, on the contrary, he admitted that he is not sure about anything.
Moreover, admitting uncertainty guides towards what needs to be learned. And here’s my revelation: if I am looking at a conflict situation as a giant hairball (please bear with me, it’s a metaphor I learned from Karen N. Johnson, derived from the book Orbiting the Giant Hairball), admitting what I don’t know and pursuing that path is the simplest way of reaching that ball of uncertainty, pulling out one thread and eventually deal with a smaller problem. I see this even more valuable during inception or early phases, preventing the proliferation of the “hairball” in time. With this rationale, embracing uncertainty becomes something I can apply.
Another thing that I took from Zeger’s presentation was the focus on questioning: testing is a questioning business, rather than an answering one. It’s our role to critically examine existing information and find the missing pieces. For this, we ask questions and then question the answers. For practicing this, the list of context-free questions that Michael Bolton put together could be helpful. I see in there some good questions that I am usually comfortable addressing, as well as some that I have never raised – e.g. Who can we trust? Is there anyone that we should distrust? Are there any other questions I should be asking you?. This list goes tomorrow to the printer and up on my board near my desk, as an incentive for asking questions.
Last, the review of the content presented by Zeger reminded me of a good online course I began but didn’t finish. The Science of Everyday Thinking is available on edX.org and among its content there are the scientific method, tools for improving our everyday thinking, techniques for learning and retaining information longer and methods to distinguish fact from fiction. Seems like a fine source to help develop the skeptical toolbox.
So this is how Liz’s and Zeger’s presentations helped me continue learning after EuroSTAR 2016 ended. I’ll be back with more notes on the Huddle soon!
If you want to read my previous posts from the conference, here are the links:
