Six Key Roles of a Tester In An Agile World
-By Neetu Verma
The “Waterfall” versus “Agile” debate does not have the celebrity-fueled fervor of “Tastes Great, Less Filling”, but the two development approaches each have their proponents. Fans of linear projects like the Waterfall concept. Many others prefer the iterative, ongoing Agile approach.
BA (Before Agile)
Back when Waterfall was all the rage, the development approach was the same. Project plans were developed. Business analysts (BA) wrote long use-cases. Following the use-case doc, developers wrote code. Only then, after the previous steps concluded, was the project handed off to the testing team. And the entire organization prayed for everything to work. Alas, before prayers were even finished, the testing team found issues. Then, painfully, the cycle restarted. Developers fixed issues and delivered new code to the testing team once a month. Or if the organization was lucky, once every two weeks. Good times, as they say.
Fast forward a decade and Agile is the gold standard for software development methodologies. Agile testing plays an integral and iterative role with the software development team. The testing team no longer needs to wait for months to get its hands on a working piece of software. The team tests side-by-side with the developer to identify issues. And in a short amount of time, the problem can be solved, tested, and released to clients. What an amazing and incredibly efficient change! It’s almost like the software development version of “Disneyworld”, where dreams come true.
In a fast-paced Agile environment, like STP’s software development group, testing needs to deliver a quality product timely. An Agile tester wears many hats. Along with the main testing role, testers are BAs, Users, and often work alongside a developer to better understand code/unit testing.
Key Roles of a Tester in Agile Development
1. Define Testable Requirements
One of a tester’s most important roles is to help build testable requirements. Important questions to ask:
- What are we changing?
- Why are we doing this?
- How are we going to test it?
In the Agile world, where teams work together, there is no scope of non-testable requirements. Testers are an integral part of the team. Ask questions during grooming and help create small chunks of requirements/code that can be tested and delivered. This is the most challenging part of the entire process.
In waterfall, an entire feature was completed and then handed off to the tester. In Agile, one feature is broken into small, testable requirements. It is not an easy process, but it’s not impossible.
2. Define “Definition of Done”
The times have changed (in Agile). No longer do testers wait for a BA to write the requirements and handoff. The tester is part of the process. Every user’s business requirements must have a “Definition of Done”.
The entire team needs to know the acceptance criteria for each specific business need. In addition, the team needs to know what must be done before it can be called “Complete”.
3. Define Acceptance Test
What is an acceptance test? This is a set of scenarios that must be executed to verify each acceptance criteria for a given requirement.
A well-versed, high-performing team must be on the same page. There is no room for surprises. The developer must know what and how the code will be tested. This helps in creating a quality product, and it enables the team to think and conduct out-of-the-box testing. Break down the walls between the developer and the tester to build a high-performing team.
4. Estimation
Estimating work is a critical component. Too often, developers estimate work, but testers don’t. And if a team’s velocity is calculated based on the developer’s velocity, not the team’s velocity, then there’s a disconnect.
It’s time to change that, for testers to be part of the estimation. Ask questions, estimate the work. Testing teams can’t continue to calculate based on developer velocity – ultimately, the team can only deliver to the client once the product is tested successfully.
5. Test Planning and Execution
This part doesn’t change much, in Agile: the tester reviews the requirements, writes the test cases, and, once the code is delivered, executes the test.
What does change: *when* the test will be done. The goal is to test as early as possible and provide immediate feedback to the developer.
If the User Interface isn’t ready, be creative! There are numerous ways to test. For example, there are API testing, database testing, just to name a few. Work closely with the team and learn new tools and technologies to help test. Build skill sets, build quality.
Wear a user hat and perform ad-hoc testing. The goal is to break it since it’s far better for testers to find issues than the client raising an issue in a production environment. Be brave!
6. Automation
Automation is a necessity for the Agile environment. With so many development iterations, it’s impossible to keep up with manual testing.
Work with the development team to determine what acceptance tests can be added to unit testing. In addition, identify what can be automated and what will require a final manual effort. The tester’s responsibility is to find ways to automate, rather than working on manual test cases. Identify a way to create repeated tests for sprint work as well as regression testing.
Adapt, Improvise & Overcome
Agile is in, waterfall is out. Most of the software industry follows Agile methodology and marches towards the goal of better quality and expedited product delivery.
Embrace the change! Be ready for it and adapt. Sure, it is a lot of work in the beginning, but it’s worth it in the end. And by understanding the role of a tester, the team, and the organization benefit. It’s a better, brighter, more “agile” future!
