Daily Posts

And it’s not because learning it is hard..

It’s mainly because keeping up with constant troubleshooting is hard

You need to learn to feel ‘comfortable’ troubleshooting, learning, evolving

Once you solve a problem, you don’t get that problem again since the machine now solves it for you

You then move on to the next problem

So this is a never ending cycle of solving problems of different kinds

If you build the temperament for it, it can be very exciting too

More on learning to program specially for testers:

The way we use words affects the way we think

In the testing community we unintentionally miscommunicate certain things

A prime example is Test Automation

The word suggests testing is being automated, however ‘testing’ is a thinking and reflecting process which our script do not do

We all know test automation does not mean automating testing

But sometimes we do forget this and succumb to what the word literally means

More on that here:

Because ‘Perception’ IS ‘Reality’..

And automation can play a BIG role in that

Something reinforced by Oren Rubin in the Automation Guild 2018

Assuring basic features are working fine through scripts goes a long way in building that confidence

It also provides a comfort level to customers of the product’s quality

Knowing that each release has these basic tests checked makes a difference

Planning testing of the product also becomes easier

If you’re not using automation for product, something to think about

#RSQ

Any ideas why ‘MOST’ UI scripts are flaky..

Inherently UI automation is flaky, I’ll give you that.

Lots of moving parts and rapid pace of change

However the major reason is not that, it’s going in without learning and planning

UI automation can be very stable if the right approach is used

Managing code complexity

Following framework design pillars

Test data management and some more tips:

Any different from dev teams?

Automation is pretty much like developing software

And should ‘EXACLTY’ be treated like a dev project

Therefore shouldn’t be much of a difference, also having synergies with dev is a good idea

Especially if they are have a decent SCM (Source Control Management) system

Although best to have separate repos (no brainer)

Importantly look out for CI tools integrations

Even if you are not planning CI right now, you will (and must) in the future

Tool selection is not as important as it is to design your SCM process

Even with a great tool a foolish process can make things pretty hard

#RSQ

From the lens of an automation architect

The front end is in some ways easy and hard to automate

Synchronization can be a problem but object identification can get easier

API automation can be a challenge, since they are not designed to be consumed for folks other than developers

Dev and test environment creation can be old school, that means creating and tearing them down is hard

More points under each of these areas can be explored here:

http://quality-spectrum.com/legacy-products-automation-technology-challenges/

Is a response within 24 hours acceptable?

It used to be a response within 24 hours is good enough to any email

With the rise of social media platforms and instant messaging, it is expected to be responsive all the time

Some people pride on their capability to respond within few hours any time of the day (night)

This habit can be detrimental to ‘Deep thinking’, which is what essentially we are paid to do

A human brain can focus only on one thing at a time in order to ‘think deep’

Also there is a switching cost from one task to the other. It’s not like flipping a switch

Going back and forth between different things can make you feel more exhausted

And ‘reduce’ your productivity since you’d not be able to hit the ‘deep thinking’ zone on 2x to 10x your mental capacity

I feel a ‘within’ 24 hours response from a ‘select few’ contacts on important conversations

And an ‘whenever possible’ response on communication from other contacts and non-important topics should be the expectation

Try spending more time daily thinking deep and less switching and doing shallow stuff

Lessons from “Deep Work” – Cal Newport

And it happens to be your old nemesis?

Around me I see people starting programming the wrong way

They start with a lot of new things to learn the same time

Complex IDEs, complex languages, configurations, advanced concepts..

Handling all these things the same time is not a smart move

The basics to learn programming IMHO has to do with algorithm design

Apptitude to think how to give instructions to a dumb machine

For those starting this journey, my two cents on where to start

Develop the right aptitude and attitude:

A question from the Automation Guild 2018

Install selenium and write tests for all screens – NO!

That can be a start, but not the plan on how to approach this

Not everything can be assessed completely sitting at the client side

Also, automating scenarios on the back end layers is more easier and effective

You would want to check all moving parts in separately

Wisdom from the ‘Automation Pyramid’

More here:

#RSQ

And is therefore very easy to install, configure and backup..

Java being platform independent, makes running Jenkins a lot easier

However some folks do get stuck setting up Java the first time

Installing the JDK (Java Development Kit) can turn into a painful process

An easy way is to install ‘Chocolately’ – A software packaging manager

In layman terms, makes ‘packages’ installation a lot easier

All you have to do is run simple windows batch commands, and it does the download, install and windows configuration for you

More on that and background on Jenkins installation here:

#RSQ

Am I the only one to feel the word ‘tester’ is synonymous to ‘being non-technical’?

Many testers are just basic users of technology

And feel no obligation in learning the magic happening behind the scene

Testing software is not like quality control for flip flops

The complexity and its impact on people’s lives requires a tester to know how the software is working

And test across the technology stack according to the architecture

That does not mean you need to be ‘Elon Musk’ type technical,

But you should know the control flow of data from the front end into the DB and back in front of the user

I have a few theories on how testers traditionally thought to be ‘absolved’ of being technical, which is for a later discussion

But one of my values I stand for is ‘Technological Advancement’

One of the three aspects that would distinguish the ‘Next generation tester’

#RedefiningSoftwareQuality

Follow the ‘decision making process’

One of the most valuable things I learned in my MBA – ‘The decision making criteria’

This is a real short synopsis which might make no sense right now, I’ll write something in detail later on

1. Identify goals and objectives – Gauge product quality, increase delivery speed, build confidence

2. Decision making criteria – Maintainability, Reusability, Scalability and Robustness

3. Core problem – E.g. Not able to increase code coverage quickly

4. Alternatives – E.g. Ready API, RestAssured, Postman, ‘quick; automation UI tools e.g. TestComplete, UFT’

5. Evaluate all alternatives with merits – Pros and Cons for each

6. Select as per decision criteria – Which tool will help to increase coverage quickly while the decision criteria (point 3) is also met

7. Implement – Track implementation progress and impact for analysis

8. Evaluate results – Retrospect

Credit: To one of my Guru’s at my business school, Prof. Fareedy.

#RedefiningSoftwareQuality #RSQ

“Automation is not finding bugs” a question I got,

My answer – “Is automation supposed to capture bugs?”

“I speak clearly, I think clearly” Michael Bolton..

Since often we call it Test Automation, the assumption is this ‘testing’ should report bugs

In reality automation is not ‘testing’, it’s ‘checking’, therefore it will not always capture bugs

However, automation does free up tester’s time to do more testing and capture bugs

The bug capturing will be done by tester’s for the most part, not automated scripts

Not to say automation will not capture bugs at all,

Rather, it should occasionally capture issues and provide confidence in our application’s stability

More on this plus about data generation for automation here:

A manager’s comments to a team member – I happen to agree with

I usually keep leaves till the very end for a rainy day

And mostly would end up having quite a few unused leaves

To be honest I avoided any time off for vacations

Or take a leave when I needed, would instead try to adjust within my work day

Knowing this was not the right thing to do, but still for some reason acted that way

I did appreciate the encouragement on utilizing leaves and not keeping them from the end

A human brain cannot function on the same pace without a break

Our cognitive abilities and concentration capability depletes and needs replenishment

So take time off guys wherever it’s due.

By doing that, you are actually doing your ‘work’ a favor!

The first step is NOT installing Selenium – IMHO

Learning Selenium with Java is not all there is about automation (nor the best place to start)

Importantly, what you might be looking for is ‘to be technical’

And learning programming with Java and TestNG does not make you technical

A person who knows how software works, how the technology stack works, basics of programming is more technical

You don’t want to be an automation engineer first, you want to be technically equip first

Then move your way up to learning the tools

#RSQ

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