Developing Book Review: Explore It!

Pragmatic Publishing has been getting a lot of my book dollars the past couple of years. There's a reason for this. They seem to be the ones best situated for my particular technology and challenges list at this point in time, plus I greatly appreciate their model of how they make books available. With many publishers, you need to be part of a secret club or know the author to get your hands on a developing book. Pragmatic Publishing has baked it into their writing model. Most of their books are made available as beta titles early on, and those who wish to get involved with the reading, implementing and reviewing of titles can do so. They realize that the books are half baked, sections are still to be written, aspects of layout and graphics are not completed, and grammar may still be a bit loose.

As I've said with other developing reviews, fair enough. Again, I will say "If we extract all of that, is there a value in getting this book now and being one of the people who will be willing to work with all of those for the time vagaries to get to what will ultimately be a good product?" That's what I hope this review will represent. Also, this review will be converted to a full review after the books ship. Oh and for those who want to say at this point "tl; dr", here's my answer.

YES!!!

Exploratory testing has been getting press lately. Deservedly so, I should say. Still, outside of blog posts and direct interaction with those who have represented the movement of exploratory testing, there isn't a good one stop for explaining what exploratory testing is in a meaningful way. Practitioners have to scratch around and try out a number of different sources and models and deal with a lot of "it depends". Getting all of the details in one place, and with a smooth narrative that can help make sense of the process is a good thing. Giving you ways to practice it and actually get some hands on understanding is even better. Hearing it in a voice and a narrative that flows smoothly, is not overly technical, and allows users to connect the dots effectively would also be a huge plus. Are we there yet? With the beta 1.0 release of "Explore It!" by Elisabeth Hendrickson, I'll dare say we are are a lot closer than we have been to date.

Software development is hard. It takes a certain amount of discipline, structured thinking and a variety of language skills to put a system together. What makes it even more challenging is that it's not like building a house on rock. It's not even like building a house on sand. It's really more like building a boat on an ocean. So much of software development requires the interaction of so many moving parts that, really, nothing is stable or static. Not really. It's in this world that we as testers are often asked to do our work. If we have illusions that everything is going to be neat and orderly and tidy, like a house built upon a stone foundation, we are liable to miss a great deal of what happens. This is where having an exploratory approach and mindset is critical. We understand that we need to explore, but how do we develop that mindset? It's with this aspect that much of the initial chapters are focused.

Part One deals with establishing and developing the exploratory foundations, so this is where exploration is explained and put into terms that a variety of people, not just testers, can understand. The key attributes of exploration (execution, learning and steering) are put forward, as well as disavowing the notion that testing is only a process of the test team (it's not, everyone tests, whether they are aware of the fact or not). Creating testing charters and understanding how to make them neither too specific nor too vague is important. There is also an emphasis on time boxing and Session Based Test Management, so as to help keep things in focus and make the exploration meaningful and on target. I like the approach Elisabeth uses in this early section to make a simple and easy top understand exploration template. Much the way that Agile development makes a story ("As a [stakeholder]., I want [functionality] So that I can [achieve result]"), consider exploration to be "Explore [target] with [resources] to discover [information]". That alone is a great takeaway from this section!

Observation is a big part of exploration, and Elisabeth puts a good emphasis on learning how to see what others don't. Inattentional blindness is addressed, and yes, we get a visit from "The Moonwalking Bear" (and if you have no idea what that is, follow the youtube link in the footnotes). The key point is that we need to make an effort to make the invisible more visible, and Elisabeth explains a number of techniques and methods to do exactly that.

Part Two digs deeper, and gives us the opportune ity to work variations and different approaches to our explorations. Elisabeth recommends that we take some time to recognize our habits and how those habits may be blocking our vision to see the unseen. From there, make a conscious effort to avoid doing things the way you normally do. Personas are introduced, and fleshed out considerably. For anyone who has heard this term, Elisabeth give this a good treatment, and also puts it into perspectives you may not have considered. States and transitions are an avenue for exploration that gets a good treatment here, and how to take advantage of them to vary your testing approach. Modeling the system and the way we interact with it are also covered. Look for places where transitions occur, and see if you can influence the way those transition occur.

Part Three puts the different approaches into unique contexts and shows that the skills are applicable in a broad range of circumstances. Exploration is often considered a front end approach, but it can be used in many places; unit tests, acceptance test driven development, behavior driven development, testing of API's, and anywhere that a user might interact with an application, even if the end user isn't actually a human. Also, while exploratory testing is encouraged for systems under development, it's just as powerful a tool for legacy and currently marketed applications, too. Elisabeth describes the value of doing reconnaissance on applications. Discover the applications capabilities and its limitations. From this, you can start asking interesting questions of the application, and discover areas where it should be doing something, or should not be doing something, and when to tell the difference.

Part of what makes this book fun, at least for me, is the fact that I have worked with Elisabeth in the past. I know her, I know her sense of humor, her manner of speaking, and the way that she gets points across. Thus, it's very easy to read this book in her voice. Even if you are not familiar with Elisabeth and how she talks and describes things, you will still be able to follow along with her as she makes the examples relevant, and sometimes amusingly so. While calculating to the air velocity of a swallow (European or African), the fact that she's willing to include those whimsical details makes it easy to get into the spirit of the book and go with the flow of the narative. For technical books, that's quite an achievement.

At the present time, the ToC lists 13 chapters, with three of them still to be written (Exploring Entities and their Relationships, Exploring Requirements, and Integrating Exploring Throughout). The appendix section includes a section on ways to interview for good exploratory testers and the now famous (for many) Test Heuristics Cheat Sheet. If you want to see progress on the book, you can certainly check the book Progress page to see if the area you are interested in is ready or well along in the process. If you want to wait for the whole book to be finished, that's understandable. If, however, you'd like to get in and try these techniques for yourself, and are willing to deal with some loose ends for a few months as they get developed, not to mention help Elisabeth deliver an even more solid book by offering suggestions in the book's Errata section, then why wait? Get the book, go forth and see what you will find. Even in it's Beta 1.0 state, my guess is, quite a bit.