A guide through the essentials of agile software testing that everyone can understand

You don’t need a technical background at all to understand aspects of agile testing. Do you come across topics like software testing in your day to day life, maybe working with developers or testers but don’t really know what it is about? This article will guide you through the values and principles of agile testing. No matter what your role is if a team struggles with test-related issues you can take a step back and use these guidelines to find improvement opportunities. This is the first article in the series “Agile Software Testing — insights for non-technical people, like me”.

Why agile testing and what is it about?

In an environment of high complexity and thus uncertainty, in which the development of innovative products and business models tends to happen (we don’t know exactly what solutions are adding value for our customers in the future and therefore also don’t know how to create them), agile approaches are a good way to reduce the risk of heading into the wrong direction for too long. By taking small, experimental, and iterative steps, we can learn continuously and adapt through short feedback loops. This is why I wanted to understand how testing works for agile teams and I looked for help in the book “Agile Testing Condensed: A Brief Introduction” by Janet Gregory and Lisa Crispin.

Janet and Lisa define Agile Testing as follows:

Collaborative testing practices that occur continuously, from inception
to delivery and beyond, supporting frequent delivery of value for our
customers. Testing activities focus on building quality into the product,
using fast feedback loops to validate our understanding. The practices
strengthen and support the idea of whole-team responsibility for
quality.

There are a few principles I found helpful to keep in mind, before looking into the testing approaches.

The very first thing, the two authors point out, is that the heart of agile testing is the involvement of the whole team to test and build in quality into the product. That means testing doesn’t happen in the end, solely being done by a tester, but is part of the whole product life cycle to prevent defects upfront. And the whole team is responsible for it.

The heart of agile testing involves the whole team in testing and building quality into our product. — Janet Gregory and Lisa Crispin

The idea of testing as a fixed element throughout the product life cycle has been nicely illustrated by Dan Ashby in his blog post about testing in DevOps (Don’t worry, we’ll talk about DevOps a bit later in the article series).

Continuous testing in the DevOps loop by Dan Ashby

Especially when a team starts to work together for the first time, it makes sense to have a closer look at the Agile Testing principles as well as the Agile Testing Manifesto. Both can act as a guideline throughout the product development and after. Here I will show you the principles, but the Testing Manifesto is definitely worth a look.

10 principles of Agile Testing:

1. Provide continuous feedback.
2. Deliver value to the customer.
3. Enable face-to-face communication.
4. Have courage.
5. Keep it simple.
6. Practice continuous improvement.
7. Respond to change.
8. Self-organize.
9. Focus on people.
10. Enjoy!

Those principles might look simple at first, but the key is to live them in day-to-day work life. Take “Have courage” for example. If it is not possible to openly address potential weaknesses in your product or to have an open conversation about the gaps between customer needs and your product, how can your tests give you valuable feedback about it? And sub-sequentially, how can you deliver a high-quality product that customers are willing to use and pay for? Have a critical look at those principles in the team and outside and think about ways to live them as honest and pragmatic as possible.

The whole-team approach

As the name suggests, the whole-team approach means that testing tasks become a part of the regular development and are being planned and done by the whole team, just like any other task. Therefore teams have to include testing into their workload.

To be able to do so the team needs to broaden their skill set. The goal is to have a T-shaped knowledge structure in the team, which means that each team member adds basic skills to their core domain. This can include:

• Test Driven Development (TDD) (part of a later article in the series)
• Exploratory testing (part of a later article in the series)
• Business domain knowledge to make sure that the features deliver value to the customer

This knowledge can be achieved through collaboration (such as pairing, where two people are sitting at one computer, doing one task together) with a tester (who ideally is part of the team) or other team members or talks with (business) experts and customers.

Each team member can help to figure out, what is most valuable for the customer. The goal is to deliver just enough in small increments to learn how the customer uses that feature. Like that, the team can focus their testing on the features that are most valuable to the customer.

To implement your testing strategy (which includes which tests you will run, when and for which level of detail) a valuable Definition of Done (DoD), which is defined by the team is vital. Valuable in terms of testing means that it should be explicit about your testing strategy so that every team member can use it as a checklist whenever they work on a backlog item. It also should describe how they want to handle defects. An example of a non-valuable DoD would be “Test every item.”

Responsibility for defects

When the whole team focuses on avoiding defects, the overall quality of produced code rises, and the effort for bug fixing (meaning to fix unexpected behavior in your product) goes down drastically.

Zero defect tolerance […] means zero known defects escape an iteration or story completion. — Janet Gregory and Lisa Crispin

The handling should include:

• Finding a defect,
• writing one or more executable test(s),
• correcting the code until test(s) pass(es) and
• performing exploratory tests if needed.

Taylor the testing to your specific needs

So what should you consider upfront? To find the right set of test approaches, it’s important to keep the Big Picture in mind. This means, not to follow a standardized way but to consider the context in which a product is being developed. This includes:

• Team context: Are there dependencies on other teams or external knowledge? The team has the responsibility to detect and minimize those dependencies to be able to run the testing activities as smoothly and independent as possible. This can happen by aligning with other teams or getting input from specialists.
• Product context: The quality level, that customers expect from a product depends on its specific requirements. (e.g. internal used content management vs. medical device software). Ask yourself (and others): How is the product being delivered? What are associated risks with the delivery mechanism (E.g. self-hosted web application with high control, or product that works on many devices such as phones → how can updates be done?) Does the team have a good understanding of how the products are used? Do all members have domain knowledge?
• Levels of detail: Especially with big releases with several features, keeping the big picture in mind while working on stories and tasks is very important. This also applies to the testing. Only testing a certain task or story without keeping the purpose of the underlying feature and release in mind is problematic. Therefore testing across multiple levels requires extra planning. Make sure that there is constant communication between developers, testers, and business representatives to create that understanding.

If you want to get more details about these essentials, have a look into the book “Agile Testing Condensed: A Brief Introduction”.

So how can your team find out, which tests are necessary for your product and when? And when should the team automate tests and when not? In the next articles, I will guide you step by step through these questions.

References

• Key source for the article series: Agile Testing Condensed: A Brief Introduction by Janet Gregory and Lisa Crispin
• Testing as a fixed element throughout the product life cycle by Dan Ashby
• The Agile Testing Manifesto by Karen Greaves and Samantha Laing
• Definition of features, user stories, and tasks

Articles of the series

Agile Testing Strategy — Graphic by Alexandra Oliveira

• Article 1: A guide through the essentials of agile software testing that everyone can understand
• Article 2: How to find the right testing strategy with an easy framework
• Article 3: Your Superpower for Successful Testing: Creating a Shared Understanding
• Article 4: Everything you need to know about Unit and Integration Tests
• Article 5: A non-technical guide about bringing code to your customer
• Article 6: How to find out if your product really creates value

About the article series “Agile Software Testing — insights for non-technical people, like me”

During these isolated times I took the chance to learn more about software testing. This can be quite challenging without a technical background. Therefore I read the book “Agile Testing Condensed: A Brief Introduction” by Janet Gregory and Lisa Crispin and worked through the content they describe in the book. To make it easier for you to quickly get the most important insights, I summarized my learnings from the book and some further sources and want to share them here with you in a series of short read articles. They are structured along the product development phases and you can either read them piece by piece to get a holistic overview or pick the topics, you are interested in most. I believe this will help you, as it helped me to understand a bit more about the world of testing, without having a technical background.