Analytical tool tests app code
- By Florence Olsen
- Apr 20, 1998
NEW YORK--Visual 2000 was the best analytical tool the Army Simulation, Training and
Instrumentation Command has found for testing application code at its combat training
centers, STRICOM project director Mark Jozwiak said at a year 2000 conference here last
"Now we know where the broken modules are," Jozwiak said.
The Visual 2000 tool from McCabe & Associates Inc. of Columbia, Md., is a
test-coverage analyzer that identifies the high-risk modules within applications. The
information lets the Army and other agencies design tests that target the date-logic paths
their applications use most frequently.
As time runs out, "The only hope in testing is to use rifle shot instead of
buckshot," McCabe & Associates founder Tom McCabe said.
McCabe has seen fewer instances of date variables and date-dependent logic in
government code than in financial code, he said. About 5 percent of the government code he
has seen had embedded dates, and those dates affected about 10 percent of the logic paths.
There is no value in testing all the modules if "90 percent of that testing is
wasted," McCabe said.
In contrast, about 6 percent of the financial application code McCabe has seen had
embedded dates, and those dates affected about 26 percent of the logic paths.
The McCabe test-coverage analyzer creates management reports showing the percentage of
completed logic-path tests and future-date tests. It shows executives clearly which
applications are not going to make it, said Don Estes, chief technology officer for 2000
Technologies Corp. of Lexington, Mass.
The goal of year 2000 testing should be "a containable level of faults, not zero
faults," Estes said. "We have faults now, and we handle them."
The dollars budgeted for year 2000 testing should be in line with the importance of the
"If you want high accuracy and low risk, expect the cost of testing to be 80
percent of the total," Estes said.
McCabe's analytical tool, though very useful, still requires considerable human
expertise, STRICOM's Jozwiak said. "I'm working those boys to death, and when it's
not right I make them do it again," he said.
The McCabe tool runs under SunSoft Solaris, Microsoft Windows NT 4.0 and Windows 95
operating systems. It analyzes Cobol, C, C++, Visual Basic, Fortran and Ada languages.
A complete set of year 2000 test tools, according to test experts, will likely have
tools to create aged test data, simulate future system dates, capture and play back
transactions, analyze test coverage and evaluate test results.
Users will spend a lot of effort "to little effect, if they don't have realistic
test data that forces them down paths they need to be forced down," said Joseph
Allegra, president and chief executive officer of Princeton Softech Inc. of Princeton,
Creating test data and verifying results for relational databases "is much
harder" than with flat files, because a single transaction may affect dozens of
tables, Allegra said.
In fact, creating adequate test data may be the largest single task for year 2000
project leaders, Estes said. If you use production data, you can wind up with insufficient
test coverage or, if you use custom-designed data, you may do more testing than necessary.
The goal, Estes said, should be to get code working for year 2000, "not to test
all the code that you've never tested in the past."
The unique challenges of year 2000 testing come from having to simulate conditions,
test logic paths, guarantee the application will work as before, and verify the stress
points, Allegra said. At a stress point, a calculation might contain, for example, one
date in 1999 and another in 2000. Estes said even experts do not really know what
constitutes a sufficient set of future dates for such testing.