My eyes were recently opened to a different way of doing something I do several times a week and have never questioned. Watch this:
Now this seemingly trivial act, peeling a banana, never crossed my mind as being something that could be optimized, as something that primates had mastered ages ago while I’m sitting here comparatively banging it against a rock to get the tasty fruit out of the peel. But this is not only a convenience I will benefit from for the rest of my life, it opened my eyes to something more. The fact that we operate on autopilot for most of our lives is quite useful, it helps us get through the day without having to actually methodically think through every little decision we have to make every second of our lives, freeing our minds to think about more important things than place finger on ‘a’ and press down, nod head to convey agreement, extend hand to shake, peel banana, etc…
The down side of this transient mode of operation is that it causes us so much effort to step back and think critically about our actions that we often do not do it, and don’t even realize we’re not doing it. We don’t ask ourselves questions like: “Should I actually be doing this activity?” or “Is there a better way to accomplish my goal?”
Regular retrospectives such as the one prescribed by Scrum or Kanban’s Kaizen events are good examples of trip wires that allow us to stop and look back at what we’ve been doing and ask ourselves how our manner of operation could improve.
Pairing up can also be a good way to keep sharp by having someone else to keep you on your toes, even better if you’re not as comfortable with your pairing partner.
I also find James Bach’s simple “Huh? Really? So?” technique useful for sparking critical thinking on a given subject:
Are there other techniques you use to keep sharp and make sure you’re identifying and questioning your assumptions?
I was turned onto this banana clip by Chip and Dan Heath’s Decisive. A great book about decision making that I will probably review in more detail later. I highly recommend it for anyone that makes decisions, which means YOU.
I’m currently reading Thinking, Fast and Slow by Daniel Kahneman. It’s a great read. The research he has done and has surveyed for this is amazing. It’s helping me to be aware of the traps I fall into daily because of the way I’m wired. The thrust is behind understanding two systems the brain uses (fast, intuitive vs. slow, methodical). We need both, but sometimes the fast, intuitive “System 1” takes over when we’d be better off slowing down to let “System 2” work something out. I will post more specific lessons I take away from this, particularly as they relate to testing in the weeks to come, but do check it out. Fascinating stuff.
I’ve been doing a bit of interviewing lately for additions to our team. This is how I model the interview.
I think of the interview as an exploratory test session (or series of test sessions depending on your interview model) and each question as a test idea to explore. Testers should be really good at interviewing because they’re skilled and practiced at predicting failure and testing for it. This is what I’m trying to do in an interview.
I’m learning and adapting as I proceed through the interview, coming up with new ideas for interview questions for the candidate based on what I’ve learned from the previous interactions. For example:
We may be running a hands on test exercise to explore knowledge around performance testing, then the candidate may mention something about the code in one of the responses that alerts me to a new “feature” of the candidate to explore. Perhaps I find out they know something about the technologies used in the application they’re testing, this prompts me to find out how much they know about the technologies involved and perhaps their experience with white box testing. Or perhaps they reveal to me in their response some very egregious assumptions and we explore that line of thinking to find out if there is maybe some one-off reasonable explanation for this or if it’s more likely a larger threat to the value they can provide.
The point of the interview is to expose value and any critical risks in the candidate that would either cause us to go with another candidate, or at least go into the hiring process with open eyes: understanding what we’re getting into with regards to expectations we can reasonably have of the candidate, what we’d be willing to pay for the candidate and feel satisfied we’re getting a solid ROI, how much and what kind of training the candidate will require, etc…
Just like a test session, I am well-served by having a clear idea of my chartered objective, ensuring the team understands it (if it’s a group interview), and debriefing afterwards with the interview team or hiring manager so we can decide if we met the objective and how much further interviewing needs to be done.
So, if you’re just reading off a list of canned questions, you’re really missing out on a great opportunity to dynamically explore the risks and values your candidate presents.
Came across this great list of testing blogs from TestingMinded.com. Check them out!
With so many great thinkers in software testing out there, there’s no reason why we shouldn’t be collaborating and learning from each other.
What are you waiting for?
I’ve been meaning to do this for some time, but at last the day has come. I’ve finally gotten around to putting my thoughts out into cyberspace. Hopefully this serves as motivation for me to do some writing to synthesize my thoughts on what I’ve been learning. I hope to be challenged and have some great discussions. Topics may jump around a lot but there will probably be a lot related to software testing, since that’s what I do for most of my waking week and probably a lot on self-education, since that’s the point of this blog, to help further my self-education.
Welcome! Hope you enjoy the thoughts I have to share and I hope you share yours with me. Let’s learn together…