Fifty Quick Ideas to Improve your Tests is a follow-up book to Fifty Quick Ideas to Improve your User Stories, focusing on how to get the most out of your investment in testing activities in an agile process.

This book will help you test your software better, easier and faster. It's a collection of ideas we've used with various clients in many different contexts, from small web start-ups to the world's largest banks, to help team members collaborate better on defining and executing tests. Many of these ideas also help teams engage their business stakeholders better in defining key expectations and improve the quality of their software products.

Who is this book for?

This book is primarily aimed at cross-functional teams working in an iterative delivery environment, planning with user stories and testing frequently changing software under the tough time pressure of short iterations. The intended audience are people with a solid understanding of the basics of software testing, who are looking for ideas on how to improve their tests and testing-related activities. The ideas in this book will be useful to many different roles, including testers, analysts and developers. You will find plenty of tips on how to organise your work better so that it fits into short iterative cycles or flow-based processes, and how to help your team define and organise testing activities better.

Who is this book not for?

This book doesn't cover the basics of software testing, nor does it try to present a complete taxonomy of all the activities a team needs to perform to inspect and improve the quality of their software. It's a book about improving testing activities, not setting up the basics. We assume that readers know about exploratory testing and test automation, the difference between unit tests and integration tests, and the key approaches to defining tests. In short, this isn't the first book about testing you should read. There are plenty of good basic books out there, so read them first and then come back. Please don't hate us because we skipped the basics, but there is only so much space in the book and other people cover the basics well enough already.

What's inside?

Unsurprisingly, the book contains exactly fifty ideas. They are grouped into four major parts: 

• Generating testing ideas: This part deals with activities for teams to engage stakeholders in more productive discussions around needs and expectations. The ideas in this part are equally applicable to manual and automated testing, and should be particularly useful to people looking for inspiration on improving exploratory testing activities.
• Designing good checks: This part deals with defining good deterministic checks that can be easily automated. The ideas in this part will help you select better examples for your tests and specifications, and in particular help with the given-when-then style of acceptance criteria. 
• Improving testability: This part contains useful architectural and modelling tricks for making software easier to observe and control, improve the reliability of testing systems and make test automation code easier to manage. It should be particularly useful for teams that suffer from unreliable automated tests due to complex architectural constraints.
• Managing large test suites: This part provides tips and suggestions on dealing with the long-term consequences of iterative delivery. In it, you'll find ideas on how to organise large groups of test cases so that they are easy to manage and update, and how to improve the structure of individual tests to simplify maintenance and reduce the costs associated with keeping your tests in sync with the frequently changing underlying software.

Each part contains ideas that we've used with teams over the last five or six years to help them manage testing activities better and get more value out of iterative delivery.  Software delivery is incredibly contextual, so some stories will apply to your situation, and some won't. Treat all the proposals in this book as experiments.

This book will help you write better stories, spot and fix common issues, split stories so that they are smaller but still valuable, and deal with difficult stuff like crosscutting concerns, long-term effects and non-functional requirements. Above all, this book will help you achieve the promise of agile and iterative delivery: to ensure that the right stuff gets delivered through productive discussions between delivery team members and business stakeholders.

Who is this book for?

This is a book for anyone working in an iterative delivery environment, doing planning with user stories. The ideas in this book are useful both to people relatively new to user stories and those who have been working with them for years. People who work in software delivery, regardless of their role, will find plenty of tips for engaging stakeholders better and structuring iterative plans more effectively. Business stakeholders working with software teams will discover how to provide better information to their delivery groups, how to set better priorities and how to outrun the competition by achieving more with less software.

Who is this book not for?

This book doesn't cover the basics of stories. We assume that readers know what Card-Conversation-Confirmation means, what INVEST is and how to apply the basic strategies for splitting user stories. This isn't the first book you should read about user stories, if those terms are unfamiliar. There are plenty of good basic books out there, so read them first and then come back.  Please don't hate us because we skipped the basics, but there is only so much space in the book and other people cover the basics already well enough.

What's inside?

Unsurprisingly, the book contains exactly fifty ideas. They are grouped into five major parts:

• Creating stories: This part deals with capturing information about stories before they get accepted into the delivery pipeline. You'll find ideas about what kind of information to note down on story cards and how to quickly spot potential problems.
• Planning with stories: This part contains ideas that will help you manage the big-picture view, set milestones and organise long-term work.
• Discussing stories: User stories are all about effective conversations, and this part contains ideas to improve discussions between delivery teams and business stakeholders. You'll find out how to discover hidden assumptions and how to facilitate effective conversations to ensure shared understanding.
• Splitting stories: The ideas in this part will help you deal with large and difficult stories, offering several strategies for dividing them into smaller chunks that will help you learn fast and deliver value quickly.
• Managing iterative delivery: This part contains ideas that will help you work with user stories in the short and mid term, manage capacity, prioritise and reduce scope to achieve the most with the least software.

Each part contains ideas that we've used with teams over the last five or six years to help them manage user stories better and get more value out of iterative delivery. These ideas come from many different contexts, from large investment banks working on internal IT initiatives to small web start-ups shipping consumer software. 

It is the mark of a good action that it appears inevitable in retrospect

Robert Louis Stevenson

Retrospectives have been the pulse of continuous improvement for teams since the boom in popularity of agile methods. For organisations who only inspected a project after it had delivered (or not), moving to a bi-weekly or monthly improvement cycle was a revolutionary shift, but why stop there? Unfortunately many teams repeat the same process over and over, so their retrospectives become flat, unrewarding and get discarded for not adding value.  This can have slow down improvement and demotivate team members. 

Learn how to improve retrospectives and avoid stagnation, with fifty ideas designed to help you enhance and energise your continuous improvement effort. This book will help you get better outcomes from retrospectives and from any continuous improvement initiative. It will help you consider how best to prepare for retrospectives, generate innovative insights, achieve valuable outcomes, improve facilitation techniques, keep things fresh and maybe even how to have a bit of fun whilst doing it.  

Who is this book for?

This book is for anyone who undertakes continuous improvement of any sort, especially those looking to get better outcomes from retrospectives, either as a participant, facilitator, coach or manager of teams. We include ideas for people with varying levels of experience. So, whether you are just getting started with Scrum and retrospectives, or a veteran of continuous improvement looking to fine-tune or get new ideas, or if your retrospectives have become a bit stale and need re-invigorating, there are ideas in here to support you.  

Many of the ideas and concepts are universally applicable and will be of use to anyone trying to make improvements in any industry or walk of life. They are not limited to the confines of software development, where we work.

Who is this book not for?

This book is not for someone without any knowledge of retrospectives. We are making an assumption that our readers will probably understand what a retrospective is, as well as how to go about using them. If you have little or no experience participating in or facilitating retrospectives please read another book first. There are plenty of good books and materials out there that introduce the basic processes and formats.