News

Best Practices: Building a Test-Driven Development Team

• By Stephen Swoyer
• August 23, 2006

It’s no secret that many programmers disdain software quality assurance (QA) testing. From feeling it’s beneath them to resenting the overall tedium and onerous nature of testing—let alone the time it takes and delays it can add to application delivery—for a lot of code jockeys, software QA testing is just plain anathema.  

Not all programmers feel this way, of course. Thanks to the rise of test-driven development (TDD) and other agile approaches to software development, more and more IT pros have come to embrace testing as a way to accelerate development and improve overall quality levels. Now that development tools vendors such as Compuware, Computer Associates (CA), and IBM have started to deliver testing-friendly toolsets—complete with canned support for unit and functional testing during the application development process—it might be just a matter of time before QA testing comes down from its pointy-headed peak and back home to the programming pit.

That’s where it started out, years ago, in the mainframe world, says Cory Foy, an agile programming enthusiast and a Java developer with a prominent online provider of used vehicle information and other services.

“The funny thing is that it didn't used to be that way,” referring to the separate responsibilities of software development and QA testing. “Back when computing resources were scarce, developers thoroughly tested and prototyped their apps, and worked closely with the customer to make sure it met their needs. They had to—it might be two days before they got the chance to have time on the machine again. I'm just not sure [when] we split off [from] that [approach].”

Regardless of when or how such a split happened, it has helped sour many developers on testing altogether, if for no other reason that they associate tests and testing with their nitpicking QA taskmasters.

That’s the way it was for one prominent provider of asset and help-desk management software, says Virgil Delecolle, a QA tester with that firm. (Delecolle asked that his company not be named.)  Delecolle’s company maintained separate development and QA teams, and both worked in entirely separate spaces, communicating almost entirely via Lotus Notes. The development team programmed and the QA team tested, he says—because that’s the way it’s supposed to be, right? One upshot: developers actively resented being corrected by QA testers.

“I think it was in such a situation for several reasons. Nobody likes to be told that he has done bad work, that there are bugs in his code, for example. So when a member of the QA underlines a bug, it is not really appreciated by the developer, more especially if the two teams are well separated. The other reason is that the points of view were different; the developers were working to build something powerful, doing many things, with a lot of knowledge; the testers were expecting something useful and user-friendly.”

More recently, Delecolle’s employer took a different tack. Management decided to tear down the literal and figurative walls that helped segregate software development from QA testing—in a phased manner, of course.

“The first important change was to put developers and testers in the same open space,” he explains, noting that the Documentation team was included in this reorganization. “This really helps to give the idea of a single team and to build a team spirit with everyone. The communication is better; for example, when there is a bug, it is no [longer perceived as] a personal attack. If someone needs some info to reproduce a bug, or to write a new test, he only has to walk two meters and ask. There are also some jokes and all the stuff you have in a real team—but now including development, documentation and QA.”

Not that testing has been taken out of the hands of Delecolle and his other QA nitpickers. “What we've done at the same time is to automate the tests. This leads to quicker feedback and regression control. That made the difference,” he indicates. “Nowadays, testing is still a QA job. ... We are trying to write new tests on what they are coding, so that it can be validated quickly, but we are also writing tests with the help of product managers, who have the best knowledge of our customers and their expectations, so that the final product will more [closely] fit those expectations. I can say that it's a long trip, but we are on the way.”

In the model Delecolle describes, QA writes the tests that are, in turn, consumed by software development. In many cases, he says, developers have asked QA to develop new, automated tests designed to address specific points. Programmers are happy because they aren’t required to write the tests in the first place—notwithstanding the growing popularity of TDD and other approaches, a lot of coders just don’t like cribbing unit or functional tests—and they’re given more control over, and insight into, the testing process itself. Everybody wins.

It’s all about tearing down walls, says independent programmer (and agile programming enthusiast) George Dinwiddie, a principal with programming consultancy iDIA Computing.

“People go to work every day and concentrate on the task they've been assigned.  As most software is produced in larger organizations, these tasks have been finely divided into narrower concerns. In the process, people working on different concerns have distanced themselves from each other,” he observes. “The software testers work with other software testers, and the developers work with other developers. Even within these groups you'll find further division—[for example,] between GUI developers, enterprise developers and database developers.”

The big picture gets lost in a maze of fragmentation and segregation, Dinwiddie argues. “Software developers see their job as delivering software that does what they intend. Software testers see their job as finding flaws in delivered software.  This difference in focus naturally sets up a conflict between the two groups. In fact, both viewpoints are vital, and it's difficult, if not impossible, for a person to accommodate both at once.  That's why it's critical to have both developers and testers. The two start with different assumptions and proceed with a different focus. The key is getting them to work together rather than in opposition.”

That’s one reason Dinwiddie advocates an organizational shift of sorts. “The base strategy is to develop an organizational culture where the customer—or customer proxy, such as a product manager—the software developers, and the QA testers are all working together to produce the desired result.”

Dinwiddie and other back-to-basics advocates acknowledge that a transition to test-centered software development is easier said than done. After all, would-be reformers must not only overcome organizational inertia but embedded turf-warring instincts, too. “There are no guarantees, of course, and everyone still has to expend the effort to work together,” he concedes. “Most of the time, this simple practice will result in mutual understanding and respect. That respect is the cornerstone of working to the same goals.”

What’s the payoff? Aside from improved relations (and genuine collaboration) between software development and QA, Sam Taha, a programmer with an ISV that develops employee information management software, thinks a move to software-centric testing—be it by means of TDD or other, testing-oriented approaches—can help increase software quality, too.

It’s a standard modus operandi in other disciplines, after all. “It is often just assumed that QA owns testing and engineers just do the coding. This in my mind is a bad premise to have. Any developer that tells me that it is not his job to do testing has just violated the first rule of being a good engineer,” he argues.

“Just for moment, imagine a structural building or airplane engineer telling you it is not his [or] her job to do testing or [to] demonstrate that his design is structurally sound. Look at how much testing hardware engineers do and how much time is spent on testing upfront during design and simulation. So why is software any different? Because it is easier to slap together software than to build an airplane for example?”

For this reason and others, too, Taha, like a growing number of programmers, is a big believer in test-oriented development. “Because of the virtual nature of software—you can’t really touch it or feel it—management often views it as something that can be patched or fix after the fact. However, good software design requires the developers to invest more emotionally into what they are designing and to take pride in the testing of the software and the final quality,” he notes.

“Often, the excuse can be cost or that the time spent on testing is too high,” he adds. “and while it may cost more to have developers doing more testing and developing, it pays for itself down the line.”