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?

Let us look at good design principles “COHESION & COUPLING “. Good design of software is high cohesion and loose coupling. Grouping similar actions & data (cohesion) keeping minimal dependencies between them (coupling).

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.

(In this SmartBits, Sudhir Patnaik outlines “Expectations of Senior Management“.  The video is at the end of this blog)

Leadership is key. But more than organization and people leadership owning a substantial part of work is also needed. One can have an oversight on some part of the organization, but need to get hands dirty by owning areas that have no managers. This keeps one grounded and also helps develop empathy for their organization as to what they go through.
Here are the expectations :
(1) The ability to understand what the team is going through.
(2) Show up in incidents, show up in incident reviews, show up in customer escalations
(3) Keep learning newer technologies and catch up with what’s going on in the industry
(4) Have the curiosity to look at everything from a metrics driven approach.

(In this SmartBits, Sudhir Patnaik outlines “ Extreme ownership mindset “.  The video is at the end of this blog)

There is a tremendous shift towards a customer backed approach. Everything that we do is keeping our customers in mind and an extreme mindset of product ownership. The one scrum team mindset is driving phenomenal change in how we deliver products. This is where extreme ownership mindset comes into picture where a scrum team owns outcome for customer.
The days are gone, when one has to develop, somebody else has to test and somebody else has to deploy. It has to be packaged in such a way that as a member of the scrum team every single member of the scrum team owns every single responsibility.  If I am a developer or a test engineer, I own development, I own testing, I own deployment, I own support. That’s the team’s extreme ownership. That’s a disruptor.

(In this SmartBits, Sudhir Patnaik outlines “ Transforming test teams “.  The video is at the end of this blog)

As a leader running platform engineering organization, industry changes made us reimagine how we test software platforms. We decided that in the context of extreme ownership mindset by Scrum team it is best that we transform quality engineering organization and merge them with Scrum teams.

This required us to look at the entire quality engineering organization, find out people well-versed in functional, performance testing and  security testing,  and automation. In a step-by-step process, we did a shift left of quality engineering organization, re-skilling many engineers towards learning the development technologies. We moved one function at a time into the respective Scrum team, and gave them about a year to transform themselves into developers. We provided every training that was needed.At the same time, we also trained developers to embrace functional testing concepts. If one is the owner of a service, one owns its unit testing, code review and its functional testing too.

From Quality Engineering perspective this meant that half of quality engineering organization ended up merging with the Scrum team and transforming themselves into developers in a period of one year. The remaining half of the team still stay as a central organization, but largely responsible for end-to-end and non-functional testing.

They are not executors of end-to-end and non-functional testing scripts, they have transformed themselves to become more creators of tools, frameworks and scripts that are needed to get these done. Then who executes those – “Well it is the Scrum team”!

T Ashok (@ash_thiru on Twitter)

Summary

Good testing is a great combination of intellect, techniques, process and heuristics.  What does it take to do brilliant testing ? It requires one to be immersed in the act, be focussed yet unbounded, be keenly observant but non-judgemental, with outcome that are beautiful, the activity so joyful that time stops. A state of flow. What does it take to get there?

As engineers we use good techniques, tools, process and intellect to do things well. So how can we do far better, that is brilliantly? Having possibly exhausted all things “external”, in terms of tools, techniques, process and intellect, it is time we considered the huge “internal” potential that we all possess.

It is about going beyond the intellectual mind, deeper into the sub-conscious to harness the infinite potential.  A good start for this would be get into a state of ‘flow’.

So, what is FLOW?
Flow is the state when you are immersed in what you are doing, where you are totally mindful. It is when all energies are harnessed fluidly to do brilliant work without tiring or trying hard, becoming an observer, fine tuning actions with extreme agility, when time seems frozen. It is when you accomplish a lot, doing work effortlessly and experiencing absolute joy. 

So how can we get into the state of flow?
When multiple sensory excitations converge harmoniously, there is a good chance of entering that state of flow. What does that mean? It is engaging the various senses well – colours, picture, visual test, mind maps for the eyes, using pen/pencil, paper for the touch, and maybe background music or talking to oneself for ‘engaged hearing’. Note the keyword is ‘harmonious’.

When we stimulate our creative side with interesting visuals, tactile and possibly sound, it activates us to get into an ‘engaged state, a state of mindfulness. 

Exploit visual thinking by using visual text , sketch maps, mind maps  to : (1) enable  deeper understand the system under test (2) to sketch test strategy (3) jot down test ideas (4) note down observations, questions, suggestions (5) list scenarios (6) record issues.

Exploit the tactile sense by using pen/pencil on paper or finger/stylus on tablet instead of keyboard.  The objective is to be write/draw freely rather than be constrained by the keyboard. 

If you want to engage your auditory sense, quietly talking to yourself, melodious quiet whistling or if you are music person, then a suitable background song played could enable you to get into the flow. 

To ensure that we can perform in the state of peak performance being in a FLOW, it is imperative that we do testing in short sessions. A session may be anywhere between 45-90 minutes. The key is to stay focussed, setup an objective at the start of session and then engage as stated earlier to get into a state of FLOW.

How does this help?
When we are fully engaged,  in a state of FLOW,  it is no more about just left brain centred logical/deductive thinking, or the creative right. It is an expansive multi dimensional thinking brought about by the harmonious stimuli enabling one to become a keen observer and absorb deeply and rapidly. This is when we exploit the infinite power of what we possess, delving into the sub-conscious which is much larger that conscious mind. Interesting questions pop up,  ideas germinate rapidly, actions are done quickly, smallest observations captured resulting in brilliant effective testing.

In closing…
Test automation allows us to do more, and machine intelligence to do better. It is now necessary for us to delve deeper so that we complement the machine rather than compete, enabling us to be super efficient and effective by being smarter. Get into the state of flow to harness the power of sub-conscious to do brilliant testing.

CLICK HERE to view the presentation slidedeck.

(In this SmartBits, Girish Elchuri outlines “Adopting DFT thinking“.  The video is at the end of this blog)

Understand big picture Part 1
When developing a product, one must have an understanding of the big picture. It’s not only about the product, it’s about the entire process of developing it. Putting oneself in the shoes of every role is a must be it a tech writer writing product documentation, quality engineer testing the product or a salesperson. One must understand the function of each of these roles for the success of the product . We must facilitate all these roles including quality while developing a product. We must treat ourselves as a product manager, a documentation person, a quality engineer or a marketing person in order to understand the roles better.

Put yourself in every role
While trying to understand each role, we need to put in more efforts to make sure that the requirements of each and every person are met. Understanding the big picture from a product perspective, process perspective, and having an attitude of making this successful and facilitating this for every role in the product development and launch is certainly required. This is what is needed to be done and this is how we can contribute to make sure we achieve quality.

Understand big picture Part 2
Quality is not achieved by just meeting functional requirements, customer requirements, quality requirements or sales requirements. For example a perfectly working umbrella when opened the wrong way, passes the quality, but does not result in any sales as it is no more useful to the customers just like the popular phrase “operation successful but patient dead”. This should never be the case. At the end of the day, that product should succeed in the market Hence we need to have an understanding of the big picture and this is what needs to be understood by every person in the organization.

Inject probes to test better
You talked about the ability to put in hooks, put in test switches etc. Do you think that is also a mentality that I have to develop, to facilitate the probing the system?

Absolutely. I put in probes to do scalability testing. If there are a few isolated test cases that I am running manually, I can always go and look at the log and manually do these things but when I am doing scalability testing, that’s where I find the scale at which things will happen. It’s not possible to manually collect this data and write them, hence the probes to collect such information.

Attitude key to probe design
So in my opinion, it’s the attitude that matters. When you have an attitude that I want to help this guy, be it a test engineer, documentation person or salesperson, then what I do is to facilitate those things to happen in the product. What will a sales guy want to do? Sales guy would want a demo system with live data. You should facilitate that in the product. You should facilitate creating scenarios so that it can be shown to customers. You cannot expect the sales guy to do it after the product is developed without assistance.  That is why I say that attitude is key to fulfil the needs & expectation of every single person associated with the product.