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

Lisa Crispin, http://lisacrispin.com/

Values

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":

• Communication
• Simplicity
• Feedback
• Courage

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.

Project Planning

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.

Acceptance Tests

Write the acceptance tests (meaning any tests needed beyond unit and integration tests: system, functional, end-to-end, performance, security, whatever) during the planning phases of the project, rather than after development is complete. More importantly, if you're trying an agile approach, write executable acceptance tests.

Executable acceptance tests serve two purposes. First of all, they're a mechanism to involve your 'customer' or business expert in defining the tests which will verify that the level of quality and functionality he has specified is met. Secondly, they are a part of your automated acceptance test framework. If you can, avoid having to re-work your acceptance test cases into input to test automation tools.

There are quite a few test tool frameworks which allow this. The concept of data-driven testing isn't new to XP, and there are plenty of tools which let you define tests in an Excel spreadsheet and then use these as input to your automated tests. XP-style test frameworks abound, as well. Here are a couple of sample JUnit tests:

assertTrue(login("bob","bobspassword"))

assertFalse(login("bob",""))

The first test proves that logging in with a valid userid and password works correctly. The second proves that logging in without a valid password fails. If you have fairly savvy business users, you can train them to read this syntax. If not, it's not hard for your programmers to write a tool to suck data out of an Excel test case and input it to JUnit.

But wait a minute, you aren't on an XP team where your programmers are totally on board to help you with acceptance testing. That might rule out Fit (http://fit.c2.com) and FitNesse (http://www.fitnesse.org) as well. Fit allows you to define acceptance tests as HTML tables, which are input to fixtures written in Java, Ruby or some other language that executes the tests. FitNesse goes one better by letting you define the Fit tests as a Wiki page, a sort of modifiable HTML page that's even easier to handle than HTML. It will also let you define tests in an Excel spreadsheet and paste them onto the Wiki page. Here's a sample FIT test:

fit.ActionFixture
Start	Page
Enter	Location		http://www.searchme.com
Enter	Userid		bob
Enter	Password		bobspassword
Check	Title		Welcome to SearchMe

If you really can't get any programmer support to write the simple fixtures that drive these 'behind the GUI' tests, check out Canoo WebTest. This allows you to define test cases in XML format. Again, users might not be totally comfortable with XML format, so you might have to do the spreadsheet-to-test tool conversion.

It doesn't matter what tool you're going to use. Defining acceptance test cases up front helps your programmers write the correct code. It gives you a huge jump on your testing too.

A word about test plans. Nobody ever reads them, so try not to write them. They're cumbersome to write and impossible to maintain. Just write test cases. If your organization requires you to deliver a test plan, try to include information that will be useful to you, such as a release plan, and refer to the test cases as much as possible.

Technical Design

Depending on your technical skills, technical design meetings may be painful for you. Try to attend them anyway, if you have the opportunity. If you can even ask one question or make one comment that leads to a more testable design, you're way ahead of the game.

XP has the wonderful benefit of making everyone on the development team conscious of testability. If you have to automate and perform acceptance tests, and it's hard to do because your GUI is thick or hooked up to the back end in a way that you can't test much behind the GUI, your next application is bound to be designed to be more testable. Unfortunately, your traditional development project won't give you this golden opportunity. You can still raise these issues yourself (tactfully, of course) at design meetings. You can also continue to help facilitate communication between the business stakeholders and the programmers. You understand the application pretty well by now, and you probably are more familiar with the technical issues than the folks on the business side. Remember that communication value!

Go to page 1    Go to page 3    Back to the archive list