daily post

With Rocky motivation..

The two week long Philly visit ended few days ago.

And like each year, did the ‘Rocky thing’ again.

What fascinates me the most about Rocky is persistence.

No one can compete with sheer hard work and persistence

And there is no substitute for it,

No short cuts, no hacks, tricks, jacks, inside edges, cutting corners,

Plain and simple hard work and persistence will ALWAYS take the day.

Because it tells the God / the universe you are willing and ready to pay the price.

And you are granted success.

#persistence #inspiration

(Photo: At the rocky stairs, Philadelphia)

Now you know what a ‘Unicorn’ employee is (See previous two posts)

What to do about it…

For employers:
– If you have a Unicorn on your team or someone who has the potential to become one
– Go out of the way to take care of their interests
– That’s what happens in sports, extraodrinaty talent is paid extraordinarily, and have an extraordinary impact on results
– So the extra mile you go will get returned back many folds

– If you don’t have unicorns (or any) on your team, you are far away from success
– This is the information economy, you can’t muscle your way to success anymore

For employees:
– If you are a unicorn, know your value
– You should not be working for anything less than ‘changing the world’, and be treated as such

– If you are not a unicorn yet
– Put in the effort to become one, it will be all the worth while

If you guessed unicorn’s don’t exist, well that’s true, but..

Unicorn employees DO exist, and here’s (IMHO) who they are:

0. Attitude – This is a given (hence point 0)
– If this is not understood already, then we have a big problem

1. Technical skills – Skills that will do today’s job.
– They know (or potential to learn) the tool, language, platform you want them to work on.
– Have demonstrated competence in similar areas.

2. The Architect mindset – They don’t think about JUST the current problem
– When developing solutions they solve problem they foresee in coming years.

These two skills are hard to find, now let’s move on..

3. Communication – They talk like a marketing / sales pro
– Can communicate their point of view effectively and are good listeners
– They are social and pros at building relationships

A good software engineer who communicates well is like a singing tree, you don’t see them very often..

And lastly..

4. Leadership – Not a manager, a leader
– Can inspire, instill purpose and drive in their team
– Develop ‘psychological safety’

Now THAT is a unicorn!

Mostly ideal candidates don’t know how to sell themselves, and the ‘not so ideal’ ones sometimes know exactly how to..

Ideal candidates are good with technical skills, they know the’re stuff and are passionate about it

Since they spend more time polishing their skill, might not be as great communicators or leaders

Hence don’t know how to sell, and are difficult to find and persuade

Not so ideal ones lack technical skills, and sometimes make it up by being good at selling

They know how to up-sell and might be good communicators as well

They come up easily in the net, but can be hard to fish out,

And, IMHO, can be equally destructive for your team

So the trick I use is to stick to the few fundamental traits/skills only, and do not compromise on them.

Tomorrow I’ll talk about the candidates I call ‘unicorns’. Want to guess..?

Small code changes at the 11th hour?

It’s always a very tricky question, but here’s how I handled it

There were some fundamental changes we were working on for our UI automation project

We were not able to get to the changes in time and release time was upon us

Despite the very urgent need to check in those changes, we holded off

The dates were changed a few times but still we didn’t try to ‘sneak in’ the change

Deciding against releasing a featue is surely more stressful than this case,

But the fundamentals are the same.

I talk more about this in the linked article:

#QsDaily #Automation #ReleaseWisdom

How to do Compatibility Testing?

Wrong question, first let’s talk WHY compatibility testing.

We all know it’s meant to test our AUT’s UI on different front-end platforms (browsers, devices, OS etc.)

But it’s paramount to understand what creates the difference when running on different platforms

Let’s take a web app running on a browser for example,

It would help to understand the different components of a ‘browser’ and what portions are different

Each browser has a different ‘driver’, e.g. Chrome uses the Gecko driver.

This causes it to probably display a piece of JavaScript slightly differently than let’s say Firefox.

I’ve seen compatibility tests meaning “Run ALL tests on each device / combination)

Instead, just run tests which are checking the ‘JavaScript’ or ‘UI’ functionality of your app

The rest will be the same on every browser

#QsDaily #Automation #CompatibilityTesting #Testing

Jenkins benefits even if you are not using a CI process,

Having the collective results in one place has a lot of advantages

Can get results from different tools (might be using separate ones for UI, API and unit level) in one place

Even for one tool, having all parallel runs in one place is a big blessing

Secondly can have a combined history of all the results (in Junit format used by Jenkins by default)

Thirdly, it allows for parallelization to your tests

To scale your automation, this is going to be a must

Number Four: One can centrally control the automation execution resources from one place

Having parameterization will make things even more easier

Evolution in automation didn’t start just few years ago.

It’s been around for decades and here’s a crude synopsis:

> 1980’s: computers found their way into businesses.

> 1985: First wave of automation tools started.

> 1990’s – Advent of GUI bases OS like Windows 3.0, UI based automation tools start to pop up.

> 1995 onwards: In the race to dominate the UI automation market, eventually WinRunner dominated.

> Around 2000: New technologies like Java jump in; web takes off. New paradigm shift, from desktop to web.

> Around 2004: First version of Selenium RC introduced.

> Around 2005: WinRunner becomes QTP after the acquisition by HP.

> Web has built a lot of momentum, big push to support web UI automation started.

> 2007: Selenium Webdriver’s first version launched.

> 2007 – 2008: iOS v1.0.x released, Android v1.0 released, Mobile is born.

> 2008: Cucumber is introduced.

> 2009: Mike Cohn introduces the Automation Pyramid.

> 2014: Appium v1.0 is launched.

> Meanwhile mobile has taken off, cloud computing is picking momentum and CI/CD is spreading in the backdrop.

> 2016: Jenkins 2.0 released.

> 2018: Docker CE is launched.

* Dates are BALLPARK VALUES, just to give a crude timeline

hashtag#QsDaily hashtag#Automation hashtag#HistoryofAutomation

Automation ROI calculation

It’s not about calculating man hours saved

While automation has a lot of benefits,

Equating time spent by a tester to a machine running the test is not accurate.

Most people (including myself in the past) calculate automation ROI by man hours saved

Automation is provides only data points, they do not necessarily mean a failure.

A person has to interpret the data and conclude if we have a failure.

But then how does automation benefit us?

Some high level points in the linked article:

#QsDaily #Automation #ROI

How to learn API automation?

I’d follow the following steps:

1)

Don’t start with instaling an API automation tool

2)

Do NOT START with installing an API automation tool, learn what are API’s first then think about tools.

3)

Understanding how APIs / the HTTP request / response works. Lots of tutorials out there.

A video covering the basics linked in the comments.

4)

Test some sample APIs with POSTMAN.

That would give you an idea of how API calls are constructed and some common responses

You can try using this website as a sample:
https://jsonplaceholder.typicode.com/

5)

Look into learning RestAssured.

There are a bunch of courses out there on it. It can work in parallel with Selenium.

All you need to do is just add the Maven dependency –

P.S.
I’m using RestAssured with spring Boots!

#QsDaily #ApiAutomation #Automation #API