Fundamentally, the basics of any testing approach still apply in the Agile world, however the focus of testing can be quite different.
There are 7 principles of quality in Agile testing, and it is important to recognise why we are testing in the first place, and that is to build the best quality system we can, that does what the client requires, at a cost that everyone agrees we can afford. Cost being money, business change, risk etc….
Too often, the focus of testing is to validate what has been produced and that alone, when in actuality it should be more about the following things:
Building quality in
You cannot test quality in at the end, which is the mistake a lot of people make. Expend the vast majority of your effort building quality in at the start instead. Get testers involved in the business decisions at the start of the project, have them write user stories and acceptance criteria, have them work directly with the test teams at the point of creation. Once past that point, testing should primarily be a verification of what we already know and understand to be true, there should be no surprises in the end test phases.
Everyone is responsible for quality
The quality of a system is defined by the people who create it. If there is a problem in the quality of the system being produced, then it should be evident to everyone involved, and every person on the project should be taking action to increase quality and fix issues. Basically, quality isn’t a testing issue.
Agile is reliant on fast feedback loops, so that we can actually be agile and change when we need to change. Testing should be about giving that fast feedback, at the time when it is useful. Pairing with developers, TDD, Continuous Integration, regular drops into QA environments, testing taking place during development etc…
What it cannot be is the usual “over the wall” approach of development sign-off, testing phase, defect tracking systems, etc… ad nauseum. They have their place and we will still use them in a lightweight fashion and when necessary, but those systems and processes are not the primary focus of the test team.
Test are an asset of the programme
By this we mean that testing is built with re-use in mind. It takes a lot of effort to do testing correctly, we don’t want it to be a throwaway exercise that has to starts from scratch each time there is a new release, or a new project. Automated tests need to be written with the same care and rigour as production code.
Faster delivery into production
While testing is necessary and valuable to the programme as a whole, once code has been written, then the time it takes for that code to go live is essentially wasted time. Testing should be a tool that is used to get the fastest possible confirmation that it is as expected, or that it isn’t and needs to be reworked. It doesn’t always need to be exhaustive at every level, it needs to be applicable to the situation at hand, and it should be the job of the tester to inform on the necessary testing at each level, based on the appetite for risk of the client and the likelihood of risk in the application.
A lot of times testing is seen as a role that gathers information and gives that out, letting others make the choice as the way to proceed. This should not be the case, testing needs to be about good empowered decisions by the testers on the ground doing the work, analysing the risk and making reasonable suggestions as to the level of testing required.
Clear and consistent view of testing
Everybody in the programme needs to understand and agree the approach to testing, and everybody needs to understand where they fit in and what they are required to do.
Optimise business value
Testing done well, will inform the business of the best way forward, and help the business get the best “bang for their buck” in terms of effort expended in various functional areas. It will help make the tough decisions, and drive the development effort based on the risk of each choice of story. It will help the prioritisation based on understanding of the complexity of the system.
Testing is actually a very organic process; it can’t be tied down into a set of automated scripts and manual test cases, as that approach gives you the least understanding of the actual quality of the system you have built. It’s the bug you never saw coming that will take down your system, and the way to find those sorts of bugs is by Exploratory Testing. That is where the value of your testers lies, and everything you do in your testing efforts should be in support of freeing up those testers to do that exploratory testing.
Test automation, testing metrics, test reports etc… are not a driver in and of themselves, the goal of testing is not to produce reports and write tests, the goal of testing is to get the product out the door, and everything we do needs to be in support of that goal. If a metric doesn’t help that, we don’t produce it, if the team doesn’t need a written test case, we don’t create it, if a test report doesn’t help the development team, we don’t write it.