T Ashok @ Ash_Thiru on Twitter

Summary

Why does a complex UI faze a tester? Is it possibly the inability to see beyond the UI, the inability to question beyond the obvious? Too many test cases, the overwhelming feeling that scientific modelling & design cannot be practised due to time constraints are some of the issues. This article outlines “How to decompose, question & analyse” to design smartly using a complex UI entity as an example.

---

During a recent consulting engagement, I noticed that a tester came up with a complicated decision table to represent the behavior 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 practised 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.

A rich UI typically has large number of data fields, some dependent on others or system settings, possibly in multiple tabbed dialogs, and doing the same thing in different screens i.e. a feature available in multiple places. This seems to pose difficulty in (1) “where-to-start” to model the behaviour (2) mixing test cases related to fields, UI and behaviour, business flow & environment dependencies.

Let us look a problem to see how we simplify testing of a rich UI using an airline application, done in four screens, each of one which seems complex.
(From http://awery.net/pages/software.html#page-screenshots)

1.Setting up a flight schedule for a flight

2. Setting the route information -“start location details”

3. Setting up the route information – “permissions”

3. Setting up the route information – “cargo details”

4. Setting up the route information – “setting up crew”

What do we see in the rich UI?

Let us analyse…
1. Firstly we can see data fields – independent and dependant one.

2. Secondly we see feature/function (some of them a mini feature) and a business flow that is really a combination of many features.

So, this single rich UI screen consists of a set of features, and enables a complex flow to be done. How do we test this?

How is this useful in TEST DESIGN for rich UI?

Let us dig in…

So, what have we done to tackle challenges of complex UI?

Well, we have:
1. DECOUPLED complex UI into COHESIVE entities : FIELD, FEATURE, FLOW & UI
2. Applied behavior driven approach for feature test design (decision table)
3. Combined outputs (variations) optimally to test the FLOW (variations table)
4. Used checklist as needed to leverage prior design

---

---

(In this SmartBits, Sudhir Patnaik outlines “Advice for career growth“.  The video is at the end of this blog)

Have a learning mindset. Technology is evolving very rapidly and the general purpose software engineering skill is on its way to becoming extinct. It is best to develop specialized skills or niche skills either in the area of test automation or in the non-functional areas or what we call it as “-ilities” testing- availability, security, scalability performance, vulnerability.  It is good to build specialized skills as opposed to staying on general purpose software engineering skill. In addition one can always become a domain expert. But the domain expertise also is transitioning to other people who are better at performing in those kinds of areas, which are needed for the software.

It is very essential to stay or at least learn technology. Those days are gone where one needs to know only what the product does. More or less, it was QA which was known as a workflow validation expert till today. As more and more logic is getting embedded into the middleware, one needs more code expertise to be able to test the software effectively. In the early 2000, we were probably talking about black & white box testing. The industry has transformed itself from black to white box today. But those who were able to catch up on white-box testing in the early 2000s must be reaping the benefits in today’s world because that is much needed today.

(In this SmartBits, Sudhir Patnaik outlines “Role of human intellect in QA“.  The video is at the end of this blog)

The way artificial intelligence and machine learning is coming into play, there will be a time where a developer doesn’t need to write code. It would be more like telling the chatbot, the business logic and it spits out the code. In fact, to some extent it is happening today, where the template code is ready and one needs to just plug in the business code.

Even in the testing world someday automation is going to be so intelligent where one just point at the software to the URL and it captures everything. There is no need for human intervention and it self-corrects whenever the things change in the website or URL.
Sometimes when we refer to test automation, we unfortunately focus only on UI automation, whereas a big piece of the world actually is platform automation because companies are transforming themselves to be known as platform organizations in the world. There is more technology on the platform side.

The human interface on the UI side will minimize itself and this is where the transformation of the shift is focusing more on the backend side. The front end is going to be driven through intelligent systems mostly. Our intervention as quality engineers on front-end side will get minimized over a period of time.

It is not easy for any computer system or whatever system one builds to understand the piece of code and magically write a unit test code. One can understand the code, can write the computer systems, can write positive and negative test cases, but that may be about 50% of the coverage; the remaining 50% of the coverage on the code still comes from humans. That is where the intellect is still needed. No chatbots can take over.