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.

T Ashok @ash_thiru on Twitter

Summary
Smartness is a brilliant combination of knowledge and skill. Skill is acquired by intense practice. Intense practice happens when you have good habits. In this article I look at SEVEN habits that are key to SmartQA.

Habit #1
Visualise well, see the big picture of the system.
Who uses, where, when, using what interface. See the big picture of how it is structured/architected, visualise the flow of control and data and the technologies used(aka tech stack). Appreciate the environments it should run on the dependencies of external systems and changes/modifications done.

Habit #2
Question well. Question to know. Question to know what you do not know. 
Ask about users and their expectations ask about the how it is constructed, ask about conditions a behaviour should satisfy.
Ask, ask… The limit to questioning is unbounded. Note you may not get all the answers, the key is to question.

Habit #3
Prove with facts. 
Show proof of adequacy of tests, hypothesise potential issues and prove that they may be detected.
Understand changes done and prove why an entity(ies) need to be regressed, after all you do not want to more that needed.

Habit #4
Iterate continuously. 
SmartQA is about experimenting, exploration.
It is about iterating with minor changes to understand better, to observe better.
Chew well to digest.

Habit #5
Unlearn. 
Revise what you know.
 Understanding is not about knowing more, it is also discarding what you know. 
Chew to digest and spit out the rest.

Habit #6
Empathise.
Put yourself in others’ shoes and feel them.
Get inside them to understand what they expect, what they will dislike, their constraints, what value they expect of the system. SmartQA is not testing the system technically, it is about delivering value.

Habit #7
Simplify the problem solving.
End users use systems to solve their problems. Great software solve them well.
Good testing is about ensuring systems do just enough i.e. simply.

T Ashok (ash_thiru on Twitter)

Summary

Inspired by how the world is handling Covid19, this article as a SlideShare lists actions taken and criteria met to contain the pandemic and correlate this to how we can deliver clean code for large scale software systems. This article focuses on the process flow and criteria for delivering clean code. 

Check out the previous article COVID19 and Clean Code Part 1: Techniques,
that outlines techniques to deliver clean code, inspired by Covid19.

T Ashok (ash_thiru on Twitter)

Summary

Corona virus aka COVID19 is a global talking point now. What is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now. In this article we take a look at the actions being taken to contain the pandemic and relate to what to do deliver clean code.

Corona virus aka COVID19 is a global talking point now. A pandemic now, it has shaken the entire population of the world, busted the business and the world economy. The major stock markets are taking a massive beating driven by the sentiment that there is no medicine for this as of now.

Interestingly the suggestions posed by experts are pretty basic stuff related to good hygiene and this seems to be the only way to go given that there is no medicine as of now.  What can we learn from COVID19 to deliver clean code?

So what is being done to contain the COVID19? Well, there are THREE actions in terms of Prevention, Detection, Containment being aggressively pursued. Three targets of young children, old people and sick persons are the most vulnerable as of now.

What is being done in terms of PREVENTION that we can relate to code?

1. Cover when you sneeze/cough => USE ASSERTS, HANDLE EXCEPTIONS
2. Wash hands frequently => SIMPLIFY, REFACTOR
3. Don’t touch surfaces => STRIVE FOR LOW COUPLING

What is being done in terms of DETECTION that we can relate to code?

1. Check for fever => DO BASIC TESTS
2. Check for other symptoms =>  USE SMART CHECKLISTS, DO DETAILED TESTS
3. Check if contact with affected => DO STATIC CODE ANALYSIS
4. Check origin on arrival (for travellers) => WRITE DEFENSIVE CODE
5. Check travel history => ANALYSE CODE COVERAGE

What is being done in terms of CONTAINMENT that we can relate to code?

1. Quarantine affected/suspected persons => REWRITE POOR CODE, DON’T FIX
2. Use masks use asserts/ EMBED TESTABILITY
3.  Publish routes travelled by affected people => PUBLISH CHANGE LOGS SO THAT OTHERS MAY ASCERTAIN IMPACT, CREATE INTERACTION MAPS, REGRESS CODE

Now who are the TARGETS that could be most impacted in COVID19  that we can relate to code?

1. Young children => NEW CODE
2. Old people => OLD CODE WITH MINIMAL DOCUMENTATION/CK COMMENTS
3. Sick people => CODE FRAGMENTS THAT HAVE BEEN BUGGY

Here is the entire learnings summarised in the full mind-map.

Check out the current article COVID19 and Clean Code Part 2 : Process & Criteria,
that outlines techniques to deliver Process & Criteria, inspired by Covid19.

(In this SmartBits, Tathagat Varma outlines “ How to reduce waste(bugs)?“. The video is at the end of this blog)

It is a holy grail of software development. We have seen from CMM days that defect prevention has been the holy grail. We fail to recognise that a software in itself is not isolated and independent. The context in which it is operating is changing all the time. Be it evolving systems, hardware, software, network or the evolving user behavior.

Ten years back when iPhone was launched, people found pinch and zoom feature very novel to use. Today it is a standard. The context in which people are changing is changing all the time. Definitely that makes sense. It is a good old saying a stitch in time saves nine and we have seen during the waterfall days how the cost of defect amplifies if not prevented. Today, even if we say we are agile, if we were to fix a defect in the production, it still costs  a lot. Definitely prevention will have its own role to play.

We are doing a lot of software reuse, whether it is third party or open source. We don’t always have control over a lot of components which we use. We get a component from somewhere and just use that. Do we really have insight into what went into when it was being designed? Do we have control over what kind of defect prevention steps were taken into that? This may or may not be known. We will still need some way of qualifying the components and putting them together and the speed at which we are aiming to really push our systems into production, it will require a lot of us to reuse.

In some sense software construction is being reduced to plumbing the whole thing. It is like the job of an architect when constructing a hundred storey building. We don’t make brick or steel pipes anymore. These just get sourced and are put together and then a system gets created in which we are able to perform incoming check criteria whether this is of the acceptable quality to us. Here some level of a component testing is done to see whether they meet our requirements.

Secondly, we put them together and see whether they really don’t burn each other out.  If we put this into the context that we have to release this into production hundred times a day, it’s kind of inevitable that we will end up doing a lot of automated testing. At some point we have to understand that if we are blindly relying on automated testing to solve or uncover every problem, that might be a little dangerous statement to make. We should use it really to make sure that whatever was the behaviour in the last build remains unchanged and unbroken and that becomes a very good verification. If new features/behaviour have been introduced, delegating that  to automated testing at the first instance might need a lot of subjectivity. We need to be a little careful. There is no definite yes and no answer but “a balance” probably is the best answer.

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

Tools & technology certainly bring in a lot of efficiencies and improves user experience, but I believe that human intellect is definitely required for SmartQA. Let’s take an example of test coverage. We definitely require intellect to validate coverage to ensure that we have the optimal set of test cases. If we were to relate this to automation, we need intellect to ensure that we have an optimal distribution of test cases across different layers as tools would not be able to do it. We as a human or an engineer would validate what is a right fit, what is the right distribution between UI or services testing.

The second example is that we need human intelligence to devise strategies to build frameworks. When we build frameworks, usage of design patterns or best practices, human intellect is required. The third example is exploratory testing, where we uncover some really interesting defects in addition to the running the scripts.