Adventures in Geekland

Support Languages

My current fascination with support (and incorporating Agile approaches into support processes), suddenly chimed with the MPS system (from JetBrains) that Martin Fowler was talking about.

The basic unit of business value is the Story. Stories are written for all functionality, but they can also be used for issue reporting. The process by which a defect is reported can often be poorly communicated, leading to unclear (and therefore unreproducible) issue reports.
Issue reporting would benefit from pairing (all issues could be written up jointly by reporter (the customer) and support analyst. The offspring from this pairing would be a well written issue story.

Can we provide any tools that would allow this story to be written in an effective way? It seems to me to be an ontological issue - if we have a vocabulary which describes all aspects of a system, then we can start to write bug reports using that vocabulary. This language could appear very similar to the language used to describe functional tests. For instance [using Java and the Abbot framework] if you had written the following functional test (created during an early iteration of the software)


class LoginRequirement extends ClientFunctionalTest {
public void testSuccessfulLogin(){
LoginScreen login = new Login Screen();
login.enterUserName( "jim01" )
login.enterPassword( "password" )
login.clickLogin();
MainScreen main = new MainScreen(); //asserts that MainScreen is showing
}
}

you could express a reproduction of the bug in a similar way, albeit with indication of the failure points:

LoginScreen login = new Login Screen();
login.enterUserName( "jim01" )
login.enterPassword( "password" )
login.clickLogin();
/** @language = support
fail( new ErrorScreen("NullPointerException") );
**/

This has obvious limitations:

• a knowledge of Java is required
• a knowledge of the Abbot screen objects
• non-functional requirements can't be expressed easily (e.g. performance)
• knowing where to express environmental context (e.g. time of day, which version of software, IP address of client, etc)

We can generalise these issues:

• The story markup language
• Ontology of the application
• Issue-tracking related concepts

There are many possible story markup languages. Some will deal with distributed enterprise applications. Some will deal with rule based systems. Some will deal with user interface design. An "overdue library book" in the ontology can be expressed in each of these languages - by a database row, by a business rule, by a screenshot. The language used to express story cards uses all of these languages - and they should be linked together.

A general support language would be used across multiple applications and domains. A enterprise application language is useful to engineers. An EPOS language would be useful to retail system analysts. Linking these languages together would bring true domain driven design closer. Languages such as UML, Java, Junit, XSD, are just mechanisms for representating part of the ontology. Collectively this concept is known as meta-programming, or language oriented programming, or even literate programming.

As discussed above - bug reports use two languages - one for expressing user behaviour (I clicked the red button), and another for expressing issue context (On thursday afternoon, from IP w.x.y.z., as an admin user) and non-functional effects (took 2 minutes to respond).

The ontology is a shared domain model of the application. Different roles (e.g. users, developers, support engineers, business analysts, sponsors) within an organisation understand subsets of the ontology. Traditionally it has been very difficult to share different views of the ontology across these roles since different roles use different languages. For instance, how do you link a story card written in Word to an area of functionality in the code, in such a way as this link can be maintained over time. How do screenshots relate to runtime behaviour?

Here's an example story: Jim sees a fault while scanning in a returned DVD. Imagine a system that tracked the user actions that had occurred, and generated a bug report in the same language in which the business story was written (e.g. a bug report written in Abbot, as above). This bug report could be easily (manually) transformed into a functional test that could be run against new builds of the application.

By allowing defects in the application to be expressed in higher level languages, we can support this example. We might add elements to the bug report:

• Rules (expressed in a rule language) that matched the DVD code (is it a 3 day rental, does it have any related offers)
• DB scripts invoked (SQL)
• The DB script would relate to some object/relational layer, so the referential integrity violations could be expressed in UML (or some textual equivalent).
• A representation of the current UI (either as a screendump, or by inspecting UI component states)
• The path through the application so far could be expressed as manipulation of screen objects (like in the Abbot example).

All this will provide better information than a simple Java stack trace or core dump.

If these ontological elements are stored as part of the defect, then we can start annotating ontological elements in the model with multiple defects. For example, we may index defects by the stack trace reported, or we may search for defects depending on which button was last pressed, or which table is updated.

There are some trade-offs to such an approach

• the mapping of state into multiple representations will have some impact on raw performance of a running system
• there will still be issues which are caused by defects outside the current ontology (e.g. power failure).
• Tools that support the whole ontology must be available to all (or else the bug reports are going to be pretty abstruse)
• A support language to be generally applicable will be complex to write (although languages can evolve over time as requirements arise)

posted by Nick Drew @ 11:33 am