About Ali Khalid

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

Writing user stories

By |2020-07-07T19:32:41+05:00July 7th, 2020|daily post|

There is a lot of good content out there on writing good use stories,

  • Here are few things I try to look out for:
  • Example mapping / Three amigo sessions – VITAL. This will crystallize your acceptance criteria and pointers for tests
  • Ensure the business objective & value is clear
  • Try to assign business value points when possible
  • Estimate relative to other work – Scrum poker helps
  • Definition of Done – Automation scripts, especially on services layer should be a part

The list can surely be longer, with these actions you should be able to write decent user stories resulting in highest value features delivered quickest.

#RedefiningSoftwareQuality #Agile #UserStories #Automation

Agile & documentation

By |2020-07-07T19:36:53+05:00July 4th, 2020|daily post|

Agile does NOT mean no documentation, most teams run into this trap.

It ‘values’ interactions over documentation – so interact with people then document the decisions from the interaction.

For instance, defining service contracts – white board the points, producers and consumers discuss what’s needed,

And after decision is made, then ‘document’ it.

#RedefiningSoftwareQuality #Agile #Testing

Coding doesn’t take much time

By |2020-07-07T19:38:11+05:00July 3rd, 2020|daily post|

Coding a feature is not the bigger problem –

It’s everything ‘around’ that development is what’s hard:

Effort that goes into:
– Making sure we’re building the right thing,
– Adequate testing of what’s developed
– Automated checks to test the functionality across tech stack
– Infrastructure to support development and testing
– Automating deployment across environments
– Observability & alerts to detect any anomalies

So you see, it’s not just ‘writing production code’ anymore. To be truly agile and having DevOps practices there is a lot more that has to be done.

#RedefiningSoftwareQuality #Transformation #DevOps #ContinuousTesting

Automation training start with learning testing

By |2020-07-02T20:09:51+05:00July 2nd, 2020|daily post|

Automation training doesn’t start with learning automation tools,

It start with learning testing fundamentals!

Learn what to test, where in the tech stack to test and how to test.

Next we can talk about what to automate, where and how.

The unfortunate part of many folks lerning automation – their training starts and ends with Selenium

And I say this all the time, you cannot pick a worse place than Selenium with Java to begin with.

Nothing against Selenium or Java, brilliant library & language but that’s not the starting point.

Most people feel what they lack is automation skills, unfortunately often engineers lack “Testing skills”.

If that’s not fixed, you’ll get garbage in and garbage out.

#RedefiningSoftwareQuality #Testing #Automation #TestAutomation #ContinuousTesting

Why flat org structures

By |2020-07-01T19:51:04+05:00July 1st, 2020|daily post|

Some background to ‘flattening the structure’

In the industrial revolution and mass manufacturing era, companies operated with lots of workers doing remedial tasks.

We had hundreds of people doing atomic jobs and funneling up progress & information up the ladder.

After information consolidating across many hierarchical structures, ‘management’ took decisions and sent instructions down the corporate ladder

In the internet age, we don’t have much remedial work left in many places & the speed of operation has phenomenally increased

Workers have been replaced with ‘knowledge workers’

OR ‘Smart creatives’ who are tech savvy, business savvy and are closest to the ground reality

Therefore decisions should not be made at the top, rather by the engineers closest to the situation

Which renders no need to ‘manage’ people and take decisions for engineers, rather just ’empower’ the engineers to take decisions.

Hence the necessity of flatter org hierarchies and Servant leadership

#Transformation #AgileTransformation


DevOps Test Strategy Mind Map

By |2020-08-09T22:19:09+05:00July 1st, 2020|Management|

Test strategy document problems

In the old days of waterfall, we were extensive on documentation and had hefty test strategy documents as well. Traditional test strategy documents used to have mountains of information, a lot of which wasn’t really used practically. They were all great writing in theory but hardly followed.

As agile came along, many teams started to pivot towards not writing a test strategy at all. Perhaps one assumption was being agile means no documentation. This never sit right with me and wasn’t happy with the approach. Ever felt like you have a lot of ideas in your head, but since can’t see them on paper, your sixth sense keep’s telling you ‘I’m missing something’, that’s what it was.

What was needed

Having no test strategy document, important ingredients to bake quality into the products was difficult. So to me it was always clear we needed a test strategy, but having done the old school test strategy documents, I knew something like that was of no use either.

I started listing what I’d like an ideal test strategy document to be like. It should help with:

  • Defining the direction and vision of testing
  • Consolidate quality related attributes we need to consider
  • What to focus on testing, where in the tech stack & how?
  • What to automate and how?
  • Some practices / references engineers can refer to in day to day practice

These would give the whole team a sense of alignment towards a common goal, vital to bake quality into the product and not try to ‘gauge’ after the fact.

DevOps Test strategy

After transforming team’s quality practices for a while, I noticed certain things which I kept on preaching to most team and end up writing them in some shape or form. Meanwhile a dire need of a good training program was needed as well to train engineers on testing and automation practices. While designing the program I saw a perfect opportunity to design a course for building a test strategy for agile teams, and that’s when I came up with the “DevOps Test Strategy Mindmap”.

The mind map depicts the target state for common web applications running in an enterprise and how to plan your quality practices to get there. The purpose was to give teams a sample target state and develop one according which suits the team’s needs.

Mind Map

An important aspect of this test strategy was it should be easy to update and maintain. I love mind maps the most among all the different documenting techniques I’ve used, therefore made one for the test strategy. It helps to keep it:

  • Concise – To the point information
  • Complete – Covering important areas teams transforming into DevOps ways of working should consider
  • Easy to read & maintain – In the form of a mind map so readers can see the whole landscape at once

To get the high-resolution version, click here:

DevOps Test Strategy Mindmap

I hope you find It useful for your teams. Feel free to share your experience about it in the comments.

Java Or Javascript for automation

By |2020-06-29T19:37:30+05:00June 29th, 2020|daily post|

Which language for automation – Java or JavaScript?

There is NO silver bullet answer and it might not even be these two (Python or Ruby)

Here’s what I have used historically:

  • Browser automation : Javascipt
  • Interacting with the DOM is easier,
  • Using AUT exposed methods is easy
  • Scripting languages quicker to write and lesser code
  • Popular tools: WebDriver, Cypress, NightWatch

Services automation: Java (Where prod code is in Java)

  • Same language as production code – critical for component tests
  • More options for mocks
  • Can reuse prod code (e.g. POJOs)
  • Extensive community support
  • Popular tools: RestAssured, WebTestClient

Again, no silver bullet answer – need to consider various factors to decide for your team.

#TestAutomation #Testing #Programming

PI planning for architecture runway

By |2020-06-28T22:05:05+05:00June 28th, 2020|daily post|

Planning you PIs (Program Increments) is crucial (One PI typically spans for 6 sprints).

While planning architectural road maps for quality initiatives across different teams, I’ve noticed a couple of blind spots:

1. Planning for feature deliveries and enablers / architecture road map are very different, planning them both the same way does not work.

2. Test and learn – I am the planning type, plan so extensively and as soon as the rubber hits the road, all plans go up in the air. Have a long term vision, but how to get there is fluid – plan that for just ONE PI

3. Prioritizing enabler features. Depending on what your structure is, getting tech debt prioritized can be the toughest job. Try to get an agreement around that.