alikhalid

“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

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

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:

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

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

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: