Adzic Gojko - Fifty Quick Ideas to Improve Your Tests

This book will help you test your software better, easier and faster. Its acollection of ideas weve used with various clients in many different contexts,from small web start-ups to the worlds largest banks, to help team memberscollaborate better on defining and executing tests. Many of these ideas alsohelp teams engage their business stakeholders better in defining keyexpectations and improve the quality of their software products.

This book is primarily aimed at cross-functional teams working in an iterativedelivery environment, planning with user stories and testing frequently changingsoftware under the tough time pressure of short iterations. The intended audienceare people with a solid understanding of the basics of software testing, whoare looking for ideas on how to improve their tests and testing-relatedactivities. 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 toorganise your work better so that it fits into short iterative cycles orflow-based processes, and how to help your team define and organise testing activitiesbetter.

This book doesnt cover the basics of software testing, nor does it try topresent a complete taxonomy of all the activities a team needs to perform toinspect and improve the quality of their software. Its a book about improvingtesting activities, not setting up the basics. We assume that readers knowabout exploratory testing and test automation, the difference betweenunit tests and integration tests, and the key approaches to defining tests. Inshort, this isnt the first book about testing you should read. There are plentyof good basic books out there, so read them first and then come back. Pleasedont hate us because we skipped the basics, but there is only so much space inthe book and other people cover the basics well enough already.

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

• Generating testing ideas: This part deals with activities for teams toengage stakeholders in more productive discussions around needs andexpectations. The ideas in this part are equally applicable to manual andautomated testing, and should be particularly useful to people looking forinspiration on improving exploratory testing activities.
• Designing good checks: This part deals with defining gooddeterministic checks that can be easily automated. The ideas in this partwill help you select better examples for your tests and specifications, and inparticular help with the given-when-then style of acceptance criteria.
• Improving testability: This part contains useful architectural and modellingtricks for making software easier to observe and control, improve the reliability oftesting systems and make test automation code easier to manage. It should beparticularly useful for teams that suffer from unreliable automated tests due tocomplex architectural constraints.
• Managing large test suites: This part provides tips and suggestions ondealing with the long-term consequences of iterative delivery. In it, youll findideas on how to organise large groups of test cases so that they are easy tomanage and update, and how to improve the structure of individual tests to simplifymaintenance and reduce the costs associated with keeping your tests in sync with thefrequently changing underlying software.

Each part contains ideas that weve used with teams over the last five or sixyears to help them manage testing activities better and get more value out ofiterative delivery. Software delivery is incredibly contextual, so somestories will apply to your situation, and some wont. Treat all the proposalsin this book as experiments.

There is only so much space in a book, and some of the ideas described deserveentire books of their own. We provide plenty of references for further studyand pointers for more detailed research in the .

If youd like to get more information on any of the ideas, get additional tipsor discuss your experiences with peers, join the discussion group50quickideas.

This book is part of a series of books on improving various aspects of iterativedelivery. If you like it, check out the other books from the series at50quickideas.com.

Generating test ideas

Define a shared big-picture view of quality

Quality is a notoriously difficult concept to pin down. Users mostly look atexternally observable attributes, such as speed and usability. Businessstakeholders look at financial performance. Developers mostly care aboutinternal code structure. Testers sit somewhere between and try to connect allthe dots. So many different levels of quality, and so many differentperspectives, often lead to disagreements. A user might consider something abug, but developers might classify it as an improvement request. Something oneperson considers critical might not even register on the scale of importancefor someone from a different group. That is why a seemingly critical defect canbe left in a software product for months, sitting in a bug tracking tool oftenserving just to prevent people sending more notifications about the same issue.This is also why software can be released to customers even when people on thedelivery team know it contains a lot of technical debt. Situations such asthis create a divisive atmosphere, us against them, testers who feel that theyare not listened to and developers who feel that testers are nit-picking aboutunimportant issues. Business stakeholders start resenting delivery teams forgold-plating the product when time is pressing, and delivery teams startresenting business stakeholders for insisting on an unsustainable pace ofdelivery. These disagreements are particularly problematic for delivery teamsthat are not in direct contact with customers.

Its easy to blame another group for being ignorant and causing thismisunderstanding, but the real issue is that people often have a simplisticview of quality, and very rarely see the big picture. A good solution for thismisunderstanding is to create a multi-layered, multi-faced view of quality thatdifferent groups can agree on.