Borland’s Gauntlet tool identifies a troublesome range of error types as code is developed.

Borland acquired its Gauntlet product when it bought the company of the same name early in 2006, and it spent the rest of that year building more features, and integrating Gauntlet with other products within its lifecycle quality management (LQM) stable.

Gauntlet runs in the background, checking code by running automated testing and test builds as developers submit their code to the organization’s source management repository. Its architecture facilitates the plug-in of different analyzers, each of which can focus on a discrete type of problem that may be present in code. This is one of Gauntlet’s major strengths, as Borland can readily add to the current range of problems that it highlights (environment integration, performance, security, vulnerabilities, and license compliance) – for example, it could be extended in future to validate code against development standards.

In typical development programs, developers work to achieve a certain level of code quality before considering many of the types of problem that Gauntlet identifies, but then the re-work costs mount as code that has already undergone unit testing is revised, as integration, performance and other error types that are Gauntlet’s focus, begin to appear. This re-work expense is the first level of cost that Gauntlet helps to eliminate, but perhaps of greater benefit is the management-level insight it provides from the same underlying information. By being able to identify developers from the IDs with which they check code into source management, Gauntlet can analyze the problem types that tend to be introduced per-individual (highlighting training needs), such as who is submitting untested code.

Gauntlet provides data that can be used to enable developers to fix problems at an earlier stage, without additional testing effort. It can give managers insight on progress against project plans, enable better go-live decisions, and use actual historical experience as part of decision-making. The underlying tests and builds used can be shared between development and quality assurance teams, saving further cost, and better integrating these teams.

Source: OpinionWire by Butler Group (www.butlergroup.com)