Learning from Agile Testing Days, Put Into Practice

Learning from Agile Testing Days, Put Into Practice

It’s been almost two months since Agile Testing Days in Potsdam, Germany. As you can tell from the subtitle of our latest book, Janet and I put a high priority on continual learning. I went to ATD with specific learning goals, which I achieved. But I also made sure to stay open to serendipitous learning opportunities. After trying out new ideas and practices for several weeks, here are my experiences putting some of what I learned into practice.

Practice and experiment

From the first keynote by Alex Schladebeck and Huib Schoots, I got many reminders at ATD that it’s important to practice our skills. Just like a musician, we shouldn’t practice everything end-to-end, we should focus on the tricky parts. Building muscle memory saves you when you’re tired. Another great message from their keynote which I heard repeated through the week was to avoid being the “hero”. Like musical groups, agile teams are made up of many players and even sub-groups, and we have to work together. Musicians can get shared understanding from listening as well as reading music. On an agile team, we need to make sure everyone knows the sound track. Keeping a cadence helps us improvise, explore and experiment.

Have I been practicing? Not as much as I’d like to, but I’ve certainly been experimenting with some of the ideas I brought home from ATD as well as experiments my own team has designed. For example, I facilitated a workshop on exploratory testing that was open to all the developers at my office. I’d never done anything like that before and it was good to practice it on a friendly audience!

One of several experiments we are trying on my team is to have me as the tester step back from testing every single story. Instead, we are covering individual story acceptance more with BDD (more on that later), and I am focusing on exploring at an epic or feature level. I write charters as we plan new stories, and start exploring as enough of a feature is delivered to test environments. I’ve found a lot of issues that I probably wouldn’t have had time to discover otherwise. Perhaps more importantly, I’ve identified things that got missed, and gotten new stories written to address them. My exploratory testing skills have improved thanks to what I learned from fellow ATD participants.

Start a Movement!

Several sessions, including (but not limited to) those by Sam Laing and Karen Greaves, Dr. Sue Black, Mike Sutton, and Selena Delesie, delivered a similar inspiring message: I may just be one person, but even I can start a movement. Personally I’m more of a first or second follower than an innovator, but those are important roles too! Sue’s practical advice sums it up: Follow your passion, trust your gut instincts, work hard, but not too hard, ask for help, and don’t give up.

Looking back over recent months, I’m glad to say I think I have helped some movements along. For more than a year now, I’ve been pairing with people (especially women) who want to present at conferences but have a hard time getting their sessions accepted because they’re new and unknown. I’ve also mentored newbie speakers through both SpeakEasy and via the Agile Testing Days conference organizers. For example, along with Maaret Pyhäjärvi, I helped organize and facilitate lightning talk sessions (http://www.agiletestingdays.com/session/lightning-talks-1/, http://www.agiletestingdays.com/session/lightning-talks-2/> that the ATD organizers so generously offered for inexperienced speakers. Each and every speaker totally blew us away with their preparation, passion and delivery. At the same time, the conference organizers around the world whom I’ve badgered to invite more of the awesome women practitioners seem to have been following up on many of my suggestions. It’s so exciting to see more diversity in conference programs!

Succeeding with BDD

My #1 goal for ATD was to learn good ways to write BDD style tests. My team had only recently started experimenting with BDD, writing acceptance tests using Cucumber and Capybara, based on outcomes from example mapping “amigos” sessions.

I asked George Dinwiddie for help. He generously gave me a couple of hours of his time, and even served me tea with his awesome miniature tea set! Duncan Nisbet also sat in, asking good questions and contributing his own sage advice. A couple of other folks wandered in and out of our conversation. George clarified the meaning of focusing on the “what” with declarative style tests – “User can save a search” – versus imperative style tests – “User clicks the save search button, focus goes to the search name field, user types in…”.

I got too many tips to include them all here, but what has been helping me the most is to keep in mind the value to the user. I ask myself, “What if this functionality were implemented in a different way?” Maybe we might switch to voice control instead of typing into a UI. My developer teammates and I have worked on handling lower level details in lower level tests, and trying to keep each test to one clear purpose (Markus Gårtner’s test pattern), and writing a test that should be able to communicate for years. Duncan and George also gave me tips for further reading, blogs and articles by Jeff Nyman, Seb Rose and Matt Lynne.

“Ghost busting user stories”

If I had to pick one conference session that was the most immediately practical to me, it’d be Alan Parkinson’s on busting ghost users in stories. I’ve used the “As a ______ I want ______ so that ______” story template for many years. Alan’s session opened my eyes to the fact that almost every user story has multiple stakeholders. By only mentioning one actor, we leave out others.

Using personas when fleshing out and testing user stories helps, but personas tend to be stereotypes. Defining roles and jobs, the responsibilities, duties and objectives each role or job has helps us counteract those stereotypes. Mapping personality traits to personas is helpful, but we want the persona to be realistic, not a stereotype.  Combining personas with jobs and roles helps us discover new risks and ideas for test charters.

As soon as I got back to work after ATD, I made my persona and role cards, and started mixing and matching them for exploratory testing. This led me into scenarios I might not have thought of otherwise. Testing as an extra-impatient, busy and fast user who has a product owner role helped me discover an issue that would have resulted in lost data. I’m going to keep practicing this technique.

What can I do to help?

One message really stuck with me, and I’m not sure now whether it came from Oana Juncu in her session on cognitive biases, Olaf Lewitz’s keynote, or both, and/or other sessions. But it sounds simple: ask what you can do to help. I work on a large team, and some people outside my immediate sub-team with whom I don’t have continual contact are busy and in a rush. There are times I feel like I don’t know how to communicate with them, and as a result I worry that we don’t have an effective working relationship. I’m finding that going to someone like that and asking “What can I do?” cuts through potential misunderstandings. I get a direct answer and usually there are tasks I can do right away. I can add value and feel good about making a contribution. Other times there’s nothing I can do right then. That’s fine too, that person knows I’m available when they need help. I know this sounds stupidly simple, but I hadn’t thought of doing exactly that thing before.

Also, many ATD sessions reminded me that I need to keep working on my listening skills. They’re important for all of us, but I think they are especially crucial for testers. We have to watch out for incorrect assumptions and be aware of our own cognitive biases.

Your learning journey

What have you learned lately from a conference, course, meet up or online community discussion? We’d love to hear about your own learning journey.