A Coaches Guide to Agile Testing - Growing Agile - A book review

There are a variety of books that testers can choose to read about testing, however there are not many about agile and testing.  I came across the book "A coaches guide to agile testing" by Karen Greaves and Samantha Laing after reading a review of it by Lisa Crispin on her blog.  As someone who works with agile teams I had been looking for a book which could help me get the message across about the testing activities within agile teams.  This book was the book I was looking for.

The book is written as a collection of workshops which you can either use as they are or adapt and change them for your audience.  The format of the workshops follow the same technique devised by Sharon Bowman in her book "Training from the Back of the room" called the 4Cs plan.

• C1 – Connections: To get participants to connect with each other and the trainers, and to connect
• participants to what they might already know about the topic
• C2 – Concepts: Some facts and theoretical concepts about the topic
• C3 – Concrete Practice: An activity or simulation to experience the topic
• C4 – Conclusion: An opportunity for participants to evaluate what they have learned about the topic

Karen and Samantha introduce you to the concepts of the 4Cs and how they are used in each of the workshop sessions.  At this point it is worth mentioning that along with the book there is a trainers kit which contains template and slides for you to use when coaching.

The first few chapters of the book concentrations on introducing the 4Cs method of training along with what materials you may need and some suggestions for how the room should be laid out.  This then goes into an example of an 'ice breaker' for the first session and provides some useful information on setting agreements (rules)

The book really starts to discuss the agile testing subject from chapter 3 onward.  Personally I would like to have more in here, maybe something on retrospectives and test estimation would be really useful.  Hopefully Samantha and Karen will add to this book at a later date.  Chapter 3 introduces a workshop about the 'Agile Testing Mindset'.  I have used the exercises in this chapter to uncover what peoples perception and assumptions are about testing.  It provides some great insights and soundbites that can be used when discussing agile testing with others.  I especially like the following:

Agile is an activity not a phase

The chapter also discusses what is the role of a tester when testing and I found the following system a very useful one when informing people what the role of a tester is.:

"Don't try to break the system, instead help build the best possible system"

Other exercises within this chapter include being a tester rather than a checker and what the difference is.  Is it the testers job to find or prevent bugs?  Overall this chapter provides some useful material in helping dispel the myths and assumptions around what testers do.  For me this one chapter was worth the purchase of the book.

Chapter 4 discusses and provides exercises around the Agile testing quadrants.  It uses exercises to explain why the agile testing quadrants can be a useful tool to help classify different types of testing.  This chapter is a good introduction to the agile testing quadrants and how each quadrants has some elements where testers can provide a contribution.

Chapter 5 introduces automation and looks at some of the pitfalls agile teams fall into when attempting automation. It provides information on the automation pyramid and gets the team thinking about the right place and level automation should be aimed at.

The next chapter looks at the input of testers into scrum meetings and how they can add value.  This chapter is useful for those who feel that testers struggle when teams introduce scrum,  For me this chapter was a little weak in some areas and maybe it was because the title was misleading.  It maybe better to have a title of agile meetings rather than scrum.  This way it can cover the sprint planning, grooming, retrospective and also investigate the concepts of Kanban,

The book finishes with a recap of what has been learnt and asks you to go back and look at other material and resources you have come across during the learning journey that you could look at next.

The book is quite short containing  around 50 + pages but within these pages is a wealth of material and information that anyone involved in agile testing will find useful and informative, The book is not only for coaches it can be used by the reader to provide themselves with an understanding of agile testing.  What I did before I went and used some of the activities described in the book, was to go through each of the exercises myself and learn more about my understanding of agile testing.  This I felt was a valuable aspect of the book it was not just telling you what agile testing is it was providing you with ways to uncover what you already know and what you can learn about agile testing.

I highly recommend this book to anyone who is working in agile teams and want to learn more about agile testing.  As a bonus it provides ready to use teaching material so that you can then go and practice what you have learnt with others.  Included in this bonus material is a ready made slide deck for you to customize and use in your coaching.

The one part of the material that stood out for me was the Agile Testing Manifesto that Karen and Samantha have in their slide deck.  To me this sums up the agile testing approach.

Book Review - Explore it! by Elisabeth Hendrickson

The following is a review of the book Explore it” by Elisabeth Hendrickson

Book link: http://pragprog.com/book/ehxta/explore-it

Elisabeth Hendrickson website

Having followed Elisabeth on twitter @testobsessed and used her test heuristics cheat sheet extensively  I was very excited when I found out that she was releasing a book about exploratory testing and I was fortunate to be able to receive an early ebook version.  The following is my review of the book and of the things I found interesting and that I hope others may find interesting.

The beginning of the book starts with an explanation of testing and exploration in which she mentions the debate on testing and checking  and to me this gives a good grounding of where Elisabeth sets the context for what follows in the book. I especially like the point she makes regarding the need to interact with the system:

Until you test—interact with the software or system, observe its actual behaviour, and compare that to our expectations—everything you think you know about it is mere speculation.

Elisabeth brings up the point of how it is difficult to plan for everything and suggest we plan just enough.  The rest of the first chapter goes into more details as to what are the essentials of exploratory testing and making use of session based test management.

One part of the book I found useful was the practice sessions at the end of each chapter to help you recap what was being explained within the chapter.  If you are the type to normally skip this kind of thing (like myself) on this occasion I would recommend that you give them a go, it really does help to understand what has been written in the chapter.

The next chapter introduces charters to the reader and for me this is the most useful and important chapter of the book.  It helped me to clarify some parts of the exploratory testing approach that I was struggling with and simplified my thoughts.  Elisabeth explains a rather simple template for creating your own charters.

Explore (target)

With (resources)

To discover (information)·

Where:

• Target: Where are you exploring
• Resources: What resources will you bring with you
• Information: What kind of information are you hoping to find?

The rest of the chapter takes this template and using examples provides the reader with a way in which to create charters simply and in some cases quickly.  Along the way she introduces rules that one may wish to follow to avoid turning the charters in to bad charters. She also offers advice on how to get information for new charters (joining requirement/design meetings, playing the headline game) .

What, you do not know what the headline game is?  Well you need to buy the book to find out.

I have started to use this template to create charters for my own testing going so far as to add this template into the mind map test plans.  This to me was worth paying for the book just for this very useful and simple approach to chartering exploratory testing.

The following chapter takes you on the journey of the importance of being able to observe and notice things.  This is a key element of exploratory testing and looking for more things to test is a part of this.  Elisabeth talks about our biases and how easy it is for us to miss things and provides examples of how we may try and avoid some of them.  She talks about the need for testers to question and question, again to be able to dig deep and uncover information that could be useful. This chapter is useful for being able to uncover the hidden information and it suggest ways in which you can get more information about what you want to explore without the need for requirement documents.  This is important since it is better to have the skills that allow you to be able to ask questions

The next few chapters of the book look at ways in which you change or alter the system to undercover more information by means of exploration.  These chapters take the cheat sheet Elisabeth and others produced and add a lot more detail and practical ways to look at the system with a different perspective.  These chapters include titles such as:

• Find Interesting Variations
• Vary Sequence and Interactions
• Explore Entities and their relationships
• Discover states and transitions

A great deal of this is found in part two of the book and this section is something I repeatedly return to for quick inspiration of what I can do to explore the system more.  It gives some great techniques on how to find variants in your system and how to model the way the system is working.  It provides useful ways to help you find the gaps in your system or even in your knowledge.

In the middle of the book there is a chapter called ‘evaluate results’ whereby Elisabeth asks if you know the rules of your system.  If you do not then it would be useful to explore and find them.  She explains the meaning of rules using ‘Never and always’.  If you have a rule that saying it always should do this, then explore. The same for ‘never’ you can explore and uncover where these rules are broken.  This chapter also looks at outside factors such as standards, external and internal consistency.  All these are important when exploring the system and Elisabeth within the book reminds us in this chapter to be aware of such things.

The final section of the book is titled ‘putting into context’

In the chapter ‘Explore the ecosystem’ expands upon the ‘evaluate results’ chapter and now asks you to think about external factors such as the OS, 3^rd party libraries.  Elisabeth gives a great tip in this chapter on modeling what is within your system and what is external and how they interface.  I have found this extremely useful to work out where I can control the system and where this is outside of my control.  Once this has been done, you can then, as Elisabeth suggests as the ‘What if’ questions of these external systems.  If you want to know more about these What if questions, again, I recommend reading the book.

Within here, Elisabeth gives advice on how to explore systems with no user interfaces.  For someone such as myself where there is very few user interfaces, I found a lot of useful information in this chapter.  Especially for making me think of ways in which I could manipulate the interfaces and explore the APIs.

Next Elisabeth talks about how to go about exploring an existing system and gives some great tips on how to do this such as:

• Recon Session
• Sharing observations
• Interviewing to gather questions

This chapter is useful for those who are, or have tested, an existing system and need new ideas to expand their exploration.

Elisabeth then talks about exploring the requirements which is very useful for those who have requirement documentation and within the chapter there are lots of ways offered in which you can explore them.  One great suggestion in using a test review meeting and turning it into a requirements review.  Elisabeth offers many other suggestions on how to create charters from the requirements and use these during your exploratory testing sessions

The final chapter of the book is to think about exploratory testing throughout the whole of the development of the system and how to make exploratory testing a key part of your test strategy.  The key point I got from this chapter was the following:

When your test strategy includes both checking and exploring and the team acts on the information that testing reveals, the result is incredibly high-quality software

Elisabeth gives some real life experiences and stories of how she went about ensuring ‘exploring’ is a key part of testing.  This chapter is very useful for those who want to introduce exploratory testing and are not sure how to go about doing this.

At the end of the book there is a bonus section on interviewing for exploratory testing skills and some details about the previously mentioned cheat sheet.

This is now my testing ‘go to’ handbook and to me it is as important as my other ‘go to’ testing reference book by Glenford Myers – The Art of software testing

I recommend that all testers should have a copy of Explore It as well as anyone who works with testers.  There is information in this book that can help developers with their unit tests by making them ask ‘have I thought of this’?  It can be used by product owners to put together their own charters which they feel would be important to be investigated or explored.

Would I recommend buying this book?  Heck! YES.