Agile Methods Target Higher Quality

By Lindsey Vereen

The ability to achieve both high productivity and high quality is a conundrum for software developers. Agile methodologies have been proposed as a solution that allows developers to solve the functionality versus defects trade-off, says Dean Leffingwell, who serves as a consulting methodologist to Boulder, Colo.-based Rally Software.

Agile methods allow teams to deliver a small amount of working code in a defined time period. “At the end of each iteration, typically two weeks in length, the teams produce incremental, working code that is potentially available for shipment,” he says. “This basic and frequent iteration foundation is the heartbeat of agility.”

He says that agile methods “forgo the large-scale, up-front planning (including test planning) and the sequential phase activities (testing at or near the end) of the traditional waterfall model of development.” Because the waterfall model entails doing system-level testing and system integration toward the end of the life cycle, much system development work occurs without the feedback that integral testing provides.

“In agile, all code is tested code,” Leffingwell says. That means that test groups don’t have to field huge amounts of code that is largely untested. “Instead the agile teams have the skills and the mandate to test the software as it’s written,” he says. “In the extreme case, tests are written even before the code is written.” When that is not the case, tests are developed at the same time code is being developed.

Continued BELOW   

When developers are forced to think through how the code will be tested, they will write code differently from they way they would have done otherwise, he says. They will create testable systems by building in the required interfaces and methods inside their components to make sure they work as they are supposed to. “This is one of the key benefits of agile methods,” he says. "These inherently testable systems exhibit higher overall quality [than would otherwise be achieved].”

Leffingwell says that agile testing processes entail the following principles:
• All code is tested code. Teams don’t deliver functionality that has been coded but not tested.
• Tests are written before, or at the same time as, the code itself.
• Testing is a team effort, which means testers and developers all write tests.
• Automation is the rule, not the exception.
• The system always runs. Continuous integration, concurrent testing and testing automation assures that there is always a running system baseline that can be continually assessed against its requirements.

These principles drive a set of practices that agile teams apply, he says, adding that most agile teams have developed a testing strategy that includes unit testing, component testing, and system and performance testing to satisfy the principles.

Unit testing is a method by which the developers themselves write testing code to test their target code at the module (class, object and interface) level. Developers have access to the internals of the object, method or interface that is being tested. They use a set of open-source and commercial method frameworks to facilitate development, management and execution of unit tests.

Continued BELOW   

Acceptance, or functional, testing, says Leffingwell, is “the testing performed by a customer, QA or test team member, product owner or other stakeholder who has the ability to evaluate any new code that has been written against its requirements.” Acceptance testing treats the system as a black box, and components and modules are evaluated based on their interaction with the user. “Acceptance testing takes place concurrently and incrementally, as each new piece of functionality is added to the system,” he says.

Systems typically comprise components and higher-level modules that fulfill certain functions and conform to a set of interfaces. “During the course of each iteration and/or release, agile teams test their systems at the component level with a variety of tools and practices,” Leffingwell says. “These tools and practices should be relevant to the languages they use and the types of systems they are building.”

Unit testing tests the code being written, acceptance testing tests the functional behavior the code delivers to the user, and component testing tests the behavior of some higher-order abstraction. “None of these methods alone (or even taken together) assures that the system as a whole meets its objectives nor will they naturally test the overall requirements of performance, accuracy, scalability or reliability,” he says. “Thus, the last level of testing is intended to test the system as a whole.”

“Taken together,” says Leffingwell, “these test practices, coupled [with] the goal of being able to perform all the testing within the course of an iteration, will drive the team to a higher level of agility and quality.”