by T Ashok

In a consulting engagement with a product company, I noticed that the tester came up with a complicated decision table to represent the behaviour model. On closer examination I noticed that he had arrived at behavioural conditions by examining the complex UI visually, rather than digging deeper to understand the behaviour. This is not the first time I have seen this, I have observed the challenge with behaviour modelling many times in numerous companies.

So “why does a complex UI faze a tester?” It is possibly the inability to see beyond the UI, the inability to question beyond the obvious. The result –  too many test cases, and the overwhelming feeling that scientific modelling & design cannot be practiced due to time constraints. Well this is the fun part of testing ‘the intellectual one’, where one decomposes an entity through a process of rational analysis and utter curiosity by thinking better to test smarter.

So how does one smartly model the system with a rich UI? How does one go beyond the veneer of the what is visible and see the various behaviours offered by this rich UI and smartly design scenarios that comprehensively evaluate the system?

What is the problem that a rich UI poses to a tester? 
What I have observed is that a rich UI results in ‘spaghetti test cases” . This is illustrated in this video below (1m:48s).

Rich UI problem analysis
Let us now analyse a rich UI of a real software to understand the challenge posed. (2m:48s minute video)

Decompose clearly to enable good design
Now let us dig deeper into the problem by analysing the various elements to test in this rich UI so that we can decompose clearly to enable good design. (3m:30s)

So what is good design?
It is about high cohesion and low coupling, as we say in software design. Let us see how we can apply this in the context of testing for good test design. (4m:19s)

Application of design principles
So what we do we now? How do we apply the good design principles here? 

1. Decompose ‘what-to-test’ into various of entries of different granularity : Fields, Features, Flow and Screen. 
2. Use a simple checklist (which is a really standard set of scenarios) to test the smaller granularity entries – Fields and Screen 
3. Model the behaviour of the higher granularity entity – Feature and Requirement maybe, using say a ‘Decision table’ and generate various test scenarios

This is outlined in the video below (2m:21s)

Summarising

1. We have ‘decoupled’ the complex UI into  ‘cohesive’ entities – Field, Feature, Flow and Screen.
2. We then applied a simple checklist to test Fields and Screen  and then applied behavior driven approach(say decision table) to design scenarios for each feature.
3. To test a flow, we combined the various unique outputs of each feature to generate the flow test scenarios.

---