The book "50 quick ideas to improve your tests" is written by Gojko Adzic, David Evans, and Tom Roden.

The book has four big chapters, and each chapter consists of testing ideas:

• Generating testing ideas - Activities for teams to engage stakeholders in more productive discussions around needs and expectations
• Designing good checks - Defining good deterministic checks that can be easily automated
• Improving testability - Contains useful architectural and modeling tricks for making software easier to observe and control, improve the reliability of testing systems and make test automation code easier to manage
• Managing large test suites - Provides tips and suggestions on dealing with the long-term consequences of iterative delivery

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.

In this chapter, you can find six ideas that are extracted from the book.

Idea 1 - EXPLORE CAPABILITIES, NOT FEATURES

• A good way to look for unexpected risks is not to explore features, but related capabilities instead
• Don't check just acceptance criteria in the user story -> do exploratory testing around the feature
• A good perspective for investigations that balances wider scope with focus is around user capabilities
• Features provide capabilities to users to do something useful
• Focusing exploratory testing on capabilities instead of features leads to deeper insights

EXAMPLE

• Implementation of contact form which the user can fill in, and the form is sent to the support

1. What in case of bad or no internet connection?

   The solution was that they had an alternative contact channel for when the network was not accessible. They displayed the alternative support contact phone number on the form, and also, the phone number was visible in the error message.

2. What if the user didn't write enough information related to the problem they have?

   The solution was to pull out the last 1000 events in the user interface and automatically send them the support request. Support could then replay and investigate what exactly happened and help the customer.

Idea 2 - MOB YOUR TEST SESSIONS

• We tend to lean towards the same techniques and types of test, covering one class of risks well, but not others
• Involve a group of people, maybe your whole team or a wider group including members from other teams (devs, PMs) or other stakeholders
• An interesting effect they've found involving people outside the immediate team is that their lack of prior knowledge allows for some better and more radical test design, uncovering information and defects that would never have been found by a smaller team
• Mobbed testing sessions are also a good way of opening up more cross-team and departmental collaboration and improving relationships

HOW TO MAKE IT WORK?

• Start with the scope and purpose of the session (is it for a specific feature, user story, defect, or area of weakness in the system, or is it product wide?)
• Decide on the appropriate level of preparation for the session (details about the requirement, acceptance criteria, the design, the test environment, etc.)
• Decide who to invite
• Start by explaining the requirement, product, feature, problem statement, design and any other useful context to get everyone involved up to speed
• Collect all the ideas - then group them, refine and risk - prioritize them

Idea 3 - DON'T LET THE PEN BE THE BOTTLENECK

• When there is a single pen being wielded by one person, it can be very difficult for a group to get into the flow of collaboration, idea generation, and constructive criticism
• If this happens, give everyone a pen so they can write on the whiteboard - encourage them all to stand within writing range of the board
• There are also tools online for remote collaboration (miro.com, stormboard.com (free for up to 5 people), ideaboardz.com, etc.)

HOW TO MAKE IT WORK?

• Start with a low-tech medium - whiteboard, flipchart, or online tool
• For larger groups, split the team - limit each group to 3, 4 people (ideally, a mix of roles)
• Each group can work on the same problem independently
• Give each person a different colored pen
• Start with writing and discuss the first few cases together but also let people add new examples simultaneously -> encourage multitasking
• After all ideas are written on the board, pause the group and check for duplications and conflicts
• Each person silently reviews its work and considers what needs correcting or improving
• Discuss cases after everyone has had time to think for themselves

Idea 4 - CONTRAST EXAMPLES WITH COUNTER - EXAMPLES

• Counter-examples are cases that show when the feature does not apply, or when the new behavior is not invoked
• Good counter-examples are those where the inputs are as close as possible to the positive/expected cases, but lead to different outputs

EXAMPLE

• Testing free delivery feature -> user needs to be eligible for the free delivery

HOW TO MAKE IT WORK?

• Start with the simplest example you can think of that shows a scenario where the feature or business rule takes effect
• Underline the parts of the example that are most relevant to the feature or rule
• Using the values you have to underline, create a table with column names for each input and each output
• Put the data values from the example into the table

• You are now prepared for testing the feature once it's implemented

Idea 5 - MINIMISE UI INTERACTIONS

• A test executed through a UI typically brings the entire application stack together

  Example:

  • Problem: E-mail systems often prevent users from sending too many messages in a short time -> we are limited to check if the user can have thousands of e-mails in his inbox
  • Solution: We can pump thousands of messages into a database directly and validate inbox performance with large lists

• The UI is often the slowest and the most brittle part of a system, and small changes in it break test easily -> for example, changing a button in the UI into link will break all tests that depend on that button

EXAMPLE: GIVEN A VALID CUSTOMER ACCOUNT WITH 100 USD

All tests started with:

• Launching the administrative application,
• Registering a user,
• Approving the account,
• Registering a payment card,
• Approving the payment card,
• Transferring money into the account

To create a valid clean customer account for the rest of the test -> This took about 90 seconds for each test.

All of it was replaced with executing the steps directly using a database -> This took milliseconds without increasing any risks.

If not possible to directly write something in the database, instead of launching a browser -> simulate HTTP calls. This will still be faster and more reliable than full UI execution.

Idea 6 - EXPLAIN THE PURPOSE OF A TEST IN THE INTRODUCTION

• Always explain the purpose of a test in the introduction or description
• Good context is crucial to avoid information bottlenecks in the future
• Contextual information explaining the purpose of a test has great value for all members of a team
• Pay attention to how you're explaining the test -> consider anything you said should go into the context
• Alternative approach -> show the test to someone and let the reader ask questions - the answers are a good starting point for context