Learn Agile Techniques to Become a More Valuable Tester

[article]
Summary:

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.

User Comments

7 comments
Leanne Howard's picture

Thank you Karthi, I am glad that I have given you some inspiration.  Good luck on your agile testing journey.

July 5, 2016 - 8:38pm
Jones Ray's picture

Not a methodology! The Agile movement seeks alternatives to traditional project management. Agile approaches help teams respond to unpredictability through incremental, iterative work cadences and empirical feedback. Agilists propose alternatives to waterfall, or traditional sequential development. Very point, As a Experienced Guy in this topic, your post gave a detailed understanding about the aboive points. Well did, 

Check here for AngularJS 

February 2, 2017 - 5:48am
Leanne Howard's picture

Thank you to those of you that took the time to post a comment.  I am always interested in sharing experiences.

July 27, 2016 - 7:19pm
Tim Thompson's picture

Nice article, but it makes one assumption that I find harder and harder to come by: "that the system under test is performing as per the requirements". Requirements? Since we went Agile I no longer get requirements, the argument being that we are Agile now. There is is really bad idea out there that Agile equates to no documentation, no commitments, no requiremnts, and the fastest way to push features out the door regardless of quality.

I think being more flexible is great, but I sorely wish we had the waterfallish times back when I knew what the business expected before I started writing any tests. As it is right now, I have to guess and make things up as best as I can, then debate with developers who claim that having proper validation for input was never asked for and thus the lack of it is "not a bug, but a feature request" that we may hit next iteration.

I hope you made other experiences, but to me Agile in practice is the death of software quality....which is so odd because it was intended to achieve exactly the opposite.

July 29, 2016 - 6:52am
Leanne Howard's picture

Tim, this is not my experience.  I do get requirements in my agile projects, they are just in a different format - a user story.  I also get a lot better understanding of what the Business wants as I do not have to rely on documentation, but have a Product Owner to talk to.  Plus the whole team has the same understanding via using the Three Amigos.  No them and us between deve, BA and test.

August 30, 2016 - 1:43am
ramya krishnan's picture

Very nice one, Thanks for your valuable information and time, it is very easy to understand which clear my doubts on agile.

 

July 1, 2017 - 3:07am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.