Agile is still on the rise, with many organizations that have been successful at the team level looking to scale their adoption. Consequently, it's important for testers to have practical application of agile techniques. You should know how to create tests to optimize maximum test coverage, have interpersonal skills, and successfully build relationships within the team.
Are you an agile tester? Soon, there will not be a distinction; just being in the tester role will mean you need to have agile experience.
The World Quality Report 2015–16 says the strategic role of QA and testing is growing in tandem with the increase in adoption of agile and DevOps delivery. Agile continues to be on the rise, with many organizations that have been successful at the team level looking to scale their adoption. How many of you testers are able to state that you have practical application of agile techniques?
So, what does it mean to have agile testing competencies? For me, there are some critical skills: the practical use of testing techniques to optimize maximum test coverage, interpersonal skills, and building relationships within the team.
Testing Techniques Are Your Foundation
Let’s start with the first value. I hear lots of talk about testers needing to be more technical, but to me that seems like running before we can walk. If we do not know the basics first, being more technical is not going to help at all.
Using proper testing techniques to assure the correct test coverage should be bread and butter to testers. You have to be confident that you have run the right test to find defects or that the system under test is performing as per the requirements. No test preparation should be completed without using a testing technique to break the requirement down into the component test elements, regardless of the level of testing being completed. I find that using a mind map to plan my agile tests is a good lightweight technique.
This doesn’t let you test leads, managers, or anyone else conducting a peer test review off the hook. It is still your responsibility to check that the correct coverage has been used based on the risk profile identified or on one of the other strategies you are employing, such as model-based.
Nor does it let the test specialists escape. How many of you automation testers or performance testers use techniques when you are designing your tests? If we, at all levels of test professionals, cannot talk in terms of coverage, then how can we possibly talk to the customer or business about residual risks or confidence in the system under test?
Using automation as an example, we may be able to execute quicker once the initial tests have been written, but that means we fail faster, not that we find the right failures in the code quicker. As we become more technical, we start to think like developers. That means two sets of brains and eyes looking for the same defects. Who is now going to look for the other defects, such as usability? It’s a smarter use of time for testers to coach the developers in testing techniques and get them to do the automated checking, leaving testers free to explore other areas of the product. Even better, let’s have testers and developers work together to come up with tests before the code is written and then build the quality in.
We all know the saying “Two heads are better than one.” When developers and testers work together, they approach the problem—i.e., what to test—from different viewpoints. The developer will normally look at the test subject from a positive view—maybe you have heard it called “the happy path”—while the tester often looks at it from a negative angle, thinking of the “what if” scenarios. Pairing these two results in a comprehensive set of tests. When applying a risk-based testing approach on top of this set, they may reduce it to a more economic subset to build and execute.
Not only does this help the tester design better tests, but the developer also can take some of these tests and automate them, using test-driven development to build the minimum code required to make them pass. The tester knows what tests the developer has run, so she can eliminate duplicates, increasing the team’s efficiency.