alikhalid

And it’s implications for automation learners

It goes like this, place a marshmallow on the table, tell the child if they don’t eat this marshmallow for another x minutes, they’ll get a second one, then leave the room.

The jist of it is, kids who can delay gratification will probably be more successful.

And I feel this holds very true for automation learners.

Starting and staying with very basic automation concepts and trying to squeeze every opportunity sitting at that level is not helpful.

Learn to do the grind today and wait for the rewards later on.

Invest in learning how to do automation well instead of doing just the bare minimum and hoping to succeed.

Yes the industry does need automation engineers, but far greater is the need for excellent ones!

#QsDaily #LearningAutomation

Here are the few places I’ve used it in:

Create isolated AUT instances
– We have separate DBs for different AUT versions
– Using docker can instantly create multiple AUT instances
– Different approaches to do it, one can be to just hook up multiple DB versions to the same app server

Multiple execution environments

– Selenium grid(s)?
– If your automation tool allows, can create multiple execution environments
– Can hook them up with Jenkins and everything will be done on the fly

I’m sure there are other uses where the AUT is NOT containerized and we can still leverage docker.

Have you tried something different? would love to hear..

Deciding what to Automate?

First let’s talk about what to test

Often when teams talk about what to automate they jump straight to regression tests

I like to start with ‘Do we have a good set of scenarios to test’ to choose from?

What to test would depend on changes, features inmportant for product positioning, most sought out features by clients, features with most bugs from the field and so on..

Once we have that list, we can talk about what to automate.

Here’s the discussion on the subject:

#QsDaily #QsEpisodes

Does verifying ethical boundaries of a product come under testing, E.g. Data privacy?

If it’s expected by management then off course, if not then?

In this age I feel we’ll have to face more ethical problems than ever before

As technology’s reach increases, more possibilities open, creating more social challenges as a by-product

As a tester, Identifying and factoring end user’s needs and wants is paramount

Keeping a moral high ground has always been tough

The decision would boil down to every person’s core values I guess

Felt this is a question many of us might face in the coming years (if not already)

Thoughts?

#QsDaily

We all learn in different ways, lessons that stick usually have more effort and emotion involved

This is one such story of debugging an automation framework problem

There were quite a few lessons we learned and have been vital in our success

If I’d have to mention just one, “Whatever can go wrong, will go wrong” (Murhpy has a lot to answer for..)

So try to figure out what can go wrong and prepare for it

For a brief summary of the story:
https://pos.li/29s544

The complete TechBeacon article here:
https://pos.li/29s545

Perhaps one of the most common and used among the Java community

For automation engineers, specially working with object oriented languages like Java and Python this is important

These will create clearner, less complex and reduced coupling in you framework

The principles might be a bit complex to understand at first,

But are very useful and worth the time spent

#QsDaily #TestersGoingTechnical

Many time it’s just inadequate planning

Sometime the change is misunderstood

Assumed as a small / localized / easy fix

One thing leads to another and we’ve opened the pandora’s box

I’ve always felt the first mistake of misjudging the change is the main culprit

BTW, this goes for automation framework changes as well

The rule of thumb I use: “If any other module of even class can get affected by the change, don’t do it at the end”

A few more tips in this article

#QsDaily #QsArticles #NotSoSmallChanges

Jim Hazen and I talk about how we keep repeating the same mistakes..

Some sample cases would be:

– Record and playback
– Automation would render testing team’s unecessary
– Treating automation as a part time activity
– Having the wrong goals to measure automation
….

To be honest, this can be a very long list, but you get the point

Here’s the discussion about why we probably keep running into the same trap every time a next wave of evolution in automation comes around

#QsEpisodes #AutomationMistakes #HistoryOfAutomation #LearningFromMistakes

Unfortunately, mostly are love and hate relations, especially between Superiors and Juniors

And here’s what I’ve experienced over the years:

– Every Superior has resentment to every team member, it might seldom and negligible, might be frequently and severe

– Similarly, every team member has resentment towards every superior, it might be seldom and negligible, or frequent and severe

Striking a balance between the love and hate is extremely hard, and equally important

The question is, how to deal with it

Well, everyone has their own way, I try to spread goodness and have no ill-will

It’s tough, seems impractical sometimes,

But my faith dictates, in the end those who spread goodness are the ones with the greatest impact and success

#QsDaily