We’ve had so many questions over the past few months about how long our book took to write, what is different from the first book, how did we come up with the title, etc., that we decided to make our first blog post on this site about that. However, we had so much fun going back into what actually happened, that it ended up longer than one post – us, Lisa and Janet, write too much??? Never. Sigh! Anyhow, we decided to turn it into 3 posts so you don’t have to feel the need to read it all at once.
Part 1 of 3
Kick-off
In September 2011, our editor at Addison-Wesley approached us about writing a second edition of Agile Testing. After some soul-searching, we came to the conclusion that our first book could still stand on its own without any changes. However, we had learned lots of new things since writing our first book, so we decided the better alternative was to write a second book. It took us another year and a half to actually start; travel, work and illness got in our way.
We sent our first proposal and preliminary mind map to our publisher was in January of 2013, and drafted our first release plan in April. We planned for a smaller book, maybe 250 pages, with the first draft to be ready for copy editing on March 1, 2014 and the final manuscript due to the publishers set for July 1, 2014. Chris Guzikowski, our editor, had an idea for a title: More Agile Testing. We loved it, and used that as our working title.
Our Process
Back when we wrote Agile Testing, Tom Poppendieck gave us a great tip; write the back cover blurb first. What message do we want to convey, what are our goals, and who is our audience? Of course, writing that is much harder than it looks, but it was a good way to articulate our goals for writing the book. We were amazed later when what we wrote at the start, is pretty much what ended up on the back cover.
We wanted to stay fairly low tech but we are a distributed team (Lisa in Denver, U.S., and Janet in Calgary, Canada), so we needed tools that promoted that type of collaboration. We used Google Docs spreadsheet for our release plan, so we could both edit at the same time and see who was working on which chapters. We used MindMeister for our collaborative mind map, and although it has some limitations, it enabled us to work on it together real time. Janet later exported it to MindManager to be able to create our chapter openings. Dropbox was our version control choice for our chapters, and it worked fairly well. Since Lisa works on a Mac and Janet on Windows-based technology, we had occasional technical issues.
We planned two chapters per two-week iteration, but it didn’t work so smoothly as that. Our intent was to do what we had done while writing our first book: draft two chapters per week to give to our volunteer reviewers. However, some chapters proved much harder than others, requiring quite a bit of back and forth to decide what we really wanted to say.
Using Tests to Guide Us
In August 2013, we put out this request to the agile-testing Yahoo group. “… for those who read Agile Testing: A Practical Guide for Testers and Agile Teams, tell us what we missed, or what you want to know more about in the second book. We will use these answers to write our acceptance test(s) “. In the first book, we had a single user write the tests so it was easy to focus. What we found by asking the community, was that there was a wide variety of needs. Some examples are:
- How to write acceptance criteria? Is there any specific format?
- More details on Security Testing and Performance testing
- Pair testing
- Performance testing using SoapUI 4.5.1.
- Exploratory Testing and Test Automation. How do they go together?
- Some practical examples on what tests should look like are essential (and should help in the reviews).
- Design and Implementation of test that span user stories.
- Design strategies. Beyond testing of individual user stories, how do you go about determining what aspects to test
- Determining what should be an acceptance test (test once for User Story delivery) and what should be a regression test (automated or manual) and worth the on-going maintenance.
- How to integrate unit tests into an overall testing strategies – i.e., beyond the two quadrants, how can you leverage the strength of both unit testing and functional testing tools to improve test coverage.
- Evaluating the tests I need to automate
- About looking at the regression tests I have, and working out if my suite is too big
- How to onboard a non-agile tester
- Something to explain value of testing to biz execs?
- As an experienced tester who has never worked in a truly agile environment, I need introductory techniques that I can offer as agile alternatives.
We sorted through all the replies and decided which we had already answered in the first book, and which we felt was appropriate to answer in this new one. You’ll have to read the book to find out the final cut.
The Stories
Like the first book, we’ve included many of our own stories sharing our experiences. However, readers of Agile Testing told us they learned a lot from reading how other people approached tough testing challenges.
We wanted lots of stories from practitioners “in the trenches” for our new book to illustrate specific concepts we wanted to make. Sometimes, we knew exactly who we wanted to ask. For example, Janet listened to a couple of experience reports at conferences that addressed tough challenges, so we elicited stories from them. Other stories came about when our volunteer reviewers wrote a comment indicating they had something interesting to share. Other times we knew that some people had expertise is a specific subject so we asked if they could contribute. Discussions on our book reviewer mailing list sometimes grew into content for the book. We even tweeted to ask: does anyone have a good story on this topic? We got a couple of great sidebars that way.
Geoff Meyer’s story of how teams at Dell approached their automation started as one story, but evolved into a series of sidebars as we realized there was more to tell. Some people that we asked for stories, couldn’t find the time – perhaps a blessing in disguise since the book ended up being almost 500 pages instead of the 250 we’d projected.
