Daily Posts

Which to focus more on..

UI automation is the first place most automation efforts start from

However, the products we are working with have most of the code written at the back end

While the front end has just a small amount of code we have added, all our testing efforts are focused there

With API / Web services automation, one can cover more code coverage

Besides, UI automation is comparatively time intensive, fragile and slow to execute

More on that here:

#RSQ

After a long day of shopping, while me and my wallet were perspiring and thinking about testing, here’s what we feel:

Shopping considerations – function, fashion and price

The same goes for testing

Function – We need to be sure it does what it’s intended to do

Fashion – The design must feel right, sits well with the users

Price – The cost should justify the effort. Spending lots of effort on testing something trivial every release might not be wise

So next time when testing a feature, think of it as going shopping

P.S.

To make the response homogeneous, imagine a shopping day with the family than just yourself.. 🙂

Perception of programming Vs Reality

The “journey of a technical tester” walking through his experiences and what he learned:

Summary:

Complete video:

Off course..

There is the argument against writing ‘typical’ test cases altogether

Regardless of where you are on that spectrum, steps to automate in a check need to be precise

And what we are automating is as important as how we automate it

Running automated checks itself is not the purpose

Rather facilitate testers by running 1 – “mundane” but 2 – “Necessary” checks,

So they can test more important features while the dumb work is done by a machine

Without carefully thought checks / tests, will be hard to achieve this

More on that here:

While some tools might have been ‘unfair’ over the years, that’s not the main problem

The main problem with automation I see is, “we don’t know the best way to approach it”

There are a few variables to analyze before you can decide the best way to do it

And generally tool vendors don’t (and probably can’t do) that job for you

While ‘some’ tools have exploited the market IMHO, it’s not just all them

We as a community are still evolving in this department

While a large part of the community is still confused with the OBJECTIVE of automation..

Kinda hard to be successful under such conditions..

Thoughts?

Short answer, yes. Long answer:

Firstly, learning programming is not as difficult as expected

Usually people just follow the wrong approach

That’s why I talk about developing the aptitude for algorithm design

Secondly, there are solutions out there recommending automation tools requiring no coding skills

These ‘Scriptless’ automation or keyword automation tools are not ‘sustainable’ and don’t work in the long run

Therefore one needs to learn programming and how to code well

Thirdly, IMHO testers should be ‘Technical’, without knowing what’s going on under the hood, they cannot test well

If you are capable of grasping that much, then learning programming would not be a problem

These topics were discussed in the #PSQC18 conference talk I gave:

#RedefiningSoftwareQuality

Henry ford and his V8 engine

Ford designed and rolled out 4 cylinder and a 6 cylinder cars back in 1909 and 1928

Both were great feats in itself, and not the only ones Ford had earned by that time..

Still he was not done yet.

He knew having more cylinders in the engine would allow for great performance benefits

His team of engineers worked on it for years, keep coming back to him saying it was ‘impossible’ to achieve

After years of pouring in finances and persisting, finally the impossible happened

Our sixth sense is a magnificent gift, one has to wonder how did Ford know this was going to work

But to trust your gut and keep persisting, that is how you truly get success.

So my fellow testers, let’s strive for ‘Technological Excellence”

#RedefiningSoftwareQuality

Someimtes folks look at this from the wrong perspective

Instead of looking at what is ‘supposed’ to be automated, they look at what ‘can’ be automated

Not to say try automating stuff which does not justify the effort

But the master set should be out of what we are supposed to test, and then find a subset of tests which can use automation effectively

I suggest 4 points to determine this subset:

Either you have or don’t and it’s not a one time thing

Very few ‘might’ have this from childhood

But many acquire it over time and with practice

Excellence can be a potent driving force behind software quality

Once a culture of excellence is established, then the ride becomes a lot more fun

#RSQ

Can we learn something for Sherlock on how to debug UI automation problems?

There are commonalities between debugging and a crime scene

Both have a couple of unknowns we have to find answers to

With the exception of a murderer trying to clean his tracks..

But debugging complex code bases can be somewhat similar too, in terms of the unknowns

The first thing to learn is study data that is available instead of jumping directly into reproducing the problem

Most often we don’t have enough data (or understanding) which is a situation we should not have in the first place

By analyzing data we can arrive at a very precise reason why there is a failure

Which, in turn, helps us solve the problem in the first or second debug attempt

If not, then the good old ‘buck shot’ method hoping to luckily stumble over the problem is attempted (we are all very familiar with)

For more lessons from Sherlock:

Unfortunately were inherited from TQM (Total Quality Management)

We did (try) to tweak those concepts to adjust for software,

However looking back at the path we took, I strongly feel it was not the right one

We are nowhere near the results TQM had in manufacturing

We can’t quantify the quality of a product nor can we measure the impact of testing as accurately

IMHO this has lead the testing community to be a silent spectator in the tech industry

A corner stone to our success would be to quantify the results of testing efforts

There are pockets of folks thinking and working towards it,

But the momentum and impact we need is not there yet.

So let’s begin #RedefiningSoftwareQuality through providing #BusinessValue

My teeny contribution towards this cause:

www.quality-spectrum.com

What changes in a micro service application and how to test that change

Micro-services are where we divide the one big ‘monolithic’ application into multiple specialized applications called micro services

The first change is distribution of functions, module level testing becomes easier, can verify each micro-serice in isolation

Second, verify the orchestration part. New micro-services are ‘initialized’ real time as they are needed, which needs separate testing

Thirdly, integration of modules is now different, best to add more tests around that too

More on that here:

Lessons learned while preparing for my talk at #PSQC18

A – The mind remembers things in a specific sequence:
1. Tell them what you want to tell them
2. Tell them
3. Tell them what you told them

B – People might forget everything about a a talk, but they’ll never forget how you made them feel

C – Story telling is one of the best ways we learn, that why right from childhood we are taught in stories

D – Feel empathetic for the audience. Walk in their shoes and feel how best you can relate to them

Reference:

More on my talk today in upcoming posts..
http://www.pstb.pk/psqc/

#PSQC18 #TheArtOfPresenting

80% of most application’s code is on the server side

And most of us spend all our energies testing from the front end

That is the what Automation Pyramid illustrates, for us to focus on the server side

It is an impossility to have decent code coverage from front end alone

One has to use te API and DB to get access to otherwise inaccessible code

IMHO this is one of the reasons testers are not valued,

We don’t usually know how to do the job well

So let’s move towards ‘Technological Excellence’

More on that here:
www.quality-spectrum.com

#RedefiningSoftwareQuality

One of the core concepts for team’s success

I read about this in ‘Smarter Faster Better’ by Charles Duhigg and leaders eat last by Simon Sinek

Both great reads for those in leadership roles

Psychological safety creates a shared belief that all members of the team are safe to take any risk

That helps them innovate more and watch each other’s back

In turn help the group achieve what no one of them could have had individually

The most successful teams studied have a common feature, Psychological safety

The same finding was also found by ‘Project Aristotle’ – A research done by Google to find traits of most successful teams

References:

https://rework.withgoogle.com/print/guides/5721312655835136/
https://en.wikipedia.org/wiki/Psychological_safety
https://www.goodreads.com/book/show/16144853-leaders-eat-last
https://www.goodreads.com/book/show/25733966-smarter-faster-better

Breaking your application into ‘micro-services’

We used to have a single huge application server

Having one big service (API) supporting all client side requests

Now we can ‘containerize’ the big service and break it down into many smaller pieces

Each ‘container’ providing a ‘service’ to one specific module / functionality

As needed, these ‘containers’ can be created and destroyed, depending on client’s requests

These type of services are commonly referred to as ‘micro-services’

P.S.

A very vague and loosely defined terms are used here.

Continuous Delivery is the king maker – and you cannot have that without continuous testing

The biggest problem with releasing software is finding bugs well ahead of time

And this problem is UNIVERSAL

The solution is to have lots of automated regression running at different stages of the SDLC

That’s when the magic happens of continuous testing

When we miss bugs during testing, they keep compounding

Over time we have a giant heap of issues

Continuous testing reduces that heap and allows for smoother releases

More on that here:

The biggest challenge in running teams

A lot of people don’t have any ‘real’ goal except earning money, being lazy and comfy

Most of us are un-inspired, and that’s what a leader is for, to INSPIRE people

My Guru (Prof. Fareedy) used to say you need that ‘Fire in the belly’

Where teams are working towards a common goal miracles happen

The first step is ‘having a goal’, companies with visions of ‘maximizing shareholder value’ will not cut it anymore

Have grand and selfless goals, like “eliminating gas leakage related deaths by 2100” (Industrial Scientific)

For more, I’d recommend reading the chapter on culture and goal setting from the book ‘How google works’

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:

A complex question to answer

I advocate to first find out what to ‘test’

Then from that set, look for what to automate

Automation is to support the overall testing effort

Following are the few parameters I suggest to look for:
– Frequency of test
– Importance of text
– Ease of automation
– Automation ‘Super Powers’!

Details on that here:

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