Report from StarEast 2011

Some people wonder why I present at several conferences each year, since I’m not a consultant. The answer is that I learn a lot at conferences, and meet helpful people, and the only way I get to go is if I’m invited to do a tutorial so that I get a free conference registration and get my expenses covered. It’s fun to catch up with friends and colleagues, and make new ones. In this Twitter age, I get a huge kick out of meeting Tweeps in person, which I always do at conferences!

The first tweep I managed to meet in person at StarEast is Naomi Karten, author of Presentation Skills for Technical Professionals: Achieving Excellence (among other books). I’m pretty sure I first heard of Naomi and her book by following her on Twitter, because someone else I follow on Twitter recommended it. She got in touch with me before the conference, and we met up for a walk and dinner. It’s a privilege to talk to leading professionals one-on-one at conferences, and this is one way I’ve been able to grow professionally.

Here are just a few of the many highlights for me at this year’s StarEast.

Sleeping With the Enemy

Gojko Adzic inspired me with his keynote, “Sleeping With the Enemy”. (Take a look at his slides here: I love his definition of independent testing: it’s there so that when you don’t catch a bug, people can blame you. Independent test teams become “alibi generators”. As Gojko says, people blame testers when quality goes down. We testers should stand up for ourselves and find out what it is we’re not testing, whether we are testing the right things, get feedback so we can improve.

Gojko has more than fifty case studies of teams that are succeeding in their testing, especially using Specification by Example. (They’re documented in his upcoming new book). When testers take on all the testing work, they get stuck, they’re suddenly the only ones who can test. It’s vital to make quality everybody’s problem.

Gojko went so far as to suggest changing the name “tester” to something else, to emphasize that testers should be the people who ensure the right testing gets done, not the people who do all the testing. This is an intriguing suggestion. Do you have any ideas?

When everyone thinks about quality, and developers do the test automation, automation won’t fall behind. Gojko convinced me with his argument that when experienced programmers do the test automation (which after all, is just more programming), testers are freed up to do their most important work, such as exploratory testing. I’ve been trying to teach good automated test design skills to non-technical testers. It makes much more sense to get the programmers involved to automate the tests while testers come up with the right test cases to automate. So my new mission is to teach testers and programmers to collaborate, own quality together, and automate tests or “checks” together so that the testers have plenty of time for other critical testing activities, such as exploratory testing.

Network & Grow

As a person with a short attention span, I love the idea of Lightning Keynotes. I was surprised and disappointed that despite all of the many excellent women presenting at StarEast, the organizers only invited one to give one of the ten lightning keynotes. I would have preferred more diversity.

The lone female lightning talker, Dawn Cannan, was also my favorite. She inspired the crowd by telling her own “rags to riches” story. At her first StarEast, she made the most of her opportunity by asking presenters if she could talk to them during breaks or in the evening to ask questions and learn more from them. I remember meeting Dawn at StarEast a few years ago in the bar, to which Elisabeth Hendrickson had invited them after her tutorial. I was impressed by Dawn’s eagerness to learn and grow professionally. Since then, she has made significant contributions to the testing community, through her writing and presenting.

Dawn showed a slide with her resumé (CV) and asked, “What can you tell about me?” It doesn’t show what kind of person she is, what kind of tester, how she works with others, how she solves problems, whether she has good critical thinking skills.

However, anyone can look at Dawn’s tweets on Twitter and see the kind of questions she asks, how she helps others, how well she communicates. On her blog, you can find out about problems she’s had, how she has solved them. It answers the questions you often hear in interviews, “Tell me about a time when…”

Dawn advised conference delegates to start blogging, express your opinion on specific issues, tell stories about the issues you struggle with. A blog will show your leadership qualities, even if you don’t see yourself as a leader. She also recommended joining Twitter, as well as local and online user groups. I particularly loved Dawn’s “Pro Tip”: hang out in the bars and restaurants after the sessions at StarEast! I hope lots of people took her advice. As Dawn says, this is how you develop a network. When you have a question, need a job or a reference, you’ll have easy access to the help you need.

Dealing With Change

I’m not usually a big fan of keynotes, but StarEast sure had some good ones. I was keen to see Naomi Karten’s, to see if she “eats her own dog food”. After all, she’s written this great book on presenting skills, which helped me grow my own presenting skills. I can now tell you with confidence that she’s one of the best speakers I’ve ever witnessed. She’s clear, funny, her slides are perfect, and her message is practical and immediately useful.

Naomi talked about change. This was especially timely for me. The Friday before I left for StarEast, I found out that the tiny company where I work has been acquired by a big giant company. So I need some good coping mechanisms.

Naomi told us about the work of Virginia Satir. Change starts with the way things are. Then there’s a jolt, followed by a period of chaos, a bumpy adjustment, and a new normal. It can take a lot of time. People resist change, and Naomi referred to a paper of Dale Emery’s about using resistance as a resource. Lots of things to dig into post-conference here!

Per Naomi, change is really all about the chaos. If it were only the jolt, the adjustment and the new normal, we could deal with it. So we have to acknowledge the chaos, find ways to minimize it, and take care to not make irreversible decisions when we are in it.

Chaos will cause productivity to drop. Recognize it. Naomi said managers don’t need to “mollycoddle”, but I disagree. I think managers need to provide lots of time, training and support during periods of chaos, and help people transition to the “new normal”. What’s wrong with a little mollycoddling, if it helps a team get through a change, enjoy their work, and deliver a good product? As Naomi points out, any change is going to take longer than you thought.

Test Design for Exploratory Testing

I enjoyed Paul Carvalho’s track session on real-time test design for exploratory testing. This statement really resonated with me: One cannot be told what exploratory testing is, one has to experience it. I know a lot of testers who can’t articulate what they do, but they are contributing important value by doing it.

Paul also referred to work by Virginia Satir (I first heard of her in Naomi’s keynote, now I hear everyone talking about her), and Carl Jung, saying that the congruence model and behavioral psychology help us understand more about humans, and thus more about the software we design.

Paul’s inner science teacher came out as he showed us one way to model the different attributes of quality we want to test, the different types of testing we want to do, environmental attributes, product features. Mind maps are a nice way to think of testing missions, but a two-dimensional model just can’t capture all this information. Paul built a 3-D model out of glow-in-the-dark plastic straws, using sticky notes along the axes to show different types of tests. This struck me as a great tool to help plan our test strategy.

As Paul says, given that testing isn’t linear, we can’t test it with a linear model. He brought out even more dimensions, such as time. What if we got away from test plans, test cases, test reports, and add back just what we need by coming up with a new strategy for what we’re testing right now?

There were so many ideas and references crammed into this session I can’t enumerate them all, but the conclusion hit home with me. Stay focused. Talk to the stakeholders, see the big picture, find out current risk, consider time and resource constraints. Think about what your team knows about the whole product or solution – not just the software.

The Test Lab

Bart Knaack organized the “Test Lab”, which was my favorite place to hang out at the conference. Laptops were set up around tables, with testing missions described in Big Visible Charts. We could choose an application to test – I chose FreeMind, which is mind mapping software. We could log bugs in Mantis, and there was a competition around bugs (I didn’t pay enough attention to the rules, but I think it there were prizes for the best bug or the most bugs found). If you participated, you got a “Test Lab Rat” button, and if you found a bug you got a “I logged my bug in the Test Lab” button. Rob Sabourin had about 20 of these buttons, so I’m guessing he was a winner.

Another aspect of the Test Lab was demos from various people. I did a demo on good ways to design automated tests, which solidified my conclusion that Gojko Adzic is right – I need to stop trying to teach code design to non-programmers, and focus on teaching testers and programmers more ways to collaborate. I got a “Test Lab Helper” button for this, so by the end of the conference I had lots of Flair on my badge!

The Bach brothers had a popular demo of their exploratory testing techniques. Dawn Cannan demonstrated Selenesse, and talked about how she set up her hands-on tutorial, coping with the challenge of no WiFi in the rooms (see for more on that). There were several other demos, I saw plenty of presenters as well as participants engaged in enthusiastic discussions in the Test Lab. The only problem was trying to find time to participate in the Test Lab, versus many interesting sessions going on at the same time.

Those are just some of the highlights from my StarEast 2011 experience. I had many great discussions with old friends and new friends, solving the worlds’ software development and testing problems. I met new people to follow on Twitter, which is the reverse of what I usually do – meet them on Twitter first, then later in person. I was excited to meet some fresh faces, people with new ideas and experiences. I hope they’ll take Dawn’s advice and start blogging, tweeting, presenting and sharing their ideas with the rest of our community.

You might be interested in... The Dojo

Dojo Adverts-05

One Response to “Report from StarEast 2011”

  1. Ajay BalamurugadasMay 13, 2011 at 1:39 am #

    Hi Lisa,

    Thank you very much for the report.
    I was imagining each and every sentence and I felt I was right there at StarEast. It must have been great experience for you to experience it LIVE.

    Thanks to your report, I have added Presentation Skills for Technical Professionals: Achieving Excellence and few other books to my wishlist and would invest in them soon.

    Thanks once again. Hope we meet soon 🙂

    Ajay Balamurugadas