alikhalid

About Ali Khalid

This author has not yet filled in any details.
So far Ali Khalid has created 303 blog entries.

My key learnings in 2019

By | January 7th, 2020|Uncategorized|

Another year of great learnings has passed. I am thankful for having the opportunity to gain lots of new insights and experiences. Most of the year was spent on designing and supporting an IT transformation focusing to deliver at speed with quality. This initiative allowed me to be exposed to a lot of different challenges and meet wonderful people.

Stepping into 2020 I thought of writing top 3 learnings which I want to take into the next year and work more on.

 

Eliminate Waste

Everyone has the same amount of time in a day, then how some people / teams accomplish much more than others? There has been considerable research on the subject, I feel the common theme in most results is successful people / teams don’t waste effort.

From reading and working in scrum teams, a very core focus in agile ways of working is to focus only on ‘what’s important’. Further to decide what’s important, ask the customer who’s paying for the effort. This singular focus on what’s important, what’s needed to meet the objective is a key factor in success.

Over the holidays some family time was spent talking about achieving goals. I shared an observation that every person has the same 24 hours in a day. Also, every person while they are awake are doing something, working on something, watching something, talking or whatever, just doing ‘something’. To achieve your goals, don’t do ‘something’, do ‘THE thing’ instead of low priority items.

I often give the example of a magnet. All solids have atoms exerting force in some direction, but the net result of all force is neutral. In magnets, like other solids atoms are exerting force too, only difference is they align in one direction. Collective focus in a singular direction makes the difference.

The problem with people / teams, we don’t always have a prioritized list of activities to do to reach our objective. Without this ‘prioritized backlog’, we react instead of being proactive and end up working on what’s not important and waste time for which the users / business is not ready to pay for.

For additional reading on alignment of purpose, especially for scum teams, I’d recommend “Scrum: The Art of Doing Twice the Work in Half the Time” by Jeff Sutherland.

 

Leadership is being Selfless

My philosophy for leadership has always been ‘leading by example’. In my quest to learn more about transformation, leadership kept coming up. Therefore, I turned to my favorite speaker on the subject: Simon Sinek.

From primitive times, leaders of the tribe were always given first choice of food and preferential treatment, and members of the tribe didn’t have a problem with that. That’s because they were getting something in return, the leader giving sacrifices which others were not ready to do. To protect from any external dangers and look after the tribe members.

The same unwritten rules still govern the modern world, but when leaders don’t give any protection in return, or don’t look after our interests, this unwritten contract is breached, that’s we have a problem. Leadership, by definition, is an act of being selfless and keeping the interests of the tribe / community / team ahead of your own personal interests.

In the capitalist world we live in, with extreme deprivation of moral code and ethics, it’s challenging to be truly selfless in a corporate environment. I feel we should at least try to be closest to this golden standard. One cannot be a true leader unless they have interests of others ahead of their own.

Additional reading: Leaders eat last by Simon Sinek.

 

DevOps – A mindset & a TON of enablers

I’ve always said the Agile manifesto had the core of DevOps in there, in theory DevOps does not suggest a new paradigm shift, it provides pointers around technology and tools to really become agile. Therefore, a big part of DevOps is the cultural mindset change.

A big part of that mindset change for me were the two points mentioned earlier, eliminate waste and leadership. To produce quickly, the whole team has to be single mindedly focused on one objective only and not waste time second or third priority items. Only then we can quickly move things from ‘work in progress’ to ‘done’.

Part of waste is teams waiting around for someone to take a decision and tell them what to do. Teams need to feel empowered, so they think for themselves, take decisions and make things happen. As they progress, they’ll learn and improve as they move along. This is where leadership comes in, if leaders selflessly try to make things easier for team members to do their job, they feel more empowered and motivated to go ahead.

With DevOps, things don’t just end with transformational talk, a lot of enablers need to be put in place to achieve this. Therefore,

 

DevOps is sexy – but not a piece of cake

 

Bare minimum to do it well, you need CI pipeline(s) with all hooks in place, code repos with proper branching / merging, spinning up of on-demand environments which are fit for purpose, a TON of automation running at different stages across the pipeline, mocks / stubs, test data creation / deletion, connectivity with other products where needed. So you see, doing all this is not sexy at all.

Oh, and lastly, if you expect DevOps is going to reduce your cost, in the long run it should yes, but for a year or two you’ll be spending 2X or 3X the amount to get all these enablers in place. It reduces cost by eliminating waste, reducing manual churn, people not working on low priority items (back to cultural change)

 

To sum this up, I wrote a short Poem a few weeks back:

 

Software over the wall ; results in a great fall.

Testers, developers and all ; will then not like management’s call.

Ship in collaboration, be quick and release small ; that’s a lesson for us all.

 

There were a lot of other things I experienced, these were the top 3. Looking forward to continue working on these in 2020 as well.

 

What was your top learning from 2019?

Don’t start with learning Selenium

By | January 7th, 2020|daily post|

I very much dislike automation trainings starting with teaching Selenium,

For starters that’s the wrong place to do automation. One should focus more on API tests and do a handful UI checks.

Secondly, automation is a means to an end, not an exercise for the heck of it. Therefore talk about why to automate.

Thirdly, in some cases folks learning automation don’t really learn how to test well either. If your testing is bad, your automation is just going to amplfy that bad.

Lastly, without knowing how the underlying architecture of the product works, IMHO one cannot truly learn how to test well.

So next time you plan an automation training, make sure you get the fundamentals right first.

#RedefiningSoftwareQuality #TestAutomation #Training

QA&TEST 2019 – Pro Tester using Fault Injection

By | December 13th, 2019|Uncategorized|

Since the start of my career as a tester, I’ve always been obsessed with testers delivering tangible value to the business. I realized ‘redefining software quality’ was my calling. There were quite a few powerful stories that lead to this realization, and one of the most important ones I presented at the QA&TEST 2019 conference.

This was a story about testers taking responsibility and recognizing how important it is to understand the underlying technology of the product. From this event emerged the three core values I feel which can reshape how we think about software quality.

This talk was awarded the best presenter award at the QA&TEST 2019 conference,

 

Award ceremony video here.

I thoroughly enjoyed the conference, the city and the hospitality. I talked about it in this article and a short shout out for the organizers on a job well done.

Presentation key points

Out of scope

The products being very complex, it was impossible to test everything through black box testing. Areas which the testers were unable to understand how they work, or there was no way to test them, were not considered as the tester’s responsibility.

While quality is everyone’s responsibility, but testers do need to make sure all bases are covered. It isn’t necessary that everything must be tested by a tester, but a tester should make sure that ‘someone’ is testing all the areas that should be covered.

 

Code coverage

Code coverage is not the only measure to check, but certainly is one of the important ones. Unless we are sure all statements and branches of the code have been executed and tested, we cannot be sure of all the hidden risks. With just black box exploratory testing, it’s almost impossible to figure out the code coverage % even is, let alone having a decent code coverage.

In our story here that was the case, almost zero visibility into the code, some functionality had been going untested. Neither was there any effort in figuring out how to improve that coverage.

 

Fault injection

In pursuit to improve coverage we came with a method to do fault injection / mutation testing. Instead of controlling the input parameters from outside, alter the control flow within the program to reach the desired state.

Technological excellence

Without knowing the technical