Daily Posts

1904, 2018

Should we have written tests to automate?

By | April 19th, 2018|

Off course..

There is the argument against writing ‘typical’ test cases altogether

Regardless of where you are on that spectrum, steps to automate in a check need to be precise

And what we are automating is as important as how we automate it

Running automated checks itself is not the purpose

Rather facilitate testers by running 1 – “mundane” but 2 – “Necessary” checks,

So they can test more important features while the dumb work is done by a machine

Without carefully thought checks / tests, will be hard to achieve this

More on that here:

1804, 2018

Unhappy with automation tools?

By | April 18th, 2018|

While some tools might have been ‘unfair’ over the years, that’s not the main problem

The main problem with automation I see is, “we don’t know the best way to approach it”

There are a few variables to analyze before you can decide the best way to do it

And generally tool vendors don’t (and probably can’t do) that job for you

While ‘some’ tools have exploited the market IMHO, it’s not just all them

We as a community are still evolving in this department

While a large part of the community is still confused with the OBJECTIVE of automation..

Kinda hard to be successful under such conditions..


1704, 2018

Should you be a programmer to do automation well?

By | April 17th, 2018|

Short answer, yes. Long answer:

Firstly, learning programming is not as difficult as expected

Usually people just follow the wrong approach

That’s why I talk about developing the aptitude for algorithm design

Secondly, there are solutions out there recommending automation tools requiring no coding skills

These ‘Scriptless’ automation or keyword automation tools are not ‘sustainable’ and don’t work in the long run

Therefore one needs to learn programming and how to code well

Thirdly, IMHO testers should be ‘Technical’, without knowing what’s going on under the hood, they cannot test well

If you are capable of grasping that much, then learning programming would not be a problem

These topics were discussed in the #PSQC18 conference talk I gave:

PSQC 2018 Conference Talk


1604, 2018

The story of excellence

By | April 16th, 2018|

Henry ford and his V8 engine

Ford designed and rolled out 4 cylinder and a 6 cylinder cars back in 1909 and 1928

Both were great feats in itself, and not the only ones Ford had earned by that time..

Still he was not done yet.

He knew having more cylinders in the engine would allow for great performance benefits

His team of engineers worked on it for years, keep coming back to him saying it was ‘impossible’ to achieve

After years of pouring in finances and persisting, finally the impossible happened

Our sixth sense is a magnificent gift, one has to wonder how did Ford know this was going to work

But to trust your gut and keep persisting, that is how you truly get success.

So my fellow testers, let’s strive for ‘Technological Excellence”


1304, 2018

Which tests to automate?

By | April 13th, 2018|

Someimtes folks look at this from the wrong perspective

Instead of looking at what is ‘supposed’ to be automated, they look at what ‘can’ be automated

Not to say try automating stuff which does not justify the effort

But the master set should be out of what we are supposed to test, and then find a subset of tests which can use automation effectively

I suggest 4 points to determine this subset:

1104, 2018

Excellence is an attitude

By | April 11th, 2018|

Either you have or don’t and it’s not a one time thing

Very few ‘might’ have this from childhood

But many acquire it over time and with practice

Excellence can be a potent driving force behind software quality

Once a culture of excellence is established, then the ride becomes a lot more fun


1004, 2018

Debugging Sherlock Style

By | April 10th, 2018|

Can we learn something for Sherlock on how to debug UI automation problems?

There are commonalities between debugging and a crime scene

Both have a couple of unknowns we have to find answers to

With the exception of a murderer trying to clean his tracks..

But debugging complex code bases can be somewhat similar too, in terms of the unknowns

The first thing to learn is study data that is available instead of jumping directly into reproducing the problem

Most often we don’t have enough data (or understanding) which is a situation we should not have in the first place

By analyzing data we can arrive at a very precise reason why there is a failure

Which, in turn, helps us solve the problem in the first or second debug attempt

If not, then the good old ‘buck shot’ method hoping to luckily stumble over the problem is attempted (we are all very familiar with)

For more lessons from Sherlock:

Debugging the Sherlock Style

904, 2018

The roots of software quality

By | April 9th, 2018|

Unfortunately were inherited from TQM (Total Quality Management)

We did (try) to tweak those concepts to adjust for software,

However looking back at the path we took, I strongly feel it was not the right one

We are nowhere near the results TQM had in manufacturing

We can’t quantify the quality of a product nor can we measure the impact of testing as accurately

IMHO this has lead the testing community to be a silent spectator in the tech industry

A corner stone to our success would be to quantify the results of testing efforts

There are pockets of folks thinking and working towards it,

But the momentum and impact we need is not there yet.

So let’s begin #RedefiningSoftwareQuality through providing #BusinessValue

My teeny contribution towards this cause:


804, 2018

Testing Micro Services

By | April 8th, 2018|

What changes in a micro service application and how to test that change

Micro-services are where we divide the one big ‘monolithic’ application into multiple specialized applications called micro services

The first change is distribution of functions, module level testing becomes easier, can verify each micro-serice in isolation

Second, verify the orchestration part. New micro-services are ‘initialized’ real time as they are needed, which needs separate testing

Thirdly, integration of modules is now different, best to add more tests around that too

More on that here:

704, 2018

The art of Presenting

By | April 7th, 2018|

Lessons learned while preparing for my talk at #PSQC18

A – The mind remembers things in a specific sequence:
1. Tell them what you want to tell them
2. Tell them
3. Tell them what you told them

B – People might forget everything about a a talk, but they’ll never forget how you made them feel

C – Story telling is one of the best ways we learn, that why right from childhood we are taught in stories

D – Feel empathetic for the audience. Walk in their shoes and feel how best you can relate to them


More on my talk today in upcoming posts..

#PSQC18 #TheArtOfPresenting

504, 2018

The Automation Pyramid’s reason to exist

By | April 5th, 2018|

80% of most application’s code is on the server side

And most of us spend all our energies testing from the front end

That is the what Automation Pyramid illustrates, for us to focus on the server side

It is an impossility to have decent code coverage from front end alone

One has to use te API and DB to get access to otherwise inaccessible code

IMHO this is one of the reasons testers are not valued,

We don’t usually know how to do the job well

So let’s move towards ‘Technological Excellence’

More on that here:


404, 2018

Psychological safety

By | April 4th, 2018|

One of the core concepts for team’s success

I read about this in ‘Smarter Faster Better’ by Charles Duhigg and leaders eat last by Simon Sinek

Both great reads for those in leadership roles

Psychological safety creates a shared belief that all members of the team are safe to take any risk

That helps them innovate more and watch each other’s back

In turn help the group achieve what no one of them could have had individually

The most successful teams studied have a common feature, Psychological safety

The same finding was also found by ‘Project Aristotle’ – A research done by Google to find traits of most successful teams



204, 2018

What is Application Containterizaion?

By | April 2nd, 2018|

Breaking your application into ‘micro-services’

We used to have a single huge application server

Having one big service (API) supporting all client side requests

Now we can ‘containerize’ the big service and break it down into many smaller pieces

Each ‘container’ providing a ‘service’ to one specific module / functionality

As needed, these ‘containers’ can be created and destroyed, depending on client’s requests

These type of services are commonly referred to as ‘micro-services’


A very vague and loosely defined terms are used here.

104, 2018

The Magic of continuous Testing

By | April 1st, 2018|

Continuous Delivery is the king maker – and you cannot have that without continuous testing

The biggest problem with releasing software is finding bugs well ahead of time

And this problem is UNIVERSAL

The solution is to have lots of automated regression running at different stages of the SDLC

That’s when the magic happens of continuous testing

When we miss bugs during testing, they keep compounding

Over time we have a giant heap of issues

Continuous testing reduces that heap and allows for smoother releases

More on that here:

The Magic of Continuous Testing

3103, 2018

Aligning goals of individuals

By | March 31st, 2018|

The biggest challenge in running teams

A lot of people don’t have any ‘real’ goal except earning money, being lazy and comfy

Most of us are un-inspired, and that’s what a leader is for, to INSPIRE people

My Guru (Prof. Fareedy) used to say you need that ‘Fire in the belly’

Where teams are working towards a common goal miracles happen

The first step is ‘having a goal’, companies with visions of ‘maximizing shareholder value’ will not cut it anymore

Have grand and selfless goals, like “eliminating gas leakage related deaths by 2100” (Industrial Scientific)

For more, I’d recommend reading the chapter on culture and goal setting from the book ‘How google works’

3003, 2018

Using precise language

By | March 30th, 2018|

The way we use words affects the way we think

In the testing community we unintentionally miscommunicate certain things

A prime example is Test Automation

The word suggests testing is being automated, however ‘testing’ is a thinking and reflecting process which our script do not do

We all know test automation does not mean automating testing

But sometimes we do forget this and succumb to what the word literally means

More on that here:

2903, 2018

What to automate?

By | March 29th, 2018|

A complex question to answer

I advocate to first find out what to ‘test’

Then from that set, look for what to automate

Automation is to support the overall testing effort

Following are the few parameters I suggest to look for:
– Frequency of test
– Importance of text
– Ease of automation
– Automation ‘Super Powers’!

Details on that here:

2803, 2018

7 lessons from debugging a test automation framework

By | March 28th, 2018|

A TechBeacon article I wrote giving tips on framework design

Event handlers are a must have in framework design

Especially for UI automation scripts

We’ve talked about UI automation being flaky by nature

There has to be a lot of event handling techniques used to make it smooth

And even with all of that, still things WILL fail

So make sure to have failsafe protocols in place or your complete 24 hours batch run might get screwed

Read the MOST interesting debug story I ever experienced and lessons learned here:



2703, 2018

Being technical is more important

By | March 27th, 2018|

More important than learning programming

Tester’s confine thier technical advancement to just automation

That is not the way it should be IMHO

There is a lot more about being ‘technical’ than programming and selenium

Understand how the software works, how the technology stack works,

How to test against the entire stack

Learn to ‘think’ on how to develop algorithms

Develop the aptitude to create troubleshoot problems

#RedefiningSoftwareQuality through #TechnologicalAdvancement

2603, 2018

Communicating effectively with clients

By | March 26th, 2018|

Communicating effectively with clients

Is something we do wrong most of the time

Roots of software quality were taken from TQM

Communicating with a customer on a tangible product easy

Corresponding on something intangible involving lots of people is hard

And most of the time that’s where we go wrong

Groups of the software vendor and groups at the client end are not always on the same page

The infimous requirement diagram we all have seen is illustrates this very well

The same was my finding on a case study I did on project escalation published here:

Be sure to keep the key stake holders on the same page, and try to stick to it.

2503, 2018

HTTP messages for client server communication

By | March 25th, 2018|

How does it work?

The first thing to understand, – it’s REALLY EASY

I use an analogy of posting a letter

You write the senders and receivers address on the envelope with the message inside

The post is delivered as per the address

Once received the envelope is opened and message received

HTTP requests (in fact all communication) works the same way

The message is wrapped in an ‘envelope’ with addresses

On receiving, the addresses are removed and message is delivered

More on that process and HTTP messages construction here:

Understanding HTTP messages

2403, 2018

Software programming requires constant learning

By | March 24th, 2018|

Software programming requires constant learning

The reason why I chose this industry

I studied more about wireless communication than software programming in my engineering

But choosing programming was a deliberate choice

Towards the end of my degree had the chance to visit a BTS installation site

I decided there and then I’ll never choose this field

I’m more interested in creating things, rather than using things designed by someone

I always enjoyed creating things from scratch and make them functional, made me feel accomplished, and to call it mine

Find out what sits well with your personality, it makes all the difference.


2303, 2018

A lot of people ‘refrain’ from programming

By | March 23rd, 2018|

And it’s not because learning it is hard..

It’s mainly because keeping up with constant troubleshooting is hard

You need to learn to feel ‘comfortable’ troubleshooting, learning, evolving

Once you solve a problem, you don’t get that problem again since the machine now solves it for you

You then move on to the next problem

So this is a never ending cycle of solving problems of different kinds

If you build the temperament for it, it can be very exciting too

More on learning to program specially for testers:

2203, 2018

Using precise language

By | March 22nd, 2018|

The way we use words affects the way we think

In the testing community we unintentionally miscommunicate certain things

A prime example is Test Automation

The word suggests testing is being automated, however ‘testing’ is a thinking and reflecting process which our script do not do

We all know test automation does not mean automating testing

But sometimes we do forget this and succumb to what the word literally means

More on that here:

2103, 2018

Building confidence in your product is important

By | March 21st, 2018|

Because ‘Perception’ IS ‘Reality’..

And automation can play a BIG role in that

Something reinforced by Oren Rubin in the Automation Guild 2018

Assuring basic features are working fine through scripts goes a long way in building that confidence

It also provides a comfort level to customers of the product’s quality

Knowing that each release has these basic tests checked makes a difference

Planning testing of the product also becomes easier

If you’re not using automation for product, something to think about


Load More Posts