The job of the tester is to find defects. Better testers find more hidden defects.
Developers get the specs wrong and don't work properly. Hence, the QA department to expose their faulty craftsmanship before it hits the customer.
Obvious.
Or - so I though. As do many testers coming from a traditional background.
That's not how it has to be like.
Before we dig into the "What" and "How" of agile testing, let's discuss some aspects of agility first briefly.
In principle, we don't need testers to look for defects
The Agile Manifesto isn't just four sentences about values to fit onto a Powerpoint slide. There are some principles behind the values as well. And those principles, combined, form a foundation for agile craftsmanship.
Trust
Let's take a peek at principle #5: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
This is not about blind trust. It is about a well-informed decision to be able to trust. Good developers don't need to me micromanaged and have someone scrutinously check whether they did their job well. Yes, they, too, are human - but they should be enabled to get things done properly, not checked on. If your developers make mistakes all the time and simply can't get anything right despite of how much support you give them, you just hired the wrong people!
As such, it can not be the responsibility of testers to check on developers!
Excellence
Principle #8 claims: "Continuous attention to technical excellence and good design enhances agility."
Technical excellence implies not repeating mistakes and proactively looking for ways to prevent them. Developers who exercise a high level of diligence will not let any mistake slip that will be easy to catch. Retroactively testing functionality is not going to reveal anything new, because it should be taken for granted.
As such, the classic functional test to report defects should not add any value!
(If it does, that would be a topic for Principle #12, Retrospectives.)
Why we still need agile testers
So, the tester job is not about finding defects - then what is it about?
Let us observe software from a high level.
There are four key activities in software development, regardless of which implementation model we follow:
- Determining why to build it
- Determining what to build
- Determining how to build it
- Delivering the built product to customers
We can turn this into a cycle, because once customers use the software, they will most likely have wishes on what else they want. In case they do not utter this wish, we need to figure out where to go next.
With each of these activities, the agile tester can add value. But let us start with the traditional activity, assuming a feature to build has already been determined.
Testing what to build
With Behaviour Driven Development (BDD) or Acceptance Test Driven Development (ATDD), developers can make sure that the product they build does what customers want or need.
Someone needs to define these behaviours and turn them into executable tests. The creation of proper tests which minimize the risk of failure is a routine activity for professional testers.
The Behavioural test suite provides the framework for developers in which they develop.
Using software like Gherkin, Fitnesse, Geb and Spock - or their likes will ensure that no software with any functional defect will ever be released to the customer ... asserting the tests are properly written!
(As a witty side note: If the tests are not properly written, then a classic "post hoc" test will not fare any better.)
Testing how to build
That's the bread and butter of TDD - in general, developers need tests to ensure that their methods are robust and do what they are supposed to do. Oftentimes, trivial problems like Null Pointers are overlooked and cause serious malfunction. Testers pairing with developers can increase the robustness of unit tests tremendously, ensuring we have a better product that is easier to understand, refactor, debug etc.
Testing the delivery
In the domain of exploratory testing, we try to understand what the product actually does when it's built. From this can come "D'oh" effects as well as ideas for other uses of the product. Testers are usually skilled at systematically and effectively exposing the little side effects nobody thought of.
Testing why to build something
The team might want to look into data on whether users are actually using the product as expected - and adapt their test strategy accordingly. The fundamental question "What do our users actually do with the product?" can not be answered on a code level. Also, it exposes what is actually happening out there in the real world: A-B tests, sampling plans etc. are all test domain - a great value a tester can add to the product!
Summary
Agile testing doesn't have the same purpose as traditional testing. Ignoring testing will result in a failed product, but the test is not about exposing defects or making developers look like dunces. It is about maximizing the value and sustainability of the product build.
