Daily Posts

1009, 2018

Philly visit and the rocky Stairs

By | September 10th, 2018|

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)

709, 2018

Handling and becoming unicorn employees

By | September 7th, 2018|

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

609, 2018

Who are ‘Unicorn’ employees

By | September 6th, 2018|

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!

509, 2018

The engineers hiring dilemma

By | September 5th, 2018|

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..?

808, 2018

Eleventh Hour Changes

By | August 8th, 2018|

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:

The ‘not’ so small code changes

#QsDaily #Automation #ReleaseWisdom

708, 2018

What is Compatibility Testing

By | August 7th, 2018|

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

608, 2018

Jenkins just for Automation

By | August 6th, 2018|

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

508, 2018

Evolution in Automation

By | August 5th, 2018|

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

308, 2018

Automation ROI

By | August 3rd, 2018|

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:

Does Automation Save Money?

#QsDaily #Automation #ROI

208, 2018

Learning API automation

By | August 2nd, 2018|

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

3107, 2018

Automation is NOT just UI Automation

By | July 31st, 2018|

TestAutomation != Ui_AutomationOnly;

AutomationInTest == UI_Automation + API_Automation + UnitTests + WhateverYouCanComeUpWith; // This can be a long list

Any mundane test programmed to be checked through a tool would classify under automation

Since UI automation is the most widely implemented form of automation, it has become synonymous with automation

API automation is very valuable and should come directly under an automation engineer’s core responsibilities

Often since we start off ‘not as aware’ about the technology stack, we’re not really sure how API testing is done

Linked article stacks up UI vs API automation to illustrate the benefits.

http://quality-spectrum.com/ui-automation-vs-api-automation/

#QsDaily #ApiAutomation #UiAutomation #Automation

3007, 2018

McCabe Code Complexity

By | July 30th, 2018|

Configurability and complexity go hand in hand

Thanks to Thomas J McCabe for proving this concept

I have to say, over time things do get streamlines when layers upon layers of abstraction are added

But while developing a product, or automation framework, the more configurable we try to make it, the more complex it becomes

For that reason, Thomas McCabe came up with this algorithm to calculate complexity

Embedded / IoT devices standards dictate to keep the McCabe cyclomatic complexity (Code complexity) below 30

It’s not a bad idea to calculate your code’s complexity level and stick to a limit

Makes life a lot easier down the road.

#QsDaily #Automation #CodeComplexity

2907, 2018

Learn automation or go technical

By | July 29th, 2018|

Want to learn or hire for automation?

“To be technical or not to be, that is the question”..

While speaking at a conference I tried to outline the journey of a tester

While there were a lot of lessons to learn, the premise was to focus on learning the underlying technology

Familiarity with just an automation tool will not bring the results you want, for both, as an employer or as an employee

What you really are looking for is a technical background AND be able to program tests at the same time

#QsDaily #TestersGoingTechnical #Automation

2807, 2018

DevOps and Tenacity

By | July 28th, 2018|

DevOps and Tenacity

Here’s the relationship..

The differential between the good and the great is Tenacity

The great know to hashtag#NeverBackDown / hashtag#NeverGiveIn, and that’s what makes them great

Success consists of going from failure to failure without loss of enthusiasm (Winston Churchil)

In delivering software there are a lot of unknowns, many things can go wrong, and you’ll never get it right the first few times

So, keep on improving and at an accelerating speed. For which you and your team must be tenacious

And to me that’s what DevOps is, keep improving at speed, keep going from failure to failure without loss of enthusiasm, or simply put ‘fail fast’

#QsDaily #NeverBackDown #DevOps #FailFast

2707, 2018

Programming an important skill

By | July 27th, 2018|

I’m often asked how to learn automation

On of the most important skill is programming..

Firstly, often times this subject is not approached the right way

Folks attempt at ‘codeless’ or ‘keyword based’ automation at first

IMHO, while it might work for a finite scope and technology stack, generally it’s seen not to deliver

In the end, to do automation well you’ll have to program. there is no way around it

Secondly, learning programming is not about being good with Java or any one language’s syntax

It’s about building the right APTITUDE and the right ATTITUDE

With those two, the language becomes irrelevant. And without them your skill in any language will not create desired results

#QsDaily #Automation #Programming #TestersGoingTechnical

2607, 2018

AutoMagic by Jim Hazen

By | July 26th, 2018|

“AutoMagic” – Jim Hazen

Here’s what it means:

The assumption of automation being a silver bullet to solve all testing problems

Depicting the thought process of automation somehow ‘magically’ doing all the testing we have toBy following some simple steps (record and playback) and all your worries are over FOR LIFE..

I’m pretty sure most folks reading this are way past that point of understanding

But the term Jim has coined always fascinated me

Here is a short clip of Jim explaining the story how he came about to coin the term

#QsDaily #Automation

2507, 2018

Deleting a build run in Jenkins

By | July 25th, 2018|

Deleting a batch run result for a Jenkins job

Why would you want to do it and how..

I must mention first there is a ton of value in using Jenkins,

It’s not only easier to run, use and share results, but also can give a historic view of the results

I have nightly builds and sometimes due to unavoidable circumstance there are some batch runs which really shouldn’t be in the history for that job (it’s a long story, so just humor me)

To keep your batch run history clear of any unnecessary ‘noise’ you might want to delete a specific job run result

Here’s how you do it:

  1. From Jenkins “configure global security” page, set ‘Anyone can do anything’ in the ‘Authorization’ section
  2. Run CMD with admin rights and ‘cd’ into Jenkins-cli.jar file location (e.g. C:\Program Files (x86)\Jenkins\war\WEB-INF)
  3. Confirm the batch run you want to delete (this is irreversible)
  4. Write the following command:
    1. java -jar jenkins-cli.jar -s       <Jenkins server>     delete-builds     <job name>              <build number to delete>
  5. Restore security settings

Tadaa!

P.S.

I know this was written very short hand, will write up a post on a few tips including this one.

#QsDaily #Automation #Jenkins

2407, 2018

The concept of Jenkins

By | July 24th, 2018|

Often folks start learning the semantics and forget the concept

The same goes with learning Jenkins, so here’s the ‘concept’:

There used to be so many steps to deploy a product (ask someone who has been in a release manager kind of role)

All that time was wasted on useless mis-management, trying to merge code properly which should have been done anyway in the first place

Plus the time to do all these repetitive tasks day in day out

A few ‘God gifted’ members of the software community started working to solve this back in 2004

After lot’s of hard work, acquisitions and court trails, today we know that project as ‘Jenkins’ with over 1000 contributors

Working towards the goal of making the deployment of software easier, the corner stone of DevOps

A quick introduction to ‘how’ Jenkins solves this problem is in this article:

#QsDaily #Automation #DevOps #Jenkins

Jenkins – A quick introduction

2307, 2018

Why is UI automation not easy

By | July 23rd, 2018|

It’s not easy to get UI automation right

And here’s the reason why:

The AUT GUI will keep on changing, the browsers / mobile OS get updated every few months and the automation tool also keep upgrading

The automation framework needs to be loosely coupled to adapt to all these rapid changes

It ends up like a person trying to balance himself on three moving wooden planks at sea which keep on drifting..

Another analogy I remember is from car CD players problem

Even when a car is running smoothly, there are subtle vibrations, enough to disrupt the lens reading data off the CD

The industry started to engineer car CD players to be flexible enough to cater for these jitters and even bigger ones to avoid the disruption in reading data

So keep your automation framework fluid, easy / quick to update, and robust enough to overcome any small bumps and tides which are inevitable

#QsDaily #automation

The Automation Blog Book

2207, 2018

Compatibility testing

By | July 22nd, 2018|

An important area to leverage automation

The number of front ends applications need to support are increasing day by day

While this is a nightmare testing by a person, automation can be a big help

Making scripts reusable with the ability to run smoothly on multiple platforms and app versions is a no brainer

What’s not so common are the tests to add under this category

Conventional wisdom is to run ALL TESTS on ALL possible environments, but that’s just not smart

IHMO, any part of our app’s code that is affected by the browser / mobile OS etc. should be included here

For instance if a specific control is used multiple places in the application, testing it extensively in one place should suffice for compatibility tests for that control

And no need to test it every other place in the application

#QsDaily

2107, 2018

The power of goal setting

By | July 21st, 2018|

The power of writing your goals

I don’t know why, but it certainly is more powerful than most think

I read the concept the first time from Brian Tracey’s book “The miracle of self-discipline”

According to him, goal setting is the best part of his trainings people come up to him and talk about how it transformed them

From my personal experience, writing goals daily has been a game changer for me too

It has helped me stay true to my purpose, meet with awesome people and open doors I never knew existed

So here’s my goal setting ritual:

1. Anything I want to implement in my life, or goals I want to achieve, I write an affirmation for them
2. That builds my latest list of affirmations
3. First thing in the morning, I write my affirmations

And that’s it!

Try it out and let me know!

For more reading, audio book link : https://www.briantracy.com/catalog/the-miracle-of-self-discipline

P.S.
This will take time. So, “TRUST THE PROCESS”.

#QsDaily

2007, 2018

Programming for testers

By | July 20th, 2018|

For those starting from scratch, here are my two cents

Writing code is not that hard, but being good at it certainly is

IME, folks starting on the wrong foot struggle for a very long time

Having the aptitude of problem solving and thinking like a machine

Coupled with the right attitude towards the problem solving process makes all the difference

More on that here:

1907, 2018

Automation logs.

By | July 19th, 2018|

Did I ever mention I’m allergic to messy code?

There’s something I hate even more, horrible automation logs

Often I’ve seen automation logs / results are so complex and very hard to navigate

The only thing you might learn is how many tests passed or failed and that’s about it

I design my logs to be like an airplane black box

If any of my scripts go down, I want ALL the information I need to figure out what happened

AND the log has to be perfectly readable by ANYONE in the team

BTW, that’s how the first F-16 was designed, they didn’t start with what they CAN build, rather what fighter pilot’s dream features were

To read more on how to build a great test log:
#QsDaily #automation #TestResults

 

\https://goo.gl/YcgSbM

1807, 2018

How I built a test harness

By | July 18th, 2018|

How I decided to build a test harness:

Angular 4 + Spring Boots + SQL, (and oh my it is so much fun!)

It could have been done with using a front interface like Jenkins

The backend with some simple scripts in restAssured and plain Java, but would not have been scalable

Keeping good design practices of maintainability, scalability, reusability and robustness, we had to take the tougher route

When deciding on how to solve the problem, don’t look at the effort needed today, the solution should be scalable enough for years to come

I always quote to my team, don’t program thinking of today, rather a 3rd person reading it a year from now

#QsDaily #TestHarness

1707, 2018

Deciding what to automate

By | July 17th, 2018|

Deciding what to automate – part 2

Once you what to test, find the subset of what to automate

Again everything you want to ‘test’ cannot be ‘checked’

It’s best to be smart about what should be automated

While the most common answer to this question is ‘automate what we can’

There’s a fundamental flaw in that, not necessarily all we CAN automate is WORTH automating

If a feature is hardly changed and used, automation efforts are best spent elsewhere

Conversely, if a certain feature is time consuming to test and has to be done every time, I’d rather automate that feature.

More factors IMHO to help deciding what to automate here:

Load More Posts