12 key tasks every agile testing

professional should perform

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 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?