In a recent interview (see the whole post), Wolfgang Griegskamp, one of the authors of Microsoft's SpecExplorer tool, says:
We didn’t really meet with large interest in the community we dealt with at Microsoft, which consists of software developers and test engineers. Everyone has a software development background. For those people graphical notations don’t really matter. Instead, what would matter a lot to them is being able to enter a textual notation which is then converted into a graphical notation, so that, for example, sequence charts could be generated which represent test cases. That would be very handy. UML is very well suited for communicating models, but as a programmer you don’t really need that, you’re more used to textual languages and you’re probably also more productive using these. On the other hand there are domains in which, for instance, business analysts work. Usually they lack a programming background. For those people graphical models may be helpful to work more productively.
Because Conformiq tools have included graphical modeling facilities since twelve years and because many of our users are capable programmers, I just need to make a couple of clarifying comments.
The first is that Conformiq Designer does generate automatically graphical sequence charts (MSCs) to document the automatically generated tests, so thank's Wolfgang for pointing out the usefulness of that feature. Our users use the generated MSCs often in test reviews, for instance.
The second is a more technical comment. A UML statechart is basically a graphical representation of an event loop structure. SpecExplorer's textual format has special syntax for operations that can be triggered from outside the system, i.e. for event handlers. In our solution the declaration of these event handlers is pushed to graphical statecharts instead of a special textual syntax, even though it is also possible to create purely text-based models in our tool. But that's not the norm. Statecharts are very good for describing high-level event processing logic in those cases where the event loop itself has a discrete set of distinct states. In SpecExplorer models that same set of district states needs to be encoded into Boolean or other finite-domain (textual) variables. In my opinion the claim that programmers would be "more productive" using textual event processing notation than graphical is unfounded. Which is, I guess, why W.G. says "probably". Our tool has support for both, but almost everyone is still drawing statecharts; I guess that should count as an evidence to the contrary.