Software testers work in many different contexts -- pharmaceutical, financial services, telephony, back office automation, and product development companies, to name a few. And they develop software using various development methodologies, including waterfall, Rational Unified Process (RUP), Scrum, Extreme Programming (XP), and code and pray (affectionately known as ad hoc).
Increasingly people are talking about and asking questions about testing on "agile" projects. What does it take to be a successful tester on an agile project? Let's take a look.
Traditional projects vs. agile projects
A lot of people say agile projects are different than "traditional" projects. T...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
hey might be, but not in the ways people typically think they are. Agile projects are faster (short iterations, working software sooner, and a sense of urgency in the entire team from the first day), but they still have many of the same problems as some traditional project lifecycles:
- Agile project teams sometimes get bad requirements, just like those that often emerge in the first iteration of a waterfall or RUP project. Agile projects don't get as much time to elaborate them into something that looks like it's not a bad requirement, but the agile approach makes bad requirements matter less.
- They often do much of the planning that occurs in other project approaches, they just do it a little bit at a time, throughout the project, and in a different way (one that attempts to value responding to change more than upfront planning).
- Agile teams still have some of the challenges inherent in coordinating an effort with multiple participants: dealing with communication across the entire team, providing opportunities for team members to grow, and planning for turnover, vacation, and holidays. Unlike a lot of project approaches, they don't try to rely on documentation to solve these problems; face-to-face communication is the preferred method for taking care of this.
- Documentation on agile projects exists, but it's more fluid and is often not considered to be "authoritative." Code that works is more important, which means team members would rather spend their efforts creating automated tests that support the code base, keeping valuable information in wikis (which change constantly), and trying agile practices such as pairing and quick daily stand-up meetings instead of creating large books of documents that nobody reads more than once.
For testers, the biggest challenge of being on an agile project team is that the software is always changing. With new code being pushed into the test environment daily or even hourly, the system you're testing becomes a moving target. Dealing with that kind of change can require different approaches to testing, with different skills, tactics, and tools. There are certain aspects of testing software that don't change just because the project team is using an agile approach to implement software, particularly in the mechanics of test execution, but some testers may need to make significant changes to their testing approach if they are going to add value on an agile software project.
You may need to change your approach
Think of a continuum for software testing. On one end you have scripted manual testing. Think of the biggest most table-filled manual test case you've seen (we've all seen at least one). That's at one end of the continuum. On the other end you have freestyle exploratory testing. Think of the last time you tested a developer's bug fix. (You may have recreated the issue that you originally submitted the defect for, and then you did that little extra bit of testing to make sure nothing else broke.) That's the other end of the continuum –- just you, no scripts, using your experience and intuition to find problems.
Exploratory testing is invaluable to an agile project. In many ways, exploratory testing embodies the Agile Manifesto, by emphasizing responsiveness to change and working software over things like comprehensive documentation and following a plan. As a result, the skills and tactics of exploratory testing (chartering, branching, backtracking, modeling, resourcing, etc.) are going to be very valuable to you as you test software that is always on the move.
If most of your experience has been testing in projects that follow the V-model or "waterfall" approach, you may have spent a lot of time designing scripted tests based on requirements documents that specify how to validate a specific feature has been implemented as required. This is a widely accepted approach to software testing, particularly in IT departments that support a business's operations, but it really doesn't work in rapidly moving agile projects.
One reason this approach is not appropriate for agile projects is the required lead time to do it well. It's not unusual for an agile project to have sprints of two to four weeks, and test cases aren't written overnight. It often takes time that agile projects typically don't have. Exploratory testing is more lightweight. It has less documentation overhead, but done properly it can have the same test coverage and can address the same level of risk. The trick is to figure out how to provide just enough structure to keep track of what you've done and evaluate the results. We often use an approach such as Session-Based Test Management, created by James Bach and Jon Bach.
Another thing that makes exploratory testing useful is that it doesn't take a lot of advance preparation. This is important because most agile methodologies emphasize volunteerism and constant planning. Volunteerism means that within the scope of a sprint, team members choose what they're going to work on when. Constant planning means that features are re-prioritized at the beginning of each sprint based on the ever-changing values of the project stakeholders. The net effect is simple: There's no comprehensive project plan. Feature delivery schedules have the potential to change every week. As a result, you need to be able to test anything, anytime, with as little upfront preparation as possible.
Introducing agility into your testing process
Without detailed requirements and a change control process that tries to keep those requirements static, one of the most critical skills you will need is chartering. When we talk about chartering, we mean making decisions about what work you will do next, how you will do it, and how you will make it meaningful to your client. It's figuring out how to tell your story about the software in a way that's meaningful to the project stakeholders and structuring your work around those stories. (It sounds an awful lot like how the developers arrange their work -- stories that we structure our work around.)
In a rapidly changing project, it is important that you make good decisions about what to test and when. If you test features that aren't ready (an easy mistake to make when the software is evolving quickly) and generate defects, you will lose credibility with the rest of the team. You need to always be aware of the state of the software. That means talking to developers, paying attention in daily stand-ups, and being adept at whatever systems are used to keep track of project work.
One of the tactics we like to teach testers is touring. Touring is simply exercising the application in different ways to improve your understanding about how things work and where risk might be. The objective is not so much to find defects as it is to create a mental model of how the software works, what it does, and which features have been completed. Touring is critical because of the impact it has on your ability to charter. You should spend some time touring the application in every iteration. That will help you to keep in touch with the overall direction of the application and keep your eyes fresh, so to speak.
David is currently testing for TriSano, an open-source, public health application and community. As part of the effort to open-source TriSano, David had to step away from the application for two weeks to test the development and installation instructions before they were released to the general public. On TriSano, two weeks is an entire iteration, and when David returned to the project he felt completely lost because several new features had been added that drastically altered his mental model of the software. Touring would have helped him keep in touch with the development effort and avoid this problem.
Make sure you don't get left out
Respect and credibility are critical on an agile project team. Developers on these teams are often very skilled, not just in coding but also in automated scripted testing, especially if they are using an approach such as Test Driven Development (TDD) or Behavior Driven Development (BDD). Don't make the mistake of treating them as if they don't understand software testing.
It's important that you earn the respect of the development team. There are a number of ways to do this, such as the "five bugs in five minutes" game, but ultimately the best way to earn respect is to add value to the project. Adding value means you provide more worth than cost. Here are some ways you can make sure you do that:
- Provide a fresh perspective on the application. It's easy for developers to get so immersed in the application that they no longer see it from the point of view of a real user.
- Do a good job isolating bugs. When you find a defect, spend a little extra time finding the simplest way possible to reproduce it. Use test-recording software such as Selenium (active) or BB TestAssistant (passive) to record your test and attach it to the defect report.
- Talk to developers before you enter a defect report. Sometimes a single defect can have a lot of symptoms, and usually it isn't helpful if you create a defect for each and every symptom. By talking to a developer before you enter a defect, he can help you understand the implications of the defect you have found before you enter a dozen defects that are ultimately caused by the same problem.
The best agile teams we've worked with want testers there to help. They know how much value a skilled tester who is focused on the big picture can add to the project. All you have to do is make sure you don't get ostracized. That means becoming a close advisor to the team. Figure out what information the team values and the information they need (those may not match), and focus on providing some balance of that information.
Agile teams are faster paced, with many the same problems traditional projects have (fortunately these problems tend to come to light faster), with some challenges that are all their own. Being an effective tester in that environment may require changing your approach and figuring out techniques for structuring your work and learning more efficiently. Don't forget that an important part of the project is also to have fun.
If you really don't want to get left behind, let how much fun you're having with the rest of the team be your barometer for when you might be struggling to keep up. In most agile teams, respect is earned through competency, and people often enjoy working only with those whom they respect.
About the authors:
About the author: Michael (Mike) Kelly is currently an independent software development consultant and trainer. Mike also writes and speaks about topics in software testing. He is a regular contributor to SearchSoftwareQuality.com and a past president for the Association for Software Testing.
David Christiansen is a project manager at a Fortune 500 financial services company where he manages IT projects using Scrum, an agile software development methodology. David is also the author of Information Technology Dark Side, a corporate IT survival guide.
