( In this SmartBits, Sriramadesikan Santhanam outlines “QA skills for digital world“.  The video is at the end of this blog)

Skills and competencies are most important. One needs to understand that it is not just the business or it’s not just the technology, it is both. One needs to acquire multiple skills. One needs to understand what the customer is going to use this product for, how is it getting implemented, the expectations of the various end users’, and their perspectives. 

Acquire those skills and competency to understand these. That’s what I advise – try to understand what customers are looking for, what their customers are seeking, and then finally what the end users are looking, for then only one will be able to test from their shoes.

We as QA people need to understand the customer’s program objectives also, that is most important. Only then will be able to align to their expectations and understand why they are making these changes and appreciate the impact/uplift they’re looking out from modern technologies.

The change in skill requirements are: In addition to knowing about technology, to be able test to meet customer program objectives. Many times in the product world, people wouldn’t have seen how people are really using it, are we aligned to them? Testers now have to have good tech/dev skills, and also have business analysis skills too.

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”!