About Ali Khalid

This author has not yet filled in any details.
So far Ali Khalid has created 77 blog entries.

Is your UI automation flaky?

By | March 20th, 2018|daily post|

Any ideas why ‘MOST’ UI scripts are flaky..

Inherently UI automation is flaky, I’ll give you that.

Lots of moving parts and rapid pace of change

However the major reason is not that, it’s going in without learning and planning

UI automation can be very stable if the right approach is used

Managing code complexity

Following framework design pillars

Test data management and some more tips:

Reducing UI Automation Problems to Debug

Source control tools selection for automation

By | March 19th, 2018|daily post|

Any different from dev teams?

Automation is pretty much like developing software

And should ‘EXACLTY’ be treated like a dev project

Therefore shouldn’t be much of a difference, also having synergies with dev is a good idea

Especially if they are have a decent SCM (Source Control Management) system

Although best to have separate repos (no brainer)

Importantly look out for CI tools integrations

Even if you are not planning CI right now, you will (and must) in the future

Tool selection is not as important as it is to design your SCM process

Even with a great tool a foolish process can make things pretty hard


Automating legacy products

By | March 18th, 2018|daily post|

From the lens of an automation architect

The front end is in some ways easy and hard to automate

Synchronization can be a problem but object identification can get easier

API automation can be a challenge, since they are not designed to be consumed for folks other than developers

Dev and test environment creation can be old school, that means creating and tearing them down is hard

More points under each of these areas can be explored here:

Email / chat response time expectations

By | March 17th, 2018|daily post|

Is a response within 24 hours acceptable?

It used to be a response within 24 hours is good enough to any email

With the rise of social media platforms and instant messaging, it is expected to be responsive all the time

Some people pride on their capability to respond within few hours any time of the day (night)

This habit can be detrimental to ‘Deep thinking’, which is what essentially we are paid to do

A human brain can focus only on one thing at a time in order to ‘think deep’

Also there is a switching cost from one task to the other. It’s not like flipping a switch

Going back and forth between different things can make you feel more exhausted

And ‘reduce’ your productivity since you’d not be able to hit the ‘deep thinking’ zone on 2x to 10x your mental capacity

I feel a ‘within’ 24 hours response from a ‘select few’ contacts on important conversations

And an ‘whenever possible’ response on communication from other contacts and non-important topics should be the expectation

Try spending more time daily thinking deep and less switching and doing shallow stuff

Lessons from “Deep Work” – Cal Newport

Want to start learning programming?

By | March 16th, 2018|daily post|

And it happens to be your old nemesis?

Around me I see people starting programming the wrong way

They start with a lot of new things to learn the same time

Complex IDEs, complex languages, configurations, advanced concepts..

Handling all these things the same time is not a smart move

The basics to learn programming IMHO has to do with algorithm design

Apptitude to think how to give instructions to a dumb machine

For those starting this journey, my two cents on where to start

Develop the right aptitude and attitude:

Client server applications automation

By | March 15th, 2018|daily post|

A question from the Automation Guild 2018

Install selenium and write tests for all screens – NO!

That can be a start, but not the plan on how to approach this

Not everything can be assessed completely sitting at the client side

Also, automating scenarios on the back end layers is more easier and effective

You would want to check all moving parts in separately

Wisdom from the ‘Automation Pyramid’

More here:


Did you know Jenkins is written in Java

By | March 14th, 2018|daily post|

And is therefore very easy to install, configure and backup..

Java being platform independent, makes running Jenkins a lot easier

However some folks do get stuck setting up Java the first time

Installing the JDK (Java Development Kit) can turn into a painful process

An easy way is to install ‘Chocolately’ – A software packaging manager

In layman terms, makes ‘packages’ installation a lot easier

All you have to do is run simple windows batch commands, and it does the download, install and windows configuration for you

More on that and background on Jenkins installation here:

Jenkins – Installation Background


Reducing UI Automation Problems to Debug

By | March 14th, 2018|UI Automation|

How much time would you guess an average programmer spends on debugging code? The few studies I’ve looked at estimate around 50% of the time. This is a great insight to improve one’s efficiency. If extra thought is put into while writing the feature / script the first time, it can have a many times fold reduction in the time spent on debugging problems. Secondly if we get better at debugging, that too can have a large impact on a programmer’s productivity

In this article, with reference to UI automation, I’ll briefly go over how to avoid having to debug more problems in the first place. Then some tips on debugging to increase the speed and effectiveness of fixes from my experience.

Before we talk about how to debug, let’s take a step back and discuss how to reduce the number of times we have to debug problems in the first place. With reference to UI automation problems, how to reduce flakiness, to manage maintenance time and debug lesser number of problems. Apart from flakiness, there are a few other common factors as well causing issues, being discussed further on.

Avoiding flakiness

It is impossible to write a piece of code that would not have any problem ever, therefore debugging is inevitable. However, if a program is written with the deliberate intention to fix issues while the ‘imminent’ debug exercise, you and your team are in for a long and bumpy road. It’s far better to spend extra time thinking over the algorithm and architectural impact / update instead of jumping right onto the implementation.

Here are a few general tips on reducing ‘inherent’ flakiness and coding problems down the road.

Code complexity

Luckily, I started my career on safety critical devices. One of the practices I picked from there was code complexity. A concept I don’t see a lot of software development teams these days.

“Cyclomatic Complexity” is a software metric used to identify the complexity of a piece of code developed by Thomas J. McCabe, Sr in 1976 [1]. Using this (and other metrics) the complexity is calculated with the intent of requiring the code to be less than a specific benchmark value (for firmware written for embedded / IoT devices the benchmark is 30).

The premise of the concept is, once the code goes above a certain threshold, the software is more prone to defects [1] and can go into unknown states, therefore should limit the amount of complexity we add to our code. Going into the details of it would require a separate article, to summarize on reducing it, as the number of decisions increase within a method, break into multiple methods / classes / modules to reduce the complexity.

Framework design principles

Quality is built into the design, cannot be painted on a product once it’s developed. The same goes for automation code, if you don’t have a carefully thought framework developed, there is no way you can have a stable automation run. Adding bandages on deeply infected wounds does not solve the problem, the root cause must be fixed.

Pillars of framework design

In my experience, there are four “pillars of automation framework design” to be followed, specifically for UI automation projects which are maintainability, reusability, scalability and robustness. This is a very extensive and important subject. To get started you can go over all four pillars brief description in this article. Following best practices while architecting helps in reducing the number of issues we would see and must debug.

Mostly flakiness in automated scripts is a direct result of poor architectural framework design. You can either face a problem learn from the mistakes and then correct them, or learn from other’s experience and avoid introducing a problem. Best to learn from other’s mistakes.

Environment stability

An automation environment can include a lot of things, while all components of an environment are important, referring the few having the most impact on flakiness here.

Test data

Pre-requisite test data is the most common reason of flakiness. Talking about test data under the test environment might be debatable, however the wrong test data management process (or the absence of one) can create havoc on your results. You can read more on the subject from this article written for TEST Magazine.

Environment Setup

Setting the environment (especially in cases where you might be orchestrating one on the fly) for the AUT and automation can save lots of debugging time waste. Examples include setting browsers to use with settings like unblocking popups, clearing cache, browser restore settings, autocomplete features and more. OS settings like opening required ports / firewall settings, any installations needed might be as well.


The patching and deployment process of your AUT. While this might not strictly come under the automation team’s ‘dominion’, but can have a great impact on automation test runs. Errors in patching can happen especially where the process is not seasoned enough.

Tools / Libraries

Tools and dependencies used for automation also need to be vetted. I’ve seen tool’s / library’s bugs causing problems. For instance, tools crashing or giving unexpected errors. It’s best to test for such possible issues during the selection process and test scalability of solutions to be used.

Selection of scenarios to automate

Some tests are inherently going to cause problems during execution and be hard to maintain. Such tests are best not automated. This again is a separate subject on selection of tools to automate, here we’ll mention only a few important ones.

Features expected to go through major change can be put off until the feature is reasonably agreed upon and implemented. In case of rapid changes specifically around UI elements can cost more in maintenance than doing it manually the first few iterations.

We talked about code complexity, AUT features can be complex as well which would also create similar problems to complex code. A very long test, or lots of different features being tested in one flow, or an inherently single complex feature can all have this effect. In many cases such scenarios can be broken down into multiple smaller cases reducing the complexity. In cases where that’s not possible, might be best not to automate such scenarios, or have a strong strategy to do it.

Debugging will live on

Taking all precautions to reduce code complexity and automate less complex features, following design principles, environment stability and choosing the right scenarios to automate might all reduce the number of problems you’d have to debug, but will never reach the point where no maintenance or debugging would be needed. In the next post will go over tips on how to efficiently debug problems without growing a fat tumor worrying about fixing broken code.

Redefining Software Quality – Technological advancement

By | March 13th, 2018|daily post|

Am I the only one to feel the word ‘tester’ is synonymous to ‘being non-technical’?

Many testers are just basic users of technology

And feel no obligation in learning the magic happening behind the scene

Testing software is not like quality control for flip flops

The complexity and its impact on people’s lives requires a tester to know how the software is working

And test across the technology stack according to the architecture

That does not mean you need to be ‘Elon Musk’ type technical,

But you should know the control flow of data from the front end into the DB and back in front of the user

I have a few theories on how testers traditionally thought to be ‘absolved’ of being technical, which is for a later discussion

But one of my values I stand for is ‘Technological Advancement’

One of the three aspects that would distinguish the ‘Next generation tester’


Automation tool selection

By | March 12th, 2018|daily post|

Follow the ‘decision making process’

One of the most valuable things I learned in my MBA – ‘The decision making criteria’

This is a real short synopsis which might make no sense right now, I’ll write something in detail later on

1. Identify goals and objectives – Gauge product quality, increase delivery speed, build confidence

2. Decision making criteria – Maintainability, Reusability, Scalability and Robustness

3. Core problem – E.g. Not able to increase code coverage quickly

4. Alternatives – E.g. Ready API, RestAssured, Postman, ‘quick; automation UI tools e.g. TestComplete, UFT’

5. Evaluate all alternatives with merits – Pros and Cons for each

6. Select as per decision criteria – Which tool will help to increase coverage quickly while the decision criteria (point 3) is also met

7. Implement – Track implementation progress and impact for analysis

8. Evaluate results – Retrospect

Credit: To one of my Guru’s at my business school, Prof. Fareedy.

#RedefiningSoftwareQuality #RSQ