The requirements gap: Agile Designer

Astute readers who have followed my articles last summer on requirements and specification management may have guessed that I was leading up to something. And that something is Agile Designer from Grid-Tools.

It’s really quite neat. On the surface it looks pretty much like Visio, in the sense that you build a flow diagram of the process to be developed. However, Agile Designer goes considerably further. Firstly, once the process flow has been defined, you can automatically generate all the paths through the tree, whether these are successful or failed paths. Next, you can generate test cases for each of these paths.

Of course, for a complex application you might generate too many potential test cases when you don’t have the time or the money to test all possible paths. In order to ameliorate this, you can assign various attributes to each node, one of which is the risk associated with that operation. Thus, each path through the flow has a total risk associated with it and you can choose just to test, for example, paths with medium or higher risks.

While on the subject of myriad numbers of test cases, Agile Designer will link to third party tools such as HP’s ALM and you can import existing test cases from there for reuse within Agile Designer. Within Agile Designer, there is also a deduplication function, so you can remove versions of the same test (which tend to accumulate) so, in effect, you can use this product as a management tool for ALM. You can export test cases from Agile Designer to ALM also.

One further feature that is notable is that if a requirement changes (and therefore test cases will likewise change), then the resulting changes will be highlighted so that you get both impact analysis and traceability.

While you can use Agile Designer as a stand-alone product, you can also use it in conjunction with Grid-Tools’ Datamaker. You can get the latter to generate or retrieve the relevant data to support your test cases, depending, of course, on whether the data is actually currently available.

Okay, so that’s some brief technical details. It’s interesting to consider why Grid-Tools moved into this area. It’s sort of connected to its main focus on test data—but only sort of. The main reason is that the company has found that most requirements and specifications produced by the majority of companies were so poor that they were negatively impacting on testing. Indeed, one of the figures that the company likes to quote is that “56% of software defects can be traced back to ambiguous or incomplete requirements”. Agile Designer is about making specifications and requirements unambiguous and complete.

The reason I like Agile Designer is that it’s simple to use and understand—I can see end-users and business analysts using it as much as developers and testers; it will support agile environments very well; and, most especially, it brings a level of automation to a process that has hitherto been ill-served. I can see particular value when dealing with outsourcers, because you can provide a much clearer definition of your requirements (a picture tells a thousand words), along with the level of testing that you want the outsourcer to undertake.