daily post

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

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

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

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

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

“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

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:
5. 1. java -jar jenkins-cli.jar -s       <Jenkins server>     delete-builds     <job name>              <build number to delete>
6. 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

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

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

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