Before answering that, I suggest thinking about ‘what to test’
For those managing automation this question comes early on
The usual answer is automate things that are ‘automatable’
And the same was my thought years ago
Over time I’ve realized we should talk about ‘what to test’ first
If this super set is not correct, actions following this would not be as effective
In this video I talk about 4 things to find out what’s ‘important’ to test
#WhatToAutomate #RSQ
But the architectural change happening near the end should not
Prioritizing fixes across sprints has more to it than meets the eye
The same holds true for changes in automation frameworks
Wide impact changes in the code should be made with significant time ahead to react
Also not to make a series of major changes at once, divide in smaller parts and test it out
For automation frameworks, I try to break an architectural change in chunks and run tests before the next piece
This way it’s easier to debug and fix, plus less painful and daunting to do
More here:
#RSQ
What matters more for automation positions?
Aptitude certainly has value and importance
Unless someone has, what I call, the ‘aptitude for algorithm development’, things would be difficult
However more than often, having or creating that aptitude is not as hard
What’s less common and more important is the attitude
A lacking aptitude can be compensated by a fired up attitude
However, “If there is ‘NO’ will, there is ‘NO’ way”
A person is three times more likely to be dropped based on attitude than aptitude
I must mention, the attitude needed for each job might not be the same
So, just a ‘can do’ attitude might not always sum it up
Build the right attitude, the aptitude will come about on its own.
Do you have multiple scripts for each environment / browser type?
The page URLs can change for each environment / browser
Or in some cases ID’s might also change on certain variables
Not saying this is a good implementation style, however it can be handled for UI automation
You can create project variables specifying the environment, browser or any other affecting variables
Set the variables at the start of project initialization and make them accessible to all classes / methods / functions
The trick is figuring out the pattern of how objects / pages are changing and incorporating that in your framework
Easy to do if you have a framework built around the tool(s)
#RedefiningSoftwareQuality #RSQ
ABSOLUTELY NOT.. Here’s why:
There is a lot of logic you have to create which the tool (or libraries) are lacking
All that effort is to some extend covered by vendor based tools
When you calculate the cost of creating those libraries and the upfront cost of some vendor based tools the math does not add up.
The upfront license cost might be just a one month salary worth of the engineer
And if you don’t have a seasoned person, creating those common routines are certainly going to take more than a month
This does not mean you should buy vendor based tools only..
Don’t go for open source just for the cost.. There are other factors which are more important..
More here:
https://lnkd.in/fCj8Zqi
#RSQ
The “Metric black hole” – from “Deep Work” by Newport
Have you seen testing team metrices which don’t feel right?
In pursuit of getting some form of ‘quantitative measure’, sometimes teams end up with non-productive metrices
Like the “Number of bugs captured” during a sprint
The underlying problem is – getting a matrix to gauge productivity of ‘knowledge workers’ is very hard
Specially in certain fields like testing
I also certainly agree with having quantitative measures,
In fact – That’s why one of my values is ‘Generating business Value’
But it should not be at the expense of creating ‘non-effective measures’
More on that here:
https://pos.li/296dds
#RSQ
I very much dislike the traditional blog style
Categorizing posts by timeline or tags might have been helpful
But whenever I am visiting a new blog, It’s impossible to make sense of things
There is no certain theme, to me feels more like a scrap book
That’s when I thought of having a ‘Blog book’ –
Resembling to a book for having a certain rhythm for the reader
Or at least a Table of Contents giving an idea of the different topics
An in time hoping to make it a great book to read..
“The Automation Blog Book” – #TABB:
https://lnkd.in/fsrwK_r
Why does it not work the first time?
This can easily become a long and inconclusive research
So let’s narrow down to Automation frameworks for UI side
Firstly, keep your code complexity low, once it passes a certain threshold, it’s INCURABLE (I can go on a rant on this for hours)..
Secondly, don’t just rush to change the first thing that comes to your mind,
Take the time for listing all possible variables that this method affects
Now assuming you are good with thinking of algorithms, script a draft change
If not good at algorithm design, write pseudo code first, then script
Thirdly – Be certain there is a flaw whenever you do a change
Therefore think of what to check before you do the code change and test your code change
Lastly and most importantly – Framework level changes can screw you up big time,
It’s better to invest in planning for these changes, every minute spent planning will save hours debugging
Then I make these changes in separately checked out projects and run the batch with the change before I push it to the master branch
Happy Debugging! Or fake at being happy, whatever works..
The beauty is its simplicity in setting it up and configuration
Common stages you might have:
– Trigger the process
– Compile / build
– Environment setup / Deploy
– Run tests / Package
– Move to the next stage
Plugins for integrations and Agent nodes for executing on other environments make it so powerful
A short history, the main components and features are summed up here:
One of the most popular CI tools
Was created in 2004 by the name Hudson, over time and disputes changed to Jenkins
Wait for object, Find object, Action on object – Repeat
If any of these are weak, getting a robust framework is impossible
Delays –
I have a rule in my teams
There has to be a dynamic delay before each object
And in some cases, a dynamic delay after specific actions (like saving a record)
Finding objects –
One of the most fragile part
That’s why it’s the most important one
No single kill definition, find what works best for your application
Action on object –
Easier than the first two, but as important as nonetheless
One of the main causes why some scenarios are ‘not automatable’
#RedefiningSoftwareQuality
