daily post

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

Well, it does and does not.. Let me explain

By testing ‘just’ the API, yes some checks programmed for the client side will get skipped

However, API automation is not to ‘replcae’ UI automation

It is supposed to work in ‘conjuction’ with UI automation

And not only UI, but in coordination with unit tests as well

Therefore, if we look at just API / service layer tests only, then we do loose areas to test

But when working in conjunction with UI and Unit tests, (the way it should), then we don’t forego any code from being tested

#QsDaily #UiAutomation #ApiAutomation

References:

https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

There are some ‘dumb’ routine tasks we have to do as a tester

Not all of them require a signifanct amount of intelligence and can be done automatically

And I’m not talking about checking as in testing something, rather activities other than actual testing

Some AUT upkeep tasks like configuration updates, checking installations, maintaining environments, compying stuff from one place to another

Having a single tool to do all of these things might be an overkill in the start

But certainly can prepare a bunch of smaller programs for routine tasks and controlled from one place (Jenkins..?)

Call it a stripped down dumb version of Jarvis if you will..

I know @Alan Richardson has talked about something similar

Care to share something you are using along those lines?

#QsDaily #Jarvis

For sure it does NOT save cost upfront at least..

Implementing a DevOps culture and integrating Continuous testing in that will take some effort

A cultural shift will be needed and breaking down of dev / QA silos

Now to the benefits, most importantly provides quick feedback

Coding a feature incorrectly and then fixing it afterwards takes considerable effort

A lot of communication back and forth not to mention time spent regressing around changes

And some times issues are not found until the 11th hour, which is another Pandora’s box

For me the greatest benefit of continuous testing is preventing as many issues from being pushed in the first place

I created an illustration showing this phenomenon of continuous testing avoiding the pile up of issues over time

The article and video can be accessed here:

#ContinuousTesting #Automation #QsDaily #QsArticles

The complete discussion here:

https://lnkd.in/fVfJmV4

#TestAutomation #QsEpisodes

Is it just a number game in terms of man hours?

Mostly that’s how these ‘savings’ are calculated

The reality is quite different IMHO

Equating man hours to execution time by a machine is not accurate

The way a person would test is a lot different, even if they follow a written test case

Equating apples with oranges does not give a true picture,

Well then how does automation help?

Here’s what I think..

#QsArticles #Automation #AutomationRoi #GeneratingBusinessValue

A segment from the talk with Jim Hazen:

Many times we stumble upon a problem and think, hmm seems no one ever had this before

Especially with automation, we probably have reinvented the wheel quite a few times

Going through the entire history of automation evolution would be very lenghty,

This episode talks about some main events and how automation tools, practices chnaged over the years

Very fascinating and interesting subject, here’s the video link:

#QsEpisodes #TestAutomation #AutomationHistory

Here’s what I have learned over the years:

Firstly the test log is not for automation folks only,

Primarily for the whole product team to consume

Plus automation folks would like to help it in their debugging also

Keeping thwese audiences in mind, following should be a part of your log:

– A good heirarchical stucture resembling the test scenarios used for regression
– Lots of debug information indended within the report
– Some info on failures we know are reported issues
– And finally best to have it in a centralized location, Jenkins would be best

More on that here:

#QsDaily #TheAutomationBlogBook #AutomationInTest