What would you say was the role of a software tester in an agile environment?
Is it just testing and logging bugs or is it more important to work closely with the project architects and developers to improve the design and code early on?

when you say "just testing", what does "just testing" mean to you? I ask, because skilled, thoughtful testing is required to go far beyond what some project stakeholders will initially think of as "just testing".
–
testerab♦Sep 18 '11 at 21:29

8 Answers
8

The role of a software tester in an agile environment - as with any other environment - is whatever it needs to be for that specific project. Sometimes there'll be a lot of close-up work with design as well testing (I personally think of design as the testing that happens before you start testing, because that's where a lot of the potentially problematic issues get sorted out), sometimes less so.

Regardless of how your particular projects and workplace sorts out, there are a few things that need to happen:

There needs to be something that documents what was tested, how, and why. This isn't so much for record-keeping purposes unless the industry you're working with requires that, as for future reference. It's not uncommon for someone to refer to old test documentation to sort out how a particular feature works and what areas of it are likely to be problematic

There needs to be at least some coordination with the programmers so you're not duplicating work. If there are a lot of unit tests in place covering the logic of the feature, the tester can focus much more on external validations. The idea is to work with the other members of the team so that your specialty, testing, supports theirs and theirs supports yours (this being the world of theory, such wonderful things are quite feasible. In the world I live in, or at least the place I work for, things are still somewhat in flux).

There also needs to be a fair amount of communication and coordination with the product owner. All the different roles in the team should be working together, and the product owner is the effective oracle on whether the feature you're building is the right feature.

In my experience with an employer in transition between waterfall and agile, I've found that I wind up initiating a lot of the communication and coordination. That may be an artefact of my employer's environment, where there is no greenfields development and the application codebase includes routines that go back over 20 years - as a tester, I've worked across a large range of it, and tend to have a broader view of what interacts with which than programmers (who naturally focus on the features they're developing or the bugs they're fixing) or product owners (who with my employer tend to have deep knowledge of the feature developments they've worked with but not the broad base of interaction).

In all, the role can be whatever you make of it, if you approach it with tact as well as enthusiasm. Good luck!

I'm not sure "more important" is the way I would phrase it. The way we approach agile is to to deliver software the customer wants quickly with high quality. What does this mean for a Tester? Members of our teams work together to complete tasks. This means a tester could do a code review, help write out requirements, code functionality, pretty much anything. The goal is to complete the project. If your time is best spent doing one of the above tasks, that's what you work on.

Does this mean the testing piece isn't important? Absolutely not. Testing is just as important in agile as it is in waterfall. In fact in my experience, testing in an agile environment is easier. Not because of the methodology exactly, but because the team members work together more. There is much less fighting between developers, testers, and project managers. Everyone's goal is the same (at least from my experience).

The Agile Manifesto talks about this principle: Individuals and interactions over processes and tools. There are no absolute rules for the role of a software tester in an agile environment, except that the tester must test. Aside from that, the software tester's role depends upon the skills and interests of the relevant parties and their interpersonal relationships.

If a tester has strong design and coding skills and has a good rapport with the project architects and developers, it may make sense for the tester to invest time in those areas. If the tester is not a strong designer or coder, or if the project architects and developers are not receptive to the tester's design and coding suggestions, or if the software tester is not receptive to his suggestions being rejected when there are good reasons for doing so, the tester should think twice about early involvement in designing and coding.

A software tester's primary job is to test; otherwise, they would not be called a software tester. Regardless of how much satisfaction a tester feels when involved in early design and coding, and regardless of how much they contribute in those areas, it is important that the tester test and log bugs. If an individual does not want to test, or does not feel it is important, they should not be a software tester.

In an agile environment, more people test, and fewer people only test. Developers write and run tests. Testers start doing things that they didn't formerly do, but which make great use of their testing skills.

In what follows, I use the word tester in a slightly unusual way, to mean "people who can apply testing skills," regardless of their job title.

A key new job of testers is to help describe the features. Just before a feature enters development, testers and others meet with the product owner to talk about the feature. One goal of the conversation is to create a set of examples that help describe the feature in concrete terms. Good testers are a great help here, because they know how to detect ambiguity, and they know how to think of relevant scenarios that haven't yet been considered. Applying those skills before development starts, rather than during or after development, means that everyone on the team understand the feature more fully. So testers, instead of "only" detecting problems, help to prevent them.

Some testers will have programming skills. They can help to turn the examples into automated tests, typically during development. Not all testers have that skill, and not have the ability or desire to become skilled at that. More and more "testing" jobs require it.

If the key examples are described up front, and if they are automated so that anyone on the team can run them at any time, what's left for testers to do? Exploratory testing. You help the team identify risks and doubts and concerns. Then you run tests to explore those. Exploratory testing means simultaneously designing tests, running tests, and learning about the system. It's very different from tests defined up front. Each test gives you information, which you then use to think up and choose the next test. You can begin exploring as soon as there's something to execute.

Also during development, testers can help developers build their skills at testing. In an agile environment, developers typically write lots of unit tests. Many developers can benefit from working with a good tester to build skills at designing tests.

Do a google search for "exploratory testing." Also important is "session-based testing," as developed by Jon Bach and James Bach.

Honestly, I would think the role of a tester is more than just finding & logging bugs in any project (agile, waterfall, seat-of-your-pants develpment, etc).

Being a good testing isn't just passively sitting & waiting for code to come over the wall then test. At any point in a project if you notice something, have an idea or something you feel you can do/contribute, find something you don't understand, or just get that 'feeling' it is a tester's job to bring that to the full team. We want it addressed early & as cheaply as possible in the development. That could be day 2 in a sprint or half way down the V in Verification/Validation.

The participation of tester in an agile environment starts from requirement and it continues till the Project delivery. And hence, testers involvement doesnot stop with just testing and logging bugs. To be more precise, Testers involvement is required for

a. Attending Project Meetings to understand Requirements, Changes - since agile is based on iterative and incremental Process. Constant interaction within team and with Product customer is required

b. Effective communication is required for testers among developers, testers and Product owner.

c. Should be capable enough of prioritizing tests I.e High and important features needs to be tested and delivered. Then, follows the Medium features and low level features. Needs to be capable enough on identifying the work items for the day

d. Testers should suggest for Test Automation of Unit & Regression testing, since agile expects more of application changes during pre/post release Build.

e. Should Focus more on exploratory testing and practice Pair Testing

f. should provide continuous feedback about the application progression to entire Team

The Agile Testing Quadrants provides a good framework for understanding the role of testing in Agile projects. This is a good reference for seeing where your testers can add value, depending on their skills.
This framework places test types in quadrants based on whether they are Business Facing or Technology facing, and if the role of the tests are to support the team or to critique the product.

In our team, the developers usually do the unit testing, and the quality members do things like:

Contribute to user stories (they have good expertise in the domain,
and strong customer affinity)

Pair with the developers to do parallel testing

Automate the system level tests (UI based tests) Document the acceptance criteria in our tool, and "accept" the story when its ready.