daily post

A TechBeacon article I wrote giving tips on framework design

Event handlers are a must have in framework design

Especially for UI automation scripts

We’ve talked about UI automation being flaky by nature

There has to be a lot of event handling techniques used to make it smooth

And even with all of that, still things WILL fail

So make sure to have failsafe protocols in place or your complete 24 hours batch run might get screwed

Read the MOST interesting debug story I ever experienced and lessons learned here:

https://techbeacon.com/7-lessons-debugging-test-automation-framework/

More important than learning programming

Tester’s confine thier technical advancement to just automation

That is not the way it should be IMHO

There is a lot more about being ‘technical’ than programming and selenium

Understand how the software works, how the technology stack works,

How to test against the entire stack

Learn to ‘think’ on how to develop algorithms

Develop the aptitude to create troubleshoot problems

#RedefiningSoftwareQuality through #TechnologicalAdvancement

Communicating effectively with clients

Is something we do wrong most of the time

Roots of software quality were taken from TQM

Communicating with a customer on a tangible product easy

Corresponding on something intangible involving lots of people is hard

And most of the time that’s where we go wrong

Groups of the software vendor and groups at the client end are not always on the same page

The infimous requirement diagram we all have seen is illustrates this very well

The same was my finding on a case study I did on project escalation published here:
https://goo.gl/rTnsHA

Lesson:
Be sure to keep the key stake holders on the same page, and try to stick to it.

How does it work?

The first thing to understand, – it’s REALLY EASY

I use an analogy of posting a letter

You write the senders and receivers address on the envelope with the message inside

The post is delivered as per the address

Once received the envelope is opened and message received

HTTP requests (in fact all communication) works the same way

The message is wrapped in an ‘envelope’ with addresses

On receiving, the addresses are removed and message is delivered

More on that process and HTTP messages construction here:

Software programming requires constant learning

The reason why I chose this industry

I studied more about wireless communication than software programming in my engineering

But choosing programming was a deliberate choice

Towards the end of my degree had the chance to visit a BTS installation site

I decided there and then I’ll never choose this field

I’m more interested in creating things, rather than using things designed by someone

I always enjoyed creating things from scratch and make them functional, made me feel accomplished, and to call it mine

Find out what sits well with your personality, it makes all the difference.

#RSQ

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