daily post

Here’s why this question comes up IMHO

For decades testers have known to be ‘Non technical’

They mostly never wanted to do much with the underlying technology

When automation came along (or when it became more popular) folks thought, well these guys know nothing of programming

So this automation thingy might not be real programming, just doing some record playback

In reality, automation is not just programming,

It IS hard core SOFTWARE DEVELOPMENT (when done right)

#TechnologicalExcellence

More here:

A common question I get when reaching out to people

It is human nature to expect something in return for spending time and effort

Over the years I’ve learned the trick in life is not to get, but to give

And the universe will respond back in many times more

But it takes faith and patience to keep going without return

In essence that’s what a business should do, solve people’s problems without trying to squeeze a dollar for every inch they contribute

I’ve always felt, living for something greater than yourself is a life worth living

Credits:
Seth Godin, Susan Jeffers (and many more I cannot recall now)

Few things you should know before going in:

Legacy products need a different approach than most modern tech stack applications

The automation framework has to deal with the various legacy platforms used

This means compatibility with those languages, platforms is essential

In some cases it can be advantageous too, e.g. front ends built with some JQuery or custom components might make things easier

The backend might not be as ‘automation friendly’ since it was never designed for anyone other than the developer to understand

Processes, tools and the team, all would come into play

More insights in this article:
https://goo.gl/B6kEX3

Angular 4 + Spring Boots + SQL..

Configuring an ERP can be VERY problematic

Getting settings the exact way a client has can be tough

There are other ways to do that (e.g. use dockerized environments) but there is the old fashion way too

Set your test environment like your client’s do the tests, revert it back

For applications having lots of configs this can be hard

That’s how we started with creating tester’s “own” test product

It had to be scalable, since there are a lot of things we might add to it

So needed a proper structure, which lead to a full-fledged product, a testing tool with:

Front end: Angular 4
Server side: Spring boots
DB: SQL

More on this in coming weeks..

#TechnologicalExcellence #TechnicalTester #RedefiningSoftwareQuality

Can your brain focus on multiple things at the same time?

In the information economy the people to thrive are who invent

The terms knowledge worker(Peter drucker) and smart creatives (google founders) are common

Yet how much of our time do we spend on thinking deeply?

Shallow activities, just passing the buck around does not create the needed value

At the minimum work with focus and precisely on one thing only

More on the subject: “Deep Work” by Cal Newport

I think you should have the capability

An argument for not using a multiple tools is “Too many cooks spoil the broth”

While this was more valid years ago, now most vendors know there is an inevitable need for integrations

Automation used to be just UI automation, now we have API, DB level checks as well

Distributed teams have caused different team dynamics needing a whole set of reporting and management tooling

Then we have CI / CD in the mix which also would need to be integrated

Case in point, the automation framework must have the capability to support and use multiple tools

#RedefiningSoftwareQuality

More on that here:

Did you know you can parameterize your jobs?

Especially helpful for automation

You can parameterize things like the app version / browser / DB / automation framework parameters from within Jenkins

Scheduled job runs will have default values selected every time they run

For manual job runs you can choose to select options from drop downs

The benefit:

All execution resources / environments management and results are centralized

Setting up new run routines or special case quick runs makes a big difference

And the kicker is the visibility you get from all the results in one place and accessible to all

In the start I thought just to reduce cost, here’s what I’ve learned till now:

– Yes some folks still think to reduce cost; <False> Automation only increases the testing cost

– Substitute testers; <False> Automation cannot substitute tests done by a person

– Increase test coverage; <True> Can rapidly increase features checked

– Provides confidence; <True> Increases the team and the customer’s confidence in the product

– Reduces time to market; <True> Can reduce testing time and supports continuous integration

– Shows commitment to quality; <True> While employing automation does show that, however not a good enough reason in itself

– Can find more bugs; <False> Automation checks ‘stable’ features, ideally it should not find ANY bug..

Care to share other reasons you observed?

#RSQ

I strongly feel they should

Firstly, let’s define technical: “Who knows how the product is designed and works”

Doesn’t mean you have to be an architect, but reasonable understanding how it works

The reason:

80% code of an application is written at the back end, isn’t it logical to spend time testing on that layer?

And without knowing how that works, it cannot be tested..

Toyota had to recall 2.1 million cars on account of a bug

More on that story here:

#RSQ

“Excessive automation was a mistake” , “Humans are underrated” Elon Musk while commenting on Tesla’s production line

Firstly, Shout out to Elon Musk for being so transparent and honest despite his position

To the point. apparently Having too much automation turned out to be a problem..

It’s ahead of its time, the technology is probably still catching up

In this case, it was just adding (a lot) more robots to the assembly line to what already existed

Then how can anyone expect automation in test to be anywhere near testing how a human does

Bottom line, it would be ‘decades’ if EVER, for automation to substantially substitute for a tester (referring to AI as well)

On the flip side, Automation is still needed for a lot of other reasons..

#RSQ