An article I recently wrote on Agile Test Data Management prompted some responses on a more fundamental level. What is Agile testing? There are plenty of methods, frameworks, and comprehensive guides available that will provide you with a template for Agile testing. Unfortunately, most of these are either too prescriptive or thinly-veiled waterfall anyway.
This isn’t one of those, this will be a quick dive into the principles that might help you evolve your own practice.
What do we test?
Going back to basics, what’s the intent of testing in the first place? Some might say quality, reputation, or resilience. For me, it’s about improving the customer’s life. A high-quality, resilient application that does what it sets out to do is something that helps a customer meet a need or solve a problem.
So how can testing, as a function, contribute to improving a customer’s life?
Agile Testing Principles
Eliminate dependencies
If you haven’t already, I’d suggest checking out my article on dependencies or Business outcome alignment. We’re seeing it more and more now, but it’s crucial that testing as an isolated function or team disappears. Introducing an unnecessary dependency simply to maximise utilization or make line management easy is a false economy.
In an ideal world, each outcome team will have all necessary development expertise to execute on a strategic value stream, including test. To completely eliminate dependencies and reduce fragility, this capability should be simply part of the engineering repertoire that everyone shares. If you’re not there yet, then having a separate QA in the same team is the next best thing. These should be full-time, first-class engineers with shared responsibility for building and testing customer value.
Key Techniques
Maximise early feedback
We know feedback is critical, and we also know that getting feedback as early as possible reduces cost and improves quality. There is no reason that this shouldn’t apply to Agile testing.
We can improve our feedback cycles by adopting any number of useful practices.
Testing is part of work definition
When making a piece of work ready, it is vital that we include testing as part of its definition. If we have testing, as a role, represented in the work refinement process, we can often see improved results. Everyone will have a better understanding of the effort required to complete it which will also result in a more accurate estimation. It also defines the work required to test the output, sharing responsibility and breaking down fragility.
Pair programming
Pair programming is relativity commonplace now, but what about testing? If you are in the enviable position where your engineers are both developers and testers, then one can test and another can develop as you go. Even if not, consider applying the practice of Acceptance Test-Driven Development. A practice like this eliminates all feedback latency from test to development. Remember when testing used to come at the end of all development in a release or project?
Test automation
Not only will appropriate test automation accelerate your current development, it will also guard against future issues so effectively that you will reap feedback dividends for years to come. Test automation gives you immediate feedback as to whether an action you take has broken something else. Broad and high-quality test coverage is simply a necessity in any development practice nowadays.
KEY TECHNIQUES
- Test-Driven Development (TDD)
- Acceptance Test-Driven Development (ATTD)
- Behaviour Driven Development (BDD)
- Pair Programming
- 3 Amigos
- Agile Testing Quadrants
- Shift Left
See it from the customer perspective
The customer of testing is not development, it is the end-user.
As soon as we start seeing things from a customer perspective, the focus of our effort changes. We want to include the customer as early as possible and enable them to collaborate with us. Bringing in a customer to your refinement sessions can help include them in the process early on. On the topic of meetings, make sure they’re included in your demonstrations. The demo or review is a key point for getting feedback and collaborating on the requirements.
Taking a customer lens can also help prevent unnecessary work. When we understand that the goal is customer enablement and not technical perfection then we cut back on waste. Traditionally the testing role was seen as the guardian of perfection and would prevent anything that wasn’t technically perfect from being delivered.
Much like we try to reduce unnecessary features through the adoption of Lean, we should aim for just enough testing. This might manifest itself as accepting less than 100% test coverage or swapping burdensome acceptance tests for multiple unit tests.
Be sure to recognise that I am not advocating for a reduction in quality but am for making sure we understand diminishing returns. There is an opportunity cost associated with all effort. We gain no benefit from testing more rigorously than is required.
Key Techniques
Computer vs. Human
Quite simply, you need to know what a computer should be doing and what a human should be doing. Computers are great at repetitive or variable but well-defined activities. Having a human tester enter ‘A’, ‘1’, ‘0’, ‘-1’, ‘?’, etc into a text field to make sure it doesn’t crash is ridiculous. Similarly, until we properly nail strong AI, a machine is never going to be as good as a human at exploring a piece of functionality in the way a user would.
Ask yourself what entity is best positioned to undertake which type of testing effort. Just because we have complete test coverage doesn’t mean we don’t need exploratory testing.
Key Techniques
Shift Left
As a movement, shift-left is pretty common so I won’t go into detail. Generally speaking, we aim to ensure that quality is treated as a well-defined and first-class aspect to a piece of value. This is in contrast to the traditional approach of bolting quality on later in the process as a result of functional division.
Key Techniques
Agile testing wrap up
Although I’ve linked plenty of prescriptive material here, I think it effectively boils down to a small number of principles.
Testing is there to enhance the user experience, not to drive technical perfection. We can achieve this by including our customer early and often, seeing our efforts through their eyes. By doing so, our focus moves to appropriate quality and the early delivery of value. The challenge comes in how we achieve this, but one of the first steps is to optimise our design for value flow.