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.

Gojko Adzic

Gojko Adzic is a strategic software delivery consultant who works with ambitious teams to improve the quality of their software products and processes. Gojko’s book Specification by Example was awarded the #2 spot on the top 100 agile books for 2012 and won the Jolt Award for the best book of 2012. In 2011, he was voted by peers as the most influential agile testing professional, and his blog won the UK agile award for the best online publication in 2010. To get in touch, write to gojko@neuri.com or visit http://gojko.net

David Evans

David Evans is a consultant, coach and trainer specialising in the field of Agile Quality. David helps organisations with strategic process improvement and coaches teams on effective agile practice. He is regularly in demand as a conference speaker and has had several articles published in international journals. Contact David at [email protected] or follow him on Twitter.

Tom Roden

Tom Roden is a software delivery coach, consultant and quality enthusiast, helping teams and people make the improvements needed to thrive and adapt to the ever changing demands of their environment.

Tom specialises in agile coaching, testing and transformation. He collaborates with teams intent on delivering high quality software with speed and reliability, supporting ongoing improvement through process and practice refinement, influenced by agile and lean principles.

  • Introduction
  • Generating test ideas

    • Define a shared big-picture view of quality

    • Explore capabilities, not features

    • Start with always/never

    • Tap into your emotions

    • Test benefit as well as implementation

    • Quantify even if you cannot measure

    • Organise test ideas using an ACC matrix

    • Use risk checklists for cross-cutting concerns

    • Document trust boundaries

    • Monitor trends in logs and consoles

    • Mob your test sessions

    • Don’t let the pen be the bottleneck

    • Snoop on the competition

  • Designing good checks

    • Focus on key examples

    • Contrast examples with counter-examples

    • Describe what, not how

    • Avoid mathematical formulas

    • Flip equivalence classes between inputs and outputs

    • Clearly separate inputs and outputs

    • Ask ‘what happens instead?’

    • Use Given-When-Then in a strict sequence

    • One test, one topic

    • Treat too many boundaries as a modelling problem

    • Prefer smaller tables

    • Balance three competing forces

    • Write assertions first

    • Split technical and business checks

    • Don’t automate manual tests

  • Improving testability

    • Wrap synchronous database tests in transactions

    • Set up before asynchronous data tests, don’t clean up after

    • Introduce business time

    • Provide atomic external resources

    • Wait for events, not time

    • Split data generators from tests

    • Minimise UI interactions

    • Separate decisions, workflows and technical interactions

    • Use production metrics for expensive tests

  • Managing large test suites

    • Make developers responsible for checking

    • Design tests together with other teams

    • Avoid organising tests by work items

    • Version control tests along with software

    • Create a gallery of examples for automation patterns

    • Decouple coverage from purpose

    • Avoid having strict coverage targets

    • Measure your tests’ half-life

    • Optimise for reading, not writing

    • Name tests for search engine optimisation

    • Explain the purpose of a test in the introduction

    • Split just-in-case tests from key examples

    • Let the chaos monkey out periodically

  • The End

    • Authors

    • Bibliography and resources

    • Legal Stuff