XP Testing Without XP: Taking Advantage of Agile Testing Practices - Page 3

Lisa Crispin, http://lisacrispin.com/

Executing Tests

Hopefully, you had the opportunity to write executable tests. If so, when code is delivered to you for testing, you've got a major jump on the test automation.

You're not on an XP team, but maybe there are still ways you can benefit from the advantages of 'pairing'. Collaborate with a fellow tester to spike some test automation solutions. Engage a programmer in brainstorming automation solutions.

The refactoring practice, changing code for the sake of maintainability or efficiency, is important for test automators. Take a little time every day to make little changes to your automated test scripts that will help you maintain them and run them effectively in the long term. You never really get the chance for that big modification, so take tiny steps as you go.

Start Early

Can the developers give you little bits and pieces to test? If you were able to convince them to take an XP-style approach to planning, this part is easy. They'll develop testable chunks in short iterations and you can race along. If not, see what you can get delivered to you early. Maybe a programmer has a solution in mind but isn't sure if it will scale well. Help by doing a performance test.

Involve the business experts as much as possible in testing. Keep simplicity in mind: What's the simplest way to execute these tests? I hate to have to say it, but automation isn't always the answer. You may have a one-time test, or you may need intelligent exploratory testing by a subject matter expert. Just remember to keep it as simple as possible! In most software projects, no matter what the methodology, you only have time to test the minimum.

Let Worry Be Your Guide

Risk assessments will help you and your stakeholders from worrying. Take a deep breath and determine what the minimum amount of testing will prove to the customer that the system behaves as specified. Lots of people have a negative view of the word 'minimum', but if it weren't 'good enough', it wouldn't be the minimum. Have courage: in most software projects, if you pull off the minimum testing, you're golden.

XP builds risk assessment into the system with the planning game. The programmers always estimate all the stories and state their potential velocity, and the business experts or customers choose the ones most important to them that will fit into each iteration. With a more traditional project, look to a traditional risk assessment to help you. Identify risk areas, assessing the probability and impact of each. Work to mitigate the top one or two risks, then tackle the next one or two. Here's a sample risk assessment:

Item	Impact	Probability	Risk
Search produces no results	4	3	12
System capacity exceeded	5	2	10
Data out of date	4	4	16

Numbers like these often get management's attention when nothing else will.

Retrospectives

Retrospectives are so important, some gurus such as Martin Fowler consider them to be one of the XP practices. Quality assurance is all about learning from history. Retrospectives let your team continually improve how you do your jobs.

Identifying Areas of Pain

There are different approaches to retrospectives (I much prefer this positive term to the oft-used 'post-mortem'). Generally, your team looks at what went well, what didn't go so well, what the team should start doing, what the team should keep doing, and what the team should stop doing. It's sometimes hard to find time for retrospective meetings, but they're a giant opportunity for the agile tester. I've found they are an ideal place to demonstrate how XP or other agile practices helped testing on the project. The goal of retrospectives is to identify areas of pain and form an action plan to mitigate the top two or three. This is a great opportunity to look to agile practices for solutions.

In my case, over the course of many months, our test team built up credibility by doing a super job of manual testing. Then, we had a chance to show what value we could add with test automation. We did our own internal retrospectives, and demonstrated improvement by focusing on our problem areas. I also took every opportunity to expose the technical management and the programmers to agile techniques, by encouraging attendance at XP Denver meetings, distributing links and magazine articles, and taking advantage of an XP/agile consultant who offered a couple hours of his time to demonstrate test-driven development.

As a result, the leaders of the development team are curious about what agile practices might help them. Retrospectives are an ideal time to talk about these. Are requirements documents always inadequate, or take too long to produce? Writing acceptance tests up front, if you haven't been able to do this up to now, is the ideal solution! This isn't an article on how to introduce agile practices, but as a tester who benefits from XP testing practices, you can help your team improve quality by seeing what else it can borrow from the XP and agile world.

Celebrating Success

My favorite aspect of XP is how it celebrates success. When programmers or testers complete a task, they ring a bell or go play a round of Foosball (maybe nobody plays Foosball anymore in this economy!) I like to bring treats such as brownies to celebrate a release or just making it through a hard week. We're often too busy going on to the next project(s) to notice, but it's a nice lift for our team to go out to lunch or a little happy hour after a retrospective meeting to toast our accomplishments. Like all creatures, we do better with positive reinforcement than with negative punishment.

Perhaps the most important aspect of XP, which should be applied across all software development processes, is the one-team approach. Testers aren't a separate, after-the-fact entity. They're an integral part of the development team. As my buddy Mike Clark says, there is no "QA" in "team". Do whatever you can to help your whole team work towards delivering high-quality software on time.

Testing provides continuous feedback to help your whole team do their best work. Take baby steps if you have to - any progress is hugely rewarding! Above all, remember to follow Kent Beck's advice, and embrace change!

---

Related Software Testing and Agile Knowledge

Software Testing Magazine

Scrum Expert

Functional Testing Tools Directory

---

Go to parge 2   Back to the archive list

This article was originally published in the Summer 2003 issue of Methods & Tools