Transitioning from a Traditional Tester to an Agile Tester

One of the most challenging changes any organization can make is moving from a traditional lifecycle development approach to an agile one. As such, there are many books, articles, blogs, and consulting firms that aim to assist with this transition.

One question I'm often asked is "What's the difference between a tester's role in a traditional lifecycle model versus in an agile methodology?” The answer is not an easy one. There are many factors to consider, and any individual tester's or test team's experience will vary based on the organizational environment, culture, and the technology being tested.

There is a spectrum of differences, ranging from redefining the testing role and responsibilities completely to making only minor changes in context and accountability. Some individual testers and test teams will find this transition easy because it's very close to the way they are already working; other individuals and teams will find the transition much more difficult, to the extent that they may need to reinvent themselves.

At the risk of oversimplifying, here are a few key differences in the context, responsibilities, behaviors, and expectations of an agile tester versus a traditional tester.

As an Agile Tester

As a Traditional Tester

Testing is conducted immediately and continually as soon as possible, with the smallest feature(s) available. Test-driven development is employed.

Testers usually wait on a specific build or release and then begin testing once most features are implemented.

Testing is planned as part of the sprint and the release. Developers automate unit tests. Functional and nonfunctional testing is conducted iteratively within the team and in collaboration with the product owner.

One phase of testing usually builds on the next—unit, then integration, then system, then acceptance.

Bug identification and repair is in hours rather than days or weeks.

There is significant wait time between bugs being identified and bugs getting fixed.

Developers and testers operate as one team and interact continuously and collaboratively. The testing voice is equally represented.

Testers are less a part of the development team. Testers may be more distant in interaction and communication with developers and may have less of a voice.

Testers and developers are part of a homogeneous team accountable for quality delivery of the system under test.

Testers are accountable for testing. Developers are accountable for developing.

Testing is continuous and all quality steps are planned and executed iteratively by the agile team.

While the goal is always to have quality built in at every step in the lifecycle, in practice, much of the checking (quality steps) occurs during the backend testing cycle.

Automation is a must have, particularly for unit tests, as it supports continuous integration.

Automation is not a necessity because most testing of new development is done manually.

What are other key differences between the traditional testing role and the role of a tester in an agile environment?

About the Author

TechWell Insights To Go

(* Required fields)

Get the latest stories delivered to your inbox every week.