XP Testing Without an XP Team
After my rewarding, if challenging, experience as a tester on XP teams, the bad economic times caught up with me and I had to take a job back on the "dark side". Oh, my new company was great and they were interested in XP, but they were a tiny shop with a huge job to do and it felt to me like barely controlled chaos. My initial attempts to apply XP practices, such as having daily XP-style stand-ups with my test team, were disasters. I just had to hunker down, hire people that I thought would be able and willing to try agile test practices, and wait for my opportunity.
Things eventually slowed down enough for my team to have time to spike test automation solutions. Many of our applications are written in Tcl. Tcl is a powerful scripting language which can lend itself to test automation, so we taught ourselves Tcl. We needed a way to load bulk data for volume testing, and one of the programmers helped out with a Tcl script; we took over maintenance for it and started expanding its functionality. Some of our test automation could be handled with fairly simple shell scripts. Other automation requirements demanded more robust tools. As we started down our own path of exploring test automation, the programmers started writing automated unit tests.
I learned the hard way that being an advocate for XP or any kind of agile development doesn’t introduce change. Instead, you and your team need to identify what hurts and look at what XP or agile approaches could help heal that pain. By adopting XP-style planning and writing acceptance testing up front, my new development team has started exploring what agile practices might help them.
Let’s look at what agile testing practices might help you, no matter what style of software development process you are using.
Earlier in this article I referred to the values by which XP teams develop software. These were defined by Kent Beck in "Extreme Programming Explained":
Some people have added their own values to this list – the one I liked best is ‘enjoyment’. Extreme Programming is the only ‘official’ agile method I have actually practiced, but from what I have learned of agile software development in general, you can always turn to these values for guidance.
Communication is usually your first job. Whether you’re new to a position or you just want to try something new, you’re going to have to talk to your coworkers and your customers. Most importantly, you need to listen. As you proceed in your agile journey, remember the XP mantra: "Do the simplest thing that could possibly work". As a tester, feedback is your core function. You’ll need plenty of courage to try agile practices in a less-than-agile environment.
Let’s explore a typical project life cycle and see how XP practices can help you with testing, whether or not your development team is taking advantage of them.
Most projects begin with some kind of requirements gathering. The business experts may write business requirements. This is often followed by the development team producing functional specifications and/or technical specifications. If you’re working on a project which is producing documents like this, try to get in on the planning meetings. I know, the last thing you need in your life is more meetings. Requirements gathering meetings can be a great opportunity to put your agile skills to work. You’ll get a head start in understanding the project. By alternately looking at the requirements from the point of view of the end users, business experts and programmers, you can ask questions that flush out hidden assumptions.
Testing the Documentation
Whether or not you attend the meetings, you can add value to the project by ‘testing’ the documentation. This isn’t an XP concept, but it is linked to flushing out hidden assumptions during XP planning games. One way to test documents is to read through the document, writing a list of assertions. For example, maybe you’re reading requirements for an order entry system and have come up with these assertions:
* "The system will capture the customer service agent’s name".
* "The new system will be 50% faster than the old system".
* "The billing address will be required."
* "The zip code will automatically populate the city name".
Go over your assertions with the document’s author and clarify any ambiguous or contradictory assertions. Will the system capture the agent’s name by means of the agent logging into the system? What exactly in the new system will be 50% faster – the response time on each page? The time for placing an order? Do we have a baseline for the old system? If not, how do we quantify this requirement so we know it’s met? What about cases where multiple cities share the same zip code? Are there any optional fields in the address (such as the second address line)? Clearing up these issues now will save time for the programmers later, just as it does during an XP planning game.
If you’ve got a big project where the team sees a problem with finishing on time, see if there is a way you can suggest an XP approach to the planning. If the requirements can be grouped into story-like chunks, estimated by the programmers, and prioritized by the stakeholders, the team can take an iterative approach which will help ensure that some percentage of the necessary features are 100% ready by the deadline, even if less critical features are not yet implemented. If you’re new to agile processes or new to this team, it might not be the right time to take such a bold step, but keep it in mind.