Strongly typed vs loosely typed languages
What is it and what’s the difference
Some programming languages have more checks at the compile time (while building the code), and have checks on method calling, data types, return types and so on
In short you cannot ‘loosely’ use variable types and change them on the go
Examples of such languages would be Java and C#, each variable must be declared with a specific datatype
The opposite off course is loosely typed, where there are no such checks on the compile time
A major reason for that is some languages don’t have to be ‘compiled’ to build code
Never give up
You are defeated only when you give up
I always give an example of a little kid and a wrestler
If the kid keeps coming back to fight, no matter what happens, or how long it takes, eventually he will win
Persistence and being tenacious are fine qualities
A quality of ‘Winners’
In the words of the Great Muhammad Ali:
“I don’t count my sit-ups; I only start counting when it starts hurting because they’re the only ones that count.”
As he said, ‘float like a butterfly and sting like a bee’
While learning automation, I feel it’s important to learn:
What is programming?
While there are many metaphors people give, most cannot fit 100%
I am too confused (was confused) how to define programming
A LOT of people just run away from learning to code
One reason is, IMHO, we don’t necessarily teach it in the best way
And a good place to start it, what is programming?
The best answer I found is:
It’s like writing, you take an idea in your head and you write it down
Similarly, in programming you think of an algorithm and write it down
If we broaden this definition, I even call playing Real Time Strategy games ‘programming’
Sure, you’re not writing code, but you are thinking of an ‘algorithm’ to beat another person or ‘algorithm’ (Computer as a player)
A link to a GREAT video I watched on the subject (added in the links)
Automation batch issues
Passes individually but fails in the batch..
This would be an all too common for anyone who has worked in automation
While the reasons for this can be ‘infinite’, here are some common ones I’ve observed on top of my head:
– Dependent test data. When running individually no other script can change the data, in a batch run that is a possibility
– Tool / browser reset. If the previous script failed, the browser was still in error state and the next script starts executing, resulting in failure
– Delay. Browser response time can change when running in a batch, must have dynamic delays before interacting with EVERY object
– Application down. While this might seem a remote possibility, in some cases this does happen in very sbtle ways.
Any other ‘very common’ factor you have noticed?
A key ingredient in my observation for evolution in technology:
A standard platform, here’s why
When a new technology emerges, it takes more than a few people to evolve it
A very large group of people collectively working with it helps in pushing boundaries
Take the PC for example, having a standardized OS on PC (Windows) was one of the main causes that fueled advancement in software development
On the other and, embedded devices (IoT) has been out there around since the PC, but we are far behind there
Embedded platforms were very fragmented and challenging to develop, therefore layers of abstraction were not built there as rapidly
Only in recent years we have seen things like Raspberry pi and so on
The same would go for automation, having a standard platform and building layers of abstraction on top of it would make the difference
#QsDaily #platforms #automation
Community building, the reason why humanity survived
And a core factor in any idea’s success.
One person alone is weak and fragile compared to other species walking the earth
But one of the reason why we went from the bottom of the food chain to the top is community building
For any idea to gain success, there must be a community around it.
And make no mistake, there is an idea / story behind everything,
Every product, every service and every person is telling a story (weather they know it or not)
So, if you are building a product, build a ‘tribe’ around the idea your product serves
Or whatever you are willing to accomplish, the idea should be worthwhile for at least a few select people
Then build a tribe around it.
Reference “Tribe” by Seth Godin
#QsDaily #community #tribe
My favorite interview question and answer:
Q: “How do you define leadership”? Ans:
“Leading by example”
This was asked to me when I was interviewing for my current role
I always felt a leader was the one who sacrificed his wishes and wants for his/her tribe
Probably why Simon Sinek’s book: “Leaders eat last” resonated with me so much
I was reminded of this answer yesterday when Tom Bilyeu asked LeVar Burton the same question,
His answer: the EXACT same words I gave my ‘to be’ manager 4 years ago ‘Leading by example’
And BTW, you don’t need to have a ‘lead’/’manager’ title to be a leader
‘Genuinely’ help solve people’s problems, the law of reciprocity will make you a leader
Most leaders in history were a ‘leader’ long before they ever got the ‘title’.
#QsDaily #leadership #interviews #LeadByExample #inspiration #hiring
LeVar Burton video:
Step 1: Install Selenium and implement POM? ABSOLUTELY NOT..
Step 1: Un-learn the crap which is holding you back
Step 2: Learn how software works
Step 3: Lean how to develop algorithms
Step 4: Understand what automation’s goal is and what to achieve from it
Step 5: Install the tool, libraries etc..
Step 6: Take algorithms from Pseudo code to actual running code
Step 7: Develop a simple and messy framework
Step 8: Learn programming best practices
Step 9: Revamp the framework and script a neat one
I know this might be longer and not as easy, but IMHO the right way to do it
I’d rather spend TWICE the time on WHY than on HOW
#QsDaily #automation #learning
How to manage your code for different UI?
Our automation is reaching yet another level of complexity hence the question..
Elaborating the question:
If we have an application with different versions we support
And there are UI differences across versions (off course), which means different automation code needed,
How to structure your automation code base?
Now off course it would depend on the kind of changes we are seeing.
Here are a few strategies I’ve used / seen / read aboout:
1. Automation code residing alongside production code, in the same repo (@Angie Jones).
– Sounds awesome, never used it. But Angie says it works so I will surely take her word for it!
2. Separate code branches for different versions.
– E.g. for product version 1.0, 2.0 & 3.0, automation code base with a trunk and branches: 1.0, 2.0 and 3.0
– I’ve seen this for prod code, it can get messy, but works
3. Conditions / variables within same branch
– Have conditions within the framework, data selection and POM classes to run based on app version
– I don’t like this. should work in few cases. But things can get out of control fairly quickly and become WAY complex.
Any other ideas you might have?
#QsDaily #automation #branching
From add on the fly, to using random data to saving seed data in DB (Link to the story in first comment)
After using seed data which resides in a baseline DB and restoring it when needed,
Now we’ve moved on to the next problem:
How to add data to ‘Six’ baselines, that’s right, one test which has to run on 6 different environments needs the same seed data
We have been adding seed data manually, but for 6 it’s not going to be easy
Since it does not have to be created just 6 times, but every time before we create the seed data on baseline, we test it by creating on the ‘restoring’ DB,
So the number jumps to ’12’ times
The few options we talked about to help with this:
– Use UI scripts to create seed data (for data which is simple)
– Improve the API automation and use it to create seed data, just like UI above
– Finally (which I don’t want to do AT ALL), create data to the DB directly
The last option has many problems, schema across versions is not the same, data creation is not the same, existing data might not be exactly same either..
The brainstorming is going on, but an interesting challenge to have.
#QsDaily #Automation #testdata
With Rocky motivation..
The two week long Philly visit ended few days ago.
And like each year, did the ‘Rocky thing’ again.
What fascinates me the most about Rocky is persistence.
No one can compete with sheer hard work and persistence
And there is no substitute for it,
No short cuts, no hacks, tricks, jacks, inside edges, cutting corners,
Plain and simple hard work and persistence will ALWAYS take the day.
Because it tells the God / the universe you are willing and ready to pay the price.
And you are granted success.
(Photo: At the rocky stairs, Philadelphia)
Now you know what a ‘Unicorn’ employee is (See previous two posts)
What to do about it…
– If you have a Unicorn on your team or someone who has the potential to become one
– Go out of the way to take care of their interests
– That’s what happens in sports, extraodrinaty talent is paid extraordinarily, and have an extraordinary impact on results
– So the extra mile you go will get returned back many folds
– If you don’t have unicorns (or any) on your team, you are far away from success
– This is the information economy, you can’t muscle your way to success anymore
– If you are a unicorn, know your value
– You should not be working for anything less than ‘changing the world’, and be treated as such
– If you are not a unicorn yet
– Put in the effort to become one, it will be all the worth while
If you guessed unicorn’s don’t exist, well that’s true, but..
Unicorn employees DO exist, and here’s (IMHO) who they are:
0. Attitude – This is a given (hence point 0)
– If this is not understood already, then we have a big problem
1. Technical skills – Skills that will do today’s job.
– They know (or potential to learn) the tool, language, platform you want them to work on.
– Have demonstrated competence in similar areas.
2. The Architect mindset – They don’t think about JUST the current problem
– When developing solutions they solve problem they foresee in coming years.
These two skills are hard to find, now let’s move on..
3. Communication – They talk like a marketing / sales pro
– Can communicate their point of view effectively and are good listeners
– They are social and pros at building relationships
A good software engineer who communicates well is like a singing tree, you don’t see them very often..
4. Leadership – Not a manager, a leader
– Can inspire, instill purpose and drive in their team
– Develop ‘psychological safety’
Now THAT is a unicorn!
Mostly ideal candidates don’t know how to sell themselves, and the ‘not so ideal’ ones sometimes know exactly how to..
Ideal candidates are good with technical skills, they know the’re stuff and are passionate about it
Since they spend more time polishing their skill, might not be as great communicators or leaders
Hence don’t know how to sell, and are difficult to find and persuade
Not so ideal ones lack technical skills, and sometimes make it up by being good at selling
They know how to up-sell and might be good communicators as well
They come up easily in the net, but can be hard to fish out,
And, IMHO, can be equally destructive for your team
So the trick I use is to stick to the few fundamental traits/skills only, and do not compromise on them.
Tomorrow I’ll talk about the candidates I call ‘unicorns’. Want to guess..?
Small code changes at the 11th hour?
It’s always a very tricky question, but here’s how I handled it
There were some fundamental changes we were working on for our UI automation project
We were not able to get to the changes in time and release time was upon us
Despite the very urgent need to check in those changes, we holded off
The dates were changed a few times but still we didn’t try to ‘sneak in’ the change
Deciding against releasing a featue is surely more stressful than this case,
But the fundamentals are the same.
I talk more about this in the linked article:
#QsDaily #Automation #ReleaseWisdom
How to do Compatibility Testing?
Wrong question, first let’s talk WHY compatibility testing.
We all know it’s meant to test our AUT’s UI on different front-end platforms (browsers, devices, OS etc.)
But it’s paramount to understand what creates the difference when running on different platforms
Let’s take a web app running on a browser for example,
It would help to understand the different components of a ‘browser’ and what portions are different
Each browser has a different ‘driver’, e.g. Chrome uses the Gecko driver.
I’ve seen compatibility tests meaning “Run ALL tests on each device / combination)
The rest will be the same on every browser
#QsDaily #Automation #CompatibilityTesting #Testing
Jenkins benefits even if you are not using a CI process,
Having the collective results in one place has a lot of advantages
Can get results from different tools (might be using separate ones for UI, API and unit level) in one place
Even for one tool, having all parallel runs in one place is a big blessing
Secondly can have a combined history of all the results (in Junit format used by Jenkins by default)
Thirdly, it allows for parallelization to your tests
To scale your automation, this is going to be a must
Number Four: One can centrally control the automation execution resources from one place
Having parameterization will make things even more easier
Evolution in automation didn’t start just few years ago.
It’s been around for decades and here’s a crude synopsis:
> 1980’s: computers found their way into businesses.
> 1985: First wave of automation tools started.
> 1990’s – Advent of GUI bases OS like Windows 3.0, UI based automation tools start to pop up.
> 1995 onwards: In the race to dominate the UI automation market, eventually WinRunner dominated.
> Around 2000: New technologies like Java jump in; web takes off. New paradigm shift, from desktop to web.
> Around 2004: First version of Selenium RC introduced.
> Around 2005: WinRunner becomes QTP after the acquisition by HP.
> Web has built a lot of momentum, big push to support web UI automation started.
> 2007: Selenium Webdriver’s first version launched.
> 2007 – 2008: iOS v1.0.x released, Android v1.0 released, Mobile is born.
> 2008: Cucumber is introduced.
> 2009: Mike Cohn introduces the Automation Pyramid.
> 2014: Appium v1.0 is launched.
> Meanwhile mobile has taken off, cloud computing is picking momentum and CI/CD is spreading in the backdrop.
> 2016: Jenkins 2.0 released.
> 2018: Docker CE is launched.
* Dates are BALLPARK VALUES, just to give a crude timeline
hashtag#QsDaily hashtag#Automation hashtag#HistoryofAutomation
Automation ROI calculation
It’s not about calculating man hours saved
While automation has a lot of benefits,
Equating time spent by a tester to a machine running the test is not accurate.
Most people (including myself in the past) calculate automation ROI by man hours saved
Automation is provides only data points, they do not necessarily mean a failure.
A person has to interpret the data and conclude if we have a failure.
But then how does automation benefit us?
Some high level points in the linked article:
#QsDaily #Automation #ROI
How to learn API automation?
I’d follow the following steps:
Don’t start with instaling an API automation tool
Do NOT START with installing an API automation tool, learn what are API’s first then think about tools.
Understanding how APIs / the HTTP request / response works. Lots of tutorials out there.
A video covering the basics linked in the comments.
Test some sample APIs with POSTMAN.
That would give you an idea of how API calls are constructed and some common responses
You can try using this website as a sample:
Look into learning RestAssured.
There are a bunch of courses out there on it. It can work in parallel with Selenium.
All you need to do is just add the Maven dependency –
I’m using RestAssured with spring Boots!
#QsDaily #ApiAutomation #Automation #API
TestAutomation != Ui_AutomationOnly;
AutomationInTest == UI_Automation + API_Automation + UnitTests + WhateverYouCanComeUpWith; // This can be a long list
Any mundane test programmed to be checked through a tool would classify under automation
Since UI automation is the most widely implemented form of automation, it has become synonymous with automation
API automation is very valuable and should come directly under an automation engineer’s core responsibilities
Often since we start off ‘not as aware’ about the technology stack, we’re not really sure how API testing is done
Linked article stacks up UI vs API automation to illustrate the benefits.
#QsDaily #ApiAutomation #UiAutomation #Automation
Configurability and complexity go hand in hand
Thanks to Thomas J McCabe for proving this concept
I have to say, over time things do get streamlines when layers upon layers of abstraction are added
But while developing a product, or automation framework, the more configurable we try to make it, the more complex it becomes
For that reason, Thomas McCabe came up with this algorithm to calculate complexity
Embedded / IoT devices standards dictate to keep the McCabe cyclomatic complexity (Code complexity) below 30
It’s not a bad idea to calculate your code’s complexity level and stick to a limit
Makes life a lot easier down the road.
#QsDaily #Automation #CodeComplexity
Want to learn or hire for automation?
“To be technical or not to be, that is the question”..
While speaking at a conference I tried to outline the journey of a tester
While there were a lot of lessons to learn, the premise was to focus on learning the underlying technology
Familiarity with just an automation tool will not bring the results you want, for both, as an employer or as an employee
What you really are looking for is a technical background AND be able to program tests at the same time
#QsDaily #TestersGoingTechnical #Automation
DevOps and Tenacity
Here’s the relationship..
The differential between the good and the great is Tenacity
The great know to hashtag#NeverBackDown / hashtag#NeverGiveIn, and that’s what makes them great
Success consists of going from failure to failure without loss of enthusiasm (Winston Churchil)
In delivering software there are a lot of unknowns, many things can go wrong, and you’ll never get it right the first few times
So, keep on improving and at an accelerating speed. For which you and your team must be tenacious
And to me that’s what DevOps is, keep improving at speed, keep going from failure to failure without loss of enthusiasm, or simply put ‘fail fast’
#QsDaily #NeverBackDown #DevOps #FailFast
I’m often asked how to learn automation
On of the most important skill is programming..
Firstly, often times this subject is not approached the right way
Folks attempt at ‘codeless’ or ‘keyword based’ automation at first
IMHO, while it might work for a finite scope and technology stack, generally it’s seen not to deliver
In the end, to do automation well you’ll have to program. there is no way around it
Secondly, learning programming is not about being good with Java or any one language’s syntax
It’s about building the right APTITUDE and the right ATTITUDE
With those two, the language becomes irrelevant. And without them your skill in any language will not create desired results
#QsDaily #Automation #Programming #TestersGoingTechnical