Bloggo back to the blog
Learning from Conferences-->
In my opinion, the most important thing we can do to improve, both personally and together with our teams, is learn. When we learn about new ideas or techniques, we can experiment with them to see if they help us do better work. No learning, no experiments, no improvement.
There are countless ways and venues for learning, but conferences have always been a favorite of mine. I worked hard to learn how to successfully propose and deliver conference presentations, workshops and tutorials so that I could afford to attend conferences and grab all that learning for myself.
I’ve learned a lot from great speakers and facilitators at conferences, and even more from fellow participants. My learning continues outside of conferences with the network I build attending them.
I’m a person who learns well from examples, so in this blog post, I’d like to present just a few examples of things I learned at the most recent conferences in which I participated.
The Importance of Communication
I think of myself as a person with good communication skills, but a talk by Marlena Compton at the recent Writing About Testing 2 conference made me think again. Marlena gave examples of situations where the stakes are high and emotions run strong. I realize that despite good working relationships with my teammates, I often do slip into “fight or flight” mode when I perceive that a developer isn’t listening to me or trying to understand my point.
Marlena had us do an exercise to practice thinking about what we want out of a particular discussion, rather than default to one of two poor choices. Since learning about this, I’ve tried to stop and think about what I want and what I don’t want when I have a conflict, rather than simply reacting emotionally. I also added a book Marlena recommended to my “to read” list: Crucial Conversations: Tools for Talking When the Stakes are High (Patterson et. al., 2002).
Building a Community
Sometimes my conference takeaways are not specific learning points, but inspiration and new contacts to whom I can turn for help in the future. At ACCU 2011, I met a passionate group of developers, many of whom return to the conference each year. They’re on the bleeding edge of development practices, and they also honor our industry’s history, by supporting Bletchley Park, the birthplace of modern computing. Maybe the most important thing I learned here is that it’s most helpful and inspiring to know people from a lot of diverse backgrounds, with diverse skills and experience. It makes me more well-rounded and aware of different approaches. I can try to build that sense of community closer to home, as well.
This is a pretty long-winded example, but it reflects the importance of a particular recent conference experience. A conference presentation may turn your long-standing beliefs 90 or 180 degrees. That’s not a bad thing.
One of my missions for the past decade and more is to help software teams understand that automating all of their regression tests will free time for the really crucial testing work, such as exploratory testing. Without this, we’re doomed to struggling over the long term with high technical debt, and we won’t achieve a desirable level of software quality.
A major reason that I’ve seen for failed automation efforts is poor test design. Testers are given the task of automating tests, but they don’t have good code design skills or experience. Without help from skilled designers, they end up with thousands of lines of test code, which takes 100% of their time to maintain. In this case, the automation didn’t free up any of their time – it only added to their technical debt.
For the past couple of years, I had been trying to find ways to teach testers good design practices and patterns, such as “Don’t Repeat Yourself” – extract duplication out of the code as soon as you see it. I’d written articles with examples, and tried various exercises in tutorials, but found it was just too difficult to easily teach these skills. They come from long experience. I started my career as a programmer, but even my design skills aren’t that great, and it’s only when I pair with a skilled programmer that I improve my ability to create maintainable tests.
At StarEast 2011, I attended Gojko Adzic’s keynote, “Sleeping with the Enemy” (slides available athttp://gojko.net/2011/05/04/sleeping-with-the-enemy-stareast-keynote-slides/). Gojko presented a different approach to solving the automation design problem. For a good programmer, test automation is no more difficult than writing production code: it’s what programmers do. For a tester, even one like myself with some programming background, automating tests is something I do only some of the time, and it’s not my strongest or most favorite skill – if it were, I’d probably still be a programmer.
Gojko proposes that programmers do all the test automation – they’ll do it in a fraction of the time it would take testers to do it (I’m paraphrasing here, so I hope I’m not misrepresenting Gojko). The testers work with customers and programmers to come up with the test cases to automate, they could specify those in some sort of framework – a spreadsheet, a BDD syntax, whatever works for them. The programmers write the actual automation code. That way, we testers have much more time for the activities where our skills count most: helping customers specify examples of desired and undesired system behavior, learning about the application through exploratory testing, and turning examples and our knowledge into tests (automated by programmers) that drive development and become our living documentation.
This was a real “aha” moment for me. Automating tests is one of my favorite activities, but I’m not as good at it as the programmers. I’m fortunate that on my team, the programmers write the vast majority of the test automation code. I’m now thinking of ways to help other testers and programmers learn to communicate and collaborate better, so that specifying and automating tests is a true team effort in every software project.
Try a Conference for Learning
Conferences can give you a new perspective. They needn’t be expensive. You can go my route, and learn how to share your experiences through a conference presentation so that you can attend for free. If that doesn’t appeal, there are many excellent local conferences everywhere in the world these days. You might not be able to afford a three- or four-day international conference, but there may be a terrific one-day conference in your part of the world. We had an agile conference in Denver this past April that cost under $100 to attend. I went to a Code Retreat last February that took place sixty miles from my house, and was free. Local user group meetings can provide some of the same benefits: New ideas from presentations, and networking opportunities.
Go to your conference with some learning goals in mind. While you’re there, think about what you’ll do immediately when you get back to the office, how you’ll apply something you learned. Try some experiments. Not everything you learn at a conference will work for you back on your team, but we can only truly learn by doing. Failure teaches us as much – maybe more – than success. Have courage, and enjoy the satisfaction of knowing you’re doing your best work.
Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009). She has worked as a tester on agile teams for the past ten years, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit www.lisacrispin.com. @lisacrispin on Twitter.