Agile Testing

Practical tips to deliver results in Agile projects

Agile development projects may come in many flavors, but all of them are characterized by short release cycles, deploying working software quickly and adapting to change. In the Agile environment, the testing team needs to bring in quick learning, minimal documentation, rapid turnaround and working closely with developers. Trigent offers some practical tips on Agile testing, gleaned from its own experience.

Each of these tips is not a 'prescription' for Agile testing. These are intended to expand the possibilities and allow the tester to adapt and not necessarily conform to traditional 'test practices'

Learn the product without written specifications

Agile projects do not have heavy and comprehensive documentation. So, to understand the expected behavior, the tester needs to go through various alternative inputs to understand the application. Some of these can be:

1. Read what the developer got as inputs to build the application - Feature list, brief write up on application capabilities, partially written use cases and any other material that will provide inputs for intended product behavior.
2. Interview product owners/ subject matter experts - Subject matter experts have a lot more knowledge than they care to express in written documents. Getting face time with SMEs and interviewing them would reveal a lot more on what the product should do.
3. Study comparable products - Studying comparable products or reading user manual documentation can provide insights into what capabilities are needed as part of the product.
4. Look out for any alternative means to learn the product - Touring the application through the GUI, reading user manuals and help text on the UI are some examples.

Consider buddy testing

"Pair programming" is a proven concept in Agile projects especially in Extreme Programming (XP) projects. The first order reaction that this is lower productivity has been proven wrong with visible gains in productivity when two programmers work together. In a testing situation, a pair of testers can generate far more test ideas than the sum of their individual outputs, especially when the module is complex. This can help uncover important bugs. It must also be recognized that buddy testing can be motivating only when the two testers can work well together.

Present test ideas instead of documenting test cases

The tester sometimes has a set of test scenarios for testing the product and needs agreement with the development team. Writing test scenario documents and circulating to developers is one approach, but there is very little chance that the developers would read and provide written feedback. A tester needs to actively improve developer-tester interaction and not restrict themselves to writing documents and handing over to developers.

So, compile the test ideas in a presentation, gather the developers for a short meeting and take live feedback. This not only gets feedback, the developers also start thinking about whether their software will pass such tests.

Practice exploratory testing

With continuous integration and incremental development, test teams need to be prepared to receive a build in the morning with a "test this today" directive. The ability to scope the work, ask the right questions, and deliver a valuable output within a few hours is the service that is needed.

In such situations, test teams need to cultivate the practice of being able to do exploratory testing which in one line is the practice of simultaneous learning, test design and test execution where the tester adapts and brings in new test ideas as they experience the product. This is in contrast to scripted testing where the test planning is done ahead of the actual testing.
(refer http://www.satisfice.com/articles/et-article.pdf for a more thorough reading).

Test performance in each iterative release

In Agile projects, each iteration includes new functionality. In the rush of testing the new features, testers tend to miss out evaluating the performance. Deferring performance tests to the end runs a risk of finding bottlenecks that need changes across the product. Instead, plan for testing the performance in each iteration and log the bottlenecks identified. The development team now gets an opportunity to fix these problems in earlier iterations. This could directly improve overall product release schedules.

Automate selectively

Test automation is a double edged sword. With dynamic or evolving features, the cost of automation and maintenance could be high, sometimes higher than the value it offers. Yet, Agile projects embrace a test driven development methodology and test team can provide real value by embracing the methodology.

If test automation is planned, it needs to be designed with the 'ability to change easily' as a design criteria. Writing data driven test scripts can enable changes quickly, and keyword driven acceptance tests are effective techniques to consider.

• A data driven test tool: Canoo
• An acceptance test tool: Fitnesse

Agile test practices are evolving and the body of knowledge is growing. The tips presented above are just a handful and the tester can bring up newer ways to handle Agile projects if the Agile manifesto and Agile principles are well understood. And certainly these tips can be applied to traditional development projects as well. The bottom line is to improve the value of testing while reducing the cost.

References and acknowledgement:

http://www.satisfice.com/articles/et-article.pdf  by James Bach
http://www.testing.com/agile/agile-testing-essay.html by Brian Marick
http://www.ddj.com/development-tools/196603549 by Scott Ambler
http://www.methodsandtools.com/archive/archive.php?id=57 by Lisa Crispin