TestCraftCamp, the unconference I co-organize, had its third installment yesterday. I'm glad I had enough energy to attend more sessions this time, though of course the "too many good things happen at once" problem remained, as it does with any valuable conference. I was able to join a discussion Maaret Pyhäjärvi (who is so often a driving force behind gatherings like these) about low and high value work, a discussion Joep Schuurkes led on daily writing practices, part of a session Veerle Verhagen hosted on testing without touching (before I realized I'd spent too long looking at the product under test already), as well as finding some of my brethren in between the sessions.
I took notes in a sprawling mind map for another session Veerle hosted, which she pitched as "spicing up your long-term relationship! (with your project)." Besides the memorable pitch, I was excited to see this topic on the schedule for a couple reasons:
First, I've been working on my current product for two years. Some new people have joined the project recently, and having to explain and document the intricacies of our product keeps giving me new reasons to question the decisions we've made as the product has been developed.
Second, I don't think this it's something we typically acknowledge: our skills can get stale and our motivation can wane when we've developed a certain level of comfort and mastery with a particular team and product. Even without changing jobs or teams, it can be worthwhile to shake things up.
On my project, adding permanent designers and engineers to the team is shaking things up. The hive mind in the session came up with many other ways to get new people involved in testing, if temporarily:
- hold a bug hunt or an ensemble
- teach an intern
- swap products with another tester
- bring your product to a meetup
- pay for crowdsourced testing
I collected a sprawling list of people's ideas for how you as an individual can gain perspective and change the way you're looking at your work. Taking notes on a multi-faceted conversation is hard, and in reviewing them, I realize they fall better into these groups:
- identify the assumptions you've built over time (which aren't true? which can be discarded? what's hard to talk about? how can I change perspective?)
- think about risks (nightmare headlines, investigate competitors, talk to users, riskstorming)
- use different testing personas (extreme conditions, soap operas, testing tours, dogfooding/drinking your own champagne, this)
- step back (take a break, go on vacation, switch projects)
As a counterpoint, the group in the session did acknowledge that reaching a point of comfort and mastery can be a good thing. (See chapter 4 of Jerry Weinberg's Becoming a Technical Leader for more on plateaus and ravines.) After months or years on a project, you'll know where to look first for what your developers typically miss. You'll know what's not worth testing. In Veerle's case, the application has been getting 5-star reviews, which provides one positive angle on product quality.
Thanks so much to the facilitators, participants, and other organizers of TestCraftCamp. It's so fulfilling to get to the end of a long day and hear that we created a "safe environment," people who were only planning to stay for the morning lasted all day, and people were able to take breaks when they needed to. I'm glad we were able to fill others back up with energy.