daily post

Developing a tester’s Jarvis

By | May 21st, 2018|daily post|

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

How does continuous testing help?

By | May 20th, 2018|daily post|

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 Magic of Continuous Testing

 

 

Calculating Automation’s ROI

By | May 17th, 2018|daily post|

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

Does Automation Save Money?

#QsArticles #Automation #AutomationRoi #GeneratingBusinessValue

Evolution in software and changing automation landscape

By | May 16th, 2018|daily post|

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

 

Best practices for logging automation results

By | May 15th, 2018|daily post|

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:

Logging automation results – Best practices learned over time

#QsDaily #TheAutomationBlogBook #AutomationInTest

How much documentation is enough?

By | May 14th, 2018|daily post|

From waterfall style having extensive documentation for each SDLC phase till the Extreme programming / SCRUM with very basics like user stories

I must add here, when teams say we’re going ‘Agile’, so don’t need anything except for user stories, that does not make me happy

Too much we run into problems of maintaining them,

Too little, and as soon as one or two key people leave their position, everyone is in trouble

It should be enough to sustain development, and keep the process lean enough

I guess everyone would agree on all the aforementioned, the problem is “Striking the right balance”..

I’d like to propose the following as a yard stick:

– Anyone wishing to understand any part of the code should not have the need to hunt down people to understand. Sufficient commenting and coding practices should be used

– Anyone wishing to learn about how the system should behave in a certain scenario, can find that info without bugging every single developer.

For application domain, one can utilize user stories, gherkin feature files (BDD), mind maps, test cases, client specifications

For code understanding, code documentation, commenting, coding practices, architecture documents

Thoughts?
#QsDaily #RedefiningSoftwareQuality

Starting an automation project

By | May 13th, 2018|daily post|

Make sure to follow the “Pillars of Automation Framework Design”

Unfortunately most teams start with UI automation

Which is the toughest and has the lowest return

Nonetheless it is important, so best to do it right

The 4 Pillars are:

  • Maintainability
  • Reusability
  • Scalability
  • Robustness

Description of those here:

Pillars of Automation Framework Design

#TheAutomationBlogBook #TestAutomation

Our most important asset?

By | May 12th, 2018|daily post|

It’s one which is most scarce – TIME – and the successful know that

It cannot be created or borrowed

Every person has 24 hours, and once they pass, they will NEVER RETURN

The trick is utilize your time in the best possible place you can

Ideally we should do stuff only which we MUST do ourselves

DELEGATE anything else that can be done by someone else

This will take disciple, planning and a burning desire to head towards your goals

PS.
This is important for testers and software development teams too

References:
“The art of self-discipline” by Brian Tracy
“The Millionaire booklet” by Grant Cardone

Automation experts over the years

By | May 11th, 2018|daily post|

A #QsEpisode in which @Jim Hazen shares names of few automation experts over the years

I was familiar with most recent ones, but folks from back in the day I did not know of

Quite a few people have been contributing over the past many yers

Teaching tricks of the trade and their experiences

You either learn by experiencing it yourself or by learning from someone elses experience

It’s best not to reinvent the wheel and learn from those who have seen it before

Here’s the segment of the talk around this topic:

P.S.
This is not a conclusive list. Just few names recalled at that time.