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.
Build Agile Skills to Test Better
By using a range of testing techniques, testers can provide wide coverage with a minimal set of tests—which is smart, because the days of being able to spend weeks preparing many test cases are going, if not gone. Testers need to think smarter about what they are doing, and they need to make their work justifiable.
Asking developers for multiple signoffs, preparing thirty-page test plans, and assembling multiple metrics stating the status of tests all take the tester away from the real value they add of completing static reviews, informed test preparation, and test execution to provide confidence in the software.
Taking screenshots of bugs is also not the best use of a tester’s time. A screenshot, taken as evidence of a test result, is potentially only of value until the next build or release, when something may change. This provides no certainty that it will continue working. This goes for regression testing, too, even if it is automated. If you have the right conversations with the developers and perform some impact analysis, there is no need to run big regression packs after each build into your test environment; you simply need to select or create the correctly targeted regression tests.
That’s why it’s so important to collaborate—one of the core attributes of agile. How are your interpersonal skills? Do you feel confident speaking up in a group? Can you defend an idea or strategy? Do you know how to negotiate well enough to convince people on your team to follow your suggestions? These types of interpersonal skills can be hard to learn if you are naturally introverted, but they are critical as you progress along your career path.
You may feel uncomfortable at first, but you need to step outside your comfort zone. Do not be afraid to get some feedback. Start by asking someone you feel comfortable talking to. You also need to be good at building relationships. Believe me, when something goes wrong (and it will), if you have good relationships with the rest of the team, they will be there to help you.
You also need to step up and take ownership and accountability for your work. Take pride in what you do and how you do it. In some agile projects, there may be no test manager or even test lead on your team. This means you will have to make testing decisions and possibly coach others on the team. The best testers in this position will be self-managing, innovative, good at time management, and able to think on their feet. With the increased visibility of agile projects, it will be evident that you have a large toolkit of strategies, practices, and techniques.
Be a Self-Starter
Times are changing. Testers are expected to be well-rounded and have a wide range of skills at their disposal, both technical and interpersonal. You may be thinking that there is too much to learn, but just pick one thing, learn it well, and then move on to your next goal. You will soon find that learning continuously is something that becomes a habit.
For those of you who are up for the challenge, these are really exciting times. There are plenty of opportunities out there, so go get them! Your career is in your hands. You cannot afford to wait for your manager to put you on a course. Find out what options are open for your continued learning.
Thank you Karthi, I am glad that I have given you some inspiration. Good luck on your agile testing journey.
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
Thank you for your comment
Thank you to those of you that took the time to post a comment. I am always interested in sharing experiences.
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.
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.
Very nice one, Thanks for your valuable information and time, it is very easy to understand which clear my doubts on agile.
Very informative post. Your knowledge on Agile Testing is great. This post shows your deep knowledge on Agile. Looking for this information for a long time. Thanks for Sharing.
Thank you for your post. I enjoy sharing my experiences.