Parasoft's Adam Kolawa: Software quality is a continuous process |
 |
By Jack Vaughan, Managing Editor
28 Nov 2007 | SearchSoftwareQuality.com |
|
|
As the diversity of tools used in software development has grown, best practices for managing the development process have often lagged. A more comprehensive infrastructure is needed for projects to regularly succeed, according to Adam Kolawa, CEO of Parasoft.
There is much complexity involved with implementing unit testing, static analysis, functional testing and so on. Teams do not create adequate processes to work with these tools "because people don't have the infrastructure," he said.
|
| Read an excerpt from Adam Kolawa's book Automated Defect Prevention |
| Chapter 1 -- "The Case for Automated Defect Prevention" explains what the methodology is and where it fits in with software development. Read the excerpt now. |
|
|
|
|
Kolawa explores the ins and outs of practices, processes and infrastructure needed for application lifecycle management (ALM) in his book Automated Defect Prevention, which he recently coauthored with Dorta Huizinga, professor of Computer Science at California State University, Fullerton.
The authors emphasize that infrastructure is not just technology that collects test data and rolls it up for the manager to view. Infrastructure also defines the roles of people and their interactions with technology. A complete software development cycle needs a process, and so does each of its individual phases -- requirements gathering, design and testing -- Huizinga and Kolawa write.
Managers' people skills important
Speaking with SearchSoftwareQuality.com, Kolawa said it is important for managers to understand the human aspects of infrastructure. For example, managers should be aware of how unit testing is performed within their developer ranks. Managers should also introduce ALM processes in stages, so that team members are not overwhelmed.
"If you don't do it slowly, people will actually reject it," he said.
Centralized policies, according to Kolawa, must be in place to ensure checked-in code meets the quality principles to which an organization adheres. But managers have to bring these policies online in steps.
"If you try to run all the possible rules against the code, you get so many violations that everybody gets overwhelmed," he said. "They say, 'So what? The code still somehow works, so I'm going to ignore it.'"
Because the overall process is the key, it is important for managers to be aware of how individual tasks fit into the big picture. That is especially true with unit testing, which Kolawa says is difficult to do because you are trying to take a piece and test it outside the context of the application.
"When somebody comes to me and says, 'I want to do unit testing,' my first question is, 'Why?' There are very interesting reasons you get. For example: 'It's a good thing to do.'" he said. "Well, it is good for you to eat rice and beans, but you don't."
A common reason for doing unit testing is that QA is so upset with the quality of the code that it insists developers do some level of testing. This may, in fact, be a good rationale for unit testing, says Kolawa, but he suggests this can be solved in different ways if QA works better with developers. Integration testing, he seems to infer, is more crucial than isolated unit testing.
Still, Kolawa admits that Web services -- in which third-party modules are invoked -- benefit from unit testing.
In this situation, there is no "full system" to test, and "you really need to do unit testing," he said. "It is the only way you can actually verify that the system works to some level."
|
