Daily Posts

1605, 2018

Evolution in software and changing automation landscape

By | May 16th, 2018|

A segment from the talk with Jim Hazen:

Many times we stumble upon a problem and think, hmm seems no one ever had this before

Especially with automation, we probably have reinvented the wheel quite a few times

Going through the entire history of automation evolution would be very lenghty,

This episode talks about some main events and how automation tools, practices chnaged over the years

Very fascinating and interesting subject, here’s the video link:

#QsEpisodes #TestAutomation #AutomationHistory


1505, 2018

Best practices for logging automation results

By | May 15th, 2018|

Here’s what I have learned over the years:

Firstly the test log is not for automation folks only,

Primarily for the whole product team to consume

Plus automation folks would like to help it in their debugging also

Keeping thwese audiences in mind, following should be a part of your log:

– A good heirarchical stucture resembling the test scenarios used for regression
– Lots of debug information indended within the report
– Some info on failures we know are reported issues
– And finally best to have it in a centralized location, Jenkins would be best

More on that here:

Logging automation results – Best practices learned over time

#QsDaily #TheAutomationBlogBook #AutomationInTest

1405, 2018

How much documentation is enough?

By | May 14th, 2018|

From waterfall style having extensive documentation for each SDLC phase till the Extreme programming / SCRUM with very basics like user stories

I must add here, when teams say we’re going ‘Agile’, so don’t need anything except for user stories, that does not make me happy

Too much we run into problems of maintaining them,

Too little, and as soon as one or two key people leave their position, everyone is in trouble

It should be enough to sustain development, and keep the process lean enough

I guess everyone would agree on all the aforementioned, the problem is “Striking the right balance”..

I’d like to propose the following as a yard stick:

– Anyone wishing to understand any part of the code should not have the need to hunt down people to understand. Sufficient commenting and coding practices should be used

– Anyone wishing to learn about how the system should behave in a certain scenario, can find that info without bugging every single developer.

For application domain, one can utilize user stories, gherkin feature files (BDD), mind maps, test cases, client specifications

For code understanding, code documentation, commenting, coding practices, architecture documents

#QsDaily #RedefiningSoftwareQuality

1305, 2018

Starting an automation project

By | May 13th, 2018|

Make sure to follow the “Pillars of Automation Framework Design”

Unfortunately most teams start with UI automation

Which is the toughest and has the lowest return

Nonetheless it is important, so best to do it right

The 4 Pillars are:

  • Maintainability
  • Reusability
  • Scalability
  • Robustness

Description of those here:

Pillars of Automation Framework Design

#TheAutomationBlogBook #TestAutomation

1205, 2018

Our most important asset?

By | May 12th, 2018|

It’s one which is most scarce – TIME – and the successful know that

It cannot be created or borrowed

Every person has 24 hours, and once they pass, they will NEVER RETURN

The trick is utilize your time in the best possible place you can

Ideally we should do stuff only which we MUST do ourselves

DELEGATE anything else that can be done by someone else

This will take disciple, planning and a burning desire to head towards your goals

This is important for testers and software development teams too

“The art of self-discipline” by Brian Tracy
“The Millionaire booklet” by Grant Cardone

1105, 2018

Automation experts over the years

By | May 11th, 2018|

A #QsEpisode in which @Jim Hazen shares names of few automation experts over the years

I was familiar with most recent ones, but folks from back in the day I did not know of

Quite a few people have been contributing over the past many yers

Teaching tricks of the trade and their experiences

You either learn by experiencing it yourself or by learning from someone elses experience

It’s best not to reinvent the wheel and learn from those who have seen it before

Here’s the segment of the talk around this topic:

This is not a conclusive list. Just few names recalled at that time.

1005, 2018

It’s automation not AutoMagic

By | May 10th, 2018|

Jim Hazen shares the story behind the term he is famous for “AutoMagic”

He was kind enough to spend some time talking about automation and it’s history

Instead of uploading the whole 2 hour long talk as one video, I’ll be creating topic wise smaller ones

If you are not introduced to Jim or the term “AutoMagic”, you would want to listen to this:

905, 2018

How to get around red tape processing

By | May 9th, 2018|

Stuck with processing red tape to get things done?

Here’s one way how I went around it

I was seeing a major lacking in our code coverage for a safety critical device

The only way to test it was through white box testing, having entrenched silos it was not an easy sell

Instead of selling upfront, we went covert to build a case first

Implement and generated results from the intrusive testing technique,

Once we had a business case opened it up to management and

The miracle happened, despite it seeming impossible to institutionalize, the evidence of its necessity was evident

And since then have tried this few more times with excellent results..

Give it a try next time, I’d be eager to know how it went..

805, 2018

Jenkins for CI like WordPress for Web development?

By | May 8th, 2018|

Remember Web front end development 15 years ago, and what has WordPress and other platforms done to it today?

The same might happen with CI processes through tools like Jenkins

The number of tools providing integrations to Jenkins is getting insane

Which is a really good thing, CI and Continuous testing is becoming way important

And getting hooks in there is not as smooth yet, but we can surely get there, probably in the near future

It might feel complex if setting up Jenkins is not approached the right way

Here’s a short guide to the very basic setup and brief description on it’s moving parts:

Jenkins – Installation Background

705, 2018

Most important assets when moving on from your current job?

By | May 7th, 2018|

IMHO – Lessons learned and the relationships you built.

We might have supported financial needs while being on that job

But the lessons we learned through our experiences are far more important

And even more are the relationships we built

On that note, I’d like to thank a team member of mine who just moved on..

Thank you @Arslan for your efforts and your contribution towards the team

I truly wish you all the success and hopefully

You had great experiences with us because I’m sure we build great relationships..

605, 2018

Seeing flakiness in your UI automation scripts?

By | May 6th, 2018|

One area I see neglected a lot is code complexity

I was fortunate to have worked for safety critical devices early on and learn some valuable lessons

One of which is code complexity (nested conditions)

When your code goes beyond a certain complexity level it becomes hard to have a deterministic result

More than often, I’ve seen a single area of code made too ccrammed and complex leading to problems all over

Spread out your conditions, instead of going deep vertically, try to go horizontal in your control flow

More on common UI problems causing flakiness:


505, 2018

To improve your life, what to change first

By | May 5th, 2018|

Try changing things around you or yourself?

The kind of life you are living is not because of the people around you

It’s because of how you feel about and react to life

The people, events, opportunities we see around us are a manifestation

Manifestion of our thoughts and expectations

So to change your surrounding, change your thoughts and manifest the change you want to see

Think and become the change you want to be

How to be a badass by Jensen Shero

405, 2018

Should we consider automation as programming

By | May 4th, 2018|

Here’s why this question comes up IMHO

For decades testers have known to be ‘Non technical’

They mostly never wanted to do much with the underlying technology

When automation came along (or when it became more popular) folks thought, well these guys know nothing of programming

So this automation thingy might not be real programming, just doing some record playback

In reality, automation is not just programming,

It IS hard core SOFTWARE DEVELOPMENT (when done right)


More here:

205, 2018

Is this advice really free

By | May 2nd, 2018|

A common question I get when reaching out to people

It is human nature to expect something in return for spending time and effort

Over the years I’ve learned the trick in life is not to get, but to give

And the universe will respond back in many times more

But it takes faith and patience to keep going without return

In essence that’s what a business should do, solve people’s problems without trying to squeeze a dollar for every inch they contribute

I’ve always felt, living for something greater than yourself is a life worth living

Seth Godin, Susan Jeffers (and many more I cannot recall now)

105, 2018

Looking to add automation for a legacy product

By | May 1st, 2018|

Few things you should know before going in:

Legacy products need a different approach than most modern tech stack applications

The automation framework has to deal with the various legacy platforms used

This means compatibility with those languages, platforms is essential

In some cases it can be advantageous too, e.g. front ends built with some JQuery or custom components might make things easier

The backend might not be as ‘automation friendly’ since it was never designed for anyone other than the developer to understand

Processes, tools and the team, all would come into play

More insights in this article:

3004, 2018

A Test Harness / Testing tool made of

By | April 30th, 2018|

Angular 4 + Spring Boots + SQL..

Configuring an ERP can be VERY problematic

Getting settings the exact way a client has can be tough

There are other ways to do that (e.g. use dockerized environments) but there is the old fashion way too

Set your test environment like your client’s do the tests, revert it back

For applications having lots of configs this can be hard

That’s how we started with creating tester’s “own” test product

It had to be scalable, since there are a lot of things we might add to it

So needed a proper structure, which lead to a full-fledged product, a testing tool with:

Front end: Angular 4
Server side: Spring boots

More on this in coming weeks..

#TechnologicalExcellence #TechnicalTester #RedefiningSoftwareQuality

2904, 2018

Looking to select an automation tool?

By | April 29th, 2018|

Can your brain focus on multiple things at the same time?

In the information economy the people to thrive are who invent

The terms knowledge worker(Peter drucker) and smart creatives (google founders) are common

Yet how much of our time do we spend on thinking deeply?

Shallow activities, just passing the buck around does not create the needed value

At the minimum work with focus and precisely on one thing only

More on the subject: “Deep Work” by Cal Newport

2704, 2018

Using multiple tools for automation

By | April 27th, 2018|

I think you should have the capability

An argument for not using a multiple tools is “Too many cooks spoil the broth”

While this was more valid years ago, now most vendors know there is an inevitable need for integrations

Automation used to be just UI automation, now we have API, DB level checks as well

Distributed teams have caused different team dynamics needing a whole set of reporting and management tooling

Then we have CI / CD in the mix which also would need to be integrated

Case in point, the automation framework must have the capability to support and use multiple tools


More on that here:



2604, 2018

Parameterizing Jenkins

By | April 26th, 2018|

Did you know you can parameterize your jobs?

Especially helpful for automation

You can parameterize things like the app version / browser / DB / automation framework parameters from within Jenkins

Scheduled job runs will have default values selected every time they run

For manual job runs you can choose to select options from drop downs

The benefit:

All execution resources / environments management and results are centralized

Setting up new run routines or special case quick runs makes a big difference

And the kicker is the visibility you get from all the results in one place and accessible to all

2504, 2018

Reasons why we automate

By | April 25th, 2018|

In the start I thought just to reduce cost, here’s what I’ve learned till now:

– Yes some folks still think to reduce cost; <False> Automation only increases the testing cost

– Substitute testers; <False> Automation cannot substitute tests done by a person

– Increase test coverage; <True> Can rapidly increase features checked

– Provides confidence; <True> Increases the team and the customer’s confidence in the product

– Reduces time to market; <True> Can reduce testing time and supports continuous integration

– Shows commitment to quality; <True> While employing automation does show that, however not a good enough reason in itself

– Can find more bugs; <False> Automation checks ‘stable’ features, ideally it should not find ANY bug..

Care to share other reasons you observed?


2404, 2018

Should testers be technical?

By | April 24th, 2018|

I strongly feel they should

Firstly, let’s define technical: “Who knows how the product is designed and works”

Doesn’t mean you have to be an architect, but reasonable understanding how it works

The reason:

80% code of an application is written at the back end, isn’t it logical to spend time testing on that layer?

And without knowing how that works, it cannot be tested..

Toyota had to recall 2.1 million cars on account of a bug

More on that story here:


PSQC 2018 Conference Talk


2304, 2018

Humans are underrated

By | April 23rd, 2018|

“Excessive automation was a mistake” , “Humans are underrated” Elon Musk while commenting on Tesla’s production line

Firstly, Shout out to Elon Musk for being so transparent and honest despite his position

To the point. apparently Having too much automation turned out to be a problem..

It’s ahead of its time, the technology is probably still catching up

In this case, it was just adding (a lot) more robots to the assembly line to what already existed

Then how can anyone expect automation in test to be anywhere near testing how a human does

Bottom line, it would be ‘decades’ if EVER, for automation to substantially substitute for a tester (referring to AI as well)

On the flip side, Automation is still needed for a lot of other reasons..


2204, 2018

UI Vs API Automation

By | April 22nd, 2018|

Which to focus more on..

UI automation is the first place most automation efforts start from

However, the products we are working with have most of the code written at the back end

While the front end has just a small amount of code we have added, all our testing efforts are focused there

With API / Web services automation, one can cover more code coverage

Besides, UI automation is comparatively time intensive, fragile and slow to execute

More on that here:

UI Automation Vs API Automation


2204, 2018

Correlation between shopping and testing?

By | April 22nd, 2018|

After a long day of shopping, while me and my wallet were perspiring and thinking about testing, here’s what we feel:

Shopping considerations – function, fashion and price

The same goes for testing

Function – We need to be sure it does what it’s intended to do

Fashion – The design must feel right, sits well with the users

Price – The cost should justify the effort. Spending lots of effort on testing something trivial every release might not be wise

So next time when testing a feature, think of it as going shopping


To make the response homogeneous, imagine a shopping day with the family than just yourself.. 🙂

Load More Posts