Naturally, I replied with a typically long-winded answer. She must have liked it though, because she suggested I cut and paste my reply into a blog post. Here it is!

The key thing with a newbie agile team is to not say “move testers on all teams into automated testing” but “help all teams learn to take whole-team responsibility for quality and testing, and learn how programmers and testers collaborate to automate tests at all levels”. Automated test code is code, and generally, it’s much quicker and better in the long run for programmers to code the automation fixtures. Testers know what to test, and when programmers do the coding, testers have lots of time to help customers come up with examples of desired behavior to turn into tests. Then they can pair with the programmers to automate regression testing and any other types of tests (performance, load etc). Then they will still have time to do the all-important manual exploratory testing.

If they read our book Agile Testing, they will learn that they have to be patient and invest a lot of time in learning and experimenting with different test frameworks. And they should use Mike Cohn’s test automation pyramid concept to see where they’ll get the best ROI in automation. Generally, they should always start by learning how to do TDD and get traction on unit level tests. Then they can move on to API or service level tests, then GUI. But that’s not a rule, each team has to figure out what’s best for them.

I highly recommend Gojko Adzic’s Specification by Example book, and also his blog, gojko.net. Markus Gaertner has a great ATDD book coming out but it’s not published yet.

There are SO many test frameworks, drivers, tools, it’s overwhelming. Recently we had to find a way to automate GUI regression tests for our new code that uses Dojo. Our existing GUI tools aren’t able to interpret the Dojo JS properly. It was truly a team effort, though not a smooth one. Our sys admin had earlier played around with Selenium, and we thought Webdriver might work. The sys admin did a spike and proved it did work, then he and our senior architect spiked a couple of different frameworks – one homegrown, one using Geb. They demo’ed it and got everyone’s opinions. For now we are going with the Geb framework, but down the road we might decide it’s not quite right and try something else.

Anyway, that’s a long-winded answer. One good place to start getting an idea about functional test tools is the Agile Alliance Functional Test Tools group’s spreadsheet comparing various tools, at http://bit.ly/AgileTestTools. When the teams are ready to think about functional testing, they might take a look and get an idea of all the choices. It’s a good idea to stop and plan a test automation strategy.

It is really, really hard to get started with test automation. There’s a period where it’s just extra work and no reward. But eventually they’ll cross over that Hump of Pain and start reaping the benefits, eating away at their technical debt!

Mike Sutton moving cards on talk task board

We did a lot of fun exercises, and had lots of opportunities to do the “failure bow” (similar to “How Fascinating” in Language Hunters) we learned from Tobias in the warm-up this morning. We encountered so many things that happen on software projects. For example, when we had to draw a picture by committee, each person had a different viewpoint on the picture and a different idea of what we were drawing.

Ball Flow Game

Next, I joined the Ball Flow Game facilitated by Olaf Lewitz and Gerry Kirk. This turned into a hilarious example of “too many cooks in the kitchen”, in my opinion. Just try to get a bunch of agile coaches together and get something done! We started out really well, producing the inventory of “magic balls” efficiently, in just over one minute.

Then, naturally, since we had done pretty well, we changed everything at once and came up with a totally new way to “deliver” the magic balls. My personal estimate of five minutes was not too far off the real result. It was a good opportunity to reinforce the fact that it is better to do small experiments and only change one thing at a time than to do a drastic reorganization.

Attempted Game Development

Paul Boos, one of the ACCUS organizers, was kind enough to let me take a slot in the agenda to get help in trying to develop a game that would teach tester-developer collaboration. My goal was a quick game that would teach testers that it’s not a bad thing to test early and often, and teach programmers that it’s valuable to have testers involved throughout development. I can’t afford Legos and I don’t like to check my bag when I travel, so I wanted to do something with a construction kit that uses plastic straws (similar to drinking straws) and connectors.

Some participants created works of art!

A wonderful group of people came to help. They started throwing out ideas, and it first, it seemed there was no way I could create the kind of game I wanted with the straw kit. While they brainstormed, participants built some awesome straw constructions, proving that using our hands does help us learn and think!

It turned out that you can build a lot of two-dimensional shapes with the straws: squares, rectangles, circles, arches, hexagons, lips. The group proposed that the first part of the game would be for each team to build all the shapes. These could be “tested”. In the second phase, each team would put the 2D shapes together into 3D shapes, and try to build the biggest structure that could hold its own weight when picked up. This also would encourage incremental testing.

An additional idea was to throw in “hidden requirements”. For example, when the facilitator comes around to verify the 2D shapes, she could say, “That is indeed a square, but I forgot to tell you, all the straws in the square must be blue.” This would simulate a real-life project.

This isn’t the quick game I envisioned, but it has potential, and I think it’s worth trying out. Thanks to everyone who helped me, I’d never have thought of this on my own! Collaboration rules!

I’m looking forward to Agile Coach Camp and more learning, insights, and friends.

Software Quality Connection, “How to Improve Communication between QA and Development“

SearchSoftwareQuality.com, “Agile development: The whole-team approach”

Also on SearchSoftwareQuality.com, “The whole-team approach to Agile development: Examples and benefits“

I’ve got a bunch of tips and Ask the Expert Q&A on SearchSoftwareQuality.com, please check them out! I’d appreciate feedback.

I have a new article on TechTarget’s SearchSoftwareQuality.com site, “Getting on the Same Page: How Testers Can Help Clarify Requirements”. I’d love to hear of your own experiences in this area.

This book is a model of concise, clear writing. It’s packed with information in the form of narrative, bullet points, graphics, photos, stories of real teams and projects, exercises, tips and examples. The authors have been walking their talk for a long time, so you can feel confident about following their advice. Their flair for language makes the book fun to read. It could be a quick read, except you’ll find yourself stopping to reflect on your own experiences, and thinking about how you could apply the technique you just read about on your own team. Each chapter includes hurdles you may face, and a checklist summarizing action items for you, the reader.

I particularly enjoyed the little vignettes with dialog from a typical team illustrating topics such as “Not Quite Done Yet” and “Getting Ready to Demo”. The authors have insight into all aspects of coding, testing, and managing software teams. You’ll find advice you might not expect in a software-related book, such as “Be kind to yourself”. The focus on people and teams will make you a better person and team member.