daily post

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: