Yesterday, you were a tester on a QA team, testing the features that the developers delivered in the last drop. But you've just come out of a meeting in which your boss announced that, from now on, the company is adopting agile testing as its development methodology. As of today, you're a member of an agile team, and you're going to see some changes in the way you work. And that's a good thing because, according to a Harris Poll study, even minor bugs can have major consequences,
Here are some of the key tasks you should expect to perform as a tester on an agile team:
1. Help define "done"
Yesterday, you had to wait for the business analysts to finish the requirements phase before you could start building your test plan in detail and ensure that you had full coverage and traceability for all the requirements.
Today, things are different. Rather than waiting for the business analysts to finish their work and hand it off to you, you're part of the process of defining user stories, adding them to the backlog, and helping the team define the criteria that must be met for each story to be considered "done." You're a member of a team that interacts frequently with the product owner (the business owner of the system you're building) and ensures that everyone is aligned with the functional and nonfunctional tests the user story will have to pass.
2. Scope and estimate
As an agile tester, you'll help estimate the scope and size of the testing effort for each user story. The estimated effort for testing is part of the overall estimation for the size of the user story, which can't be marked as "done" until it passes all the tests. After each sprint, your team will review and update the estimates of upcoming user stories based on the team's experience from the previous sprint and re-plan upcoming sprints based on the new estimates, which should be improving over time.
3. Assess testability
You'll be involved in the design of the software by working closely with developers to assess and advise on testability aspects. You'll also be looking at concerns such as whether software testing can be automated, whether components can be tested independently from the rest of the package, and how much information is written to the log files.
4. Design and execute test cases
On an agile project, everyone on the team plays a role in testing. Each team member might have their own specialty, but everyone is responsible for delivering the team's user stories at the end of the sprint. The team will be writing functional, performance, and automated unit tests, as well as creating scripts to automatically deploy code into test environments and execute the tests. As a tester on the team, you'll be helping to design and execute automated and manual tests, including exploratory testing. As testing is infused throughout the development process, you'll become involved in testing at the component and API level, as well as at the end-to-end and feature level. You'll also be testing those nonfunctional requirements teams sometimes refer to as the "ilities": security, reliability, maintainability, scalability, usability, and so on.
5. Automate
In an agile development environment, there are frequent small-functionality increments at the end of each sprint, which means the software is continually changing. The frequency of change makes the speed of regression testing incredibly important, because the code should be tested every time a change is committed. This means you need to automate your tests as much as possible—manual testing simply takes too long. Look for opportunities to automate tests and deployment scripts and develop test automation frameworks for your team and the rest of the agile release train.
6. Collaborate
You'll be working more closely with developers than ever before. If you find a defect, tell the developer, and let them use your system to debug so they can find and fix the problem as quickly as possible. Don't force them to set up their own system. You're working together on the same code and user story, with the same goal of providing working software at the end of the sprint.
You'll also sometimes need to help members of the team who require assistance in completing a user story that hasn't progressed as planned.
Keep in mind that collaboration in larger organizations differs from the ideal of having colocated teams in pure agile. In addition to the unavoidable interaction with enterprise bureaucracy and the need to work with non-agile teams, agile team members in large organizations often work with offshore colleagues. This introduces challenges such as different time zones, languages, and cultures. When you're colocated, much of the valuable information (and gossip) is exchanged by the water cooler or over a casual cup of coffee. Keep your off-site colleagues in the loop.
7. Verify fixes
OK. This doesn't sound new. Yesterday, you were working on verifying fixes, too. But these fixes might have been made weeks or months ago, and you could only test them when a formal build was delivered to QA. In agile though, the aim is to fix and verify bugs within the same sprint, because otherwise the tests won't pass, and the user story can't be considered "done."
In larger organizations, there might still be occasions when it's not possible to fix a defect in the same sprint, perhaps because you're working with another part of the organization that isn't aligned with your goals. Many organizations include an innovation and planning sprint, which gives you an opportunity to verify fixes later, but still within the set of sprints that make up the program increment.
8. Attend daily stand-up meetings
It's important to attend and contribute to the daily stand-up meetings. To be really effective, don't just talk about what you accomplished yesterday and what you're going to be doing today. The most important part of a daily stand-up meeting is sharing the obstacles that will prevent you from making progress as a tester on the team.
Focus on identifying and describing these obstacles to the rest of the team and enlist the help of the team to remove them. Eric Jacobson has a number of examples in his article on things a tester should say at a daily stand-up, including reviewing the steps to reproduce a specific defect, deciding which defects the developers should fix first because they're a barrier to testing the rest of the system, and so on.
9. Track different metrics
Yesterday, when you were part of a QA team, you followed metrics that were important to your organization, such as the status of requirements, number of reopened defects, etc. Today, you'll be looking at a new set of metrics that you'll need to track as part of an agile organization, such as sprint burndown, velocity, and release burndown.
10. Fail
Yes, you're allowed to fail. That's OK.
You could even say it's your responsibility to fail once in a while, but only as long as you fail fast and learn from your failures. In traditional development, failure is not only discouraged but also often punished. In agile, failure is accepted, and the lessons learned from failures are shared with the team. Support from management to accommodate failure is critical to the success of agile in the enterprise.
11. Embrace change
Today, you get to try out the second principle behind the Agile Manifesto: welcome change. Just moving to agile itself is a big change, but now that you're agile, you must be prepared not only to expect change but also to deal with it. In a traditional setting, a disruption during development can jeopardize the whole project. But in agile, any user stories that meet the "done" criteria are good to go. Because constantly grooming and reassessing the backlog is part of the agile concept, the team can accommodate and accept disruptions. The only major casualty of a disruption in agile should be the current sprint, but because you aim for short sprints, there are only a couple of weeks' work at stake.
12. Learn
You've always had to keep up with the product you're testing and the technologies you're encountering, as well as the testing itself. But now that you're in an agile organization, you'll need to learn about agile itself, including what is and isn't working for you. Make the changes you need, and keep reassessing whether they're working or if they need to be refined or removed.
New practices and responsibilities
Yesterday, you were a tester in a testing team. Today, you're a member of an agile development team working with other agile teams in your organization. To make that transition, you need to adopt some new practices and responsibilities.
Understanding the tasks above should help you and your team members maximize your contribution to the agile organization. What are your thoughts? Anything you would add to this list?
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
