About Ali Khalid

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

The Next Generation Tester Skill Set

By | August 10th, 2019|Management|

What would be the skill set you’d like the people driving the quality culture in an organization to have? I’ve always been excited to find out what would be the skill set of a veteran tester. Who can interface with senior executives and at the same time lead and mentor quality best practices in testers. This is an attempt to classify the skills on a very high level I’d like to see.

This certainly will be subjective from person / organization to another, and I can’t imagine any person who would be an expert in all these skills. But helps to draw out the important skills.

Quality Engineering

Ways of working

  • Understanding of what a DevOps culture is
  • Designing and developing quality practices which are efficient and effective
  • Understands the practical implementation of Agile principles and implementing them in a team
  • Implementing scrum best practices
  • Experience in driving desired behavior in teams
  • Leading by example / servant leadership

KPIs, Reporting, Metrics

  • Designing quality metrics which provide indication of a build’s health
  • Developing team KPIs
  • Pitfalls in metrics and how to mitigate them
  • Expose and report risks in large product solutions

Facilitating Product Development

  1. Understanding core problem the product is solving
  2. Building and communicating product context for testers
  3. Make sure testing activities are in line with the core problem to solve
  4. Facilitate UAT and collaborate to making the process effective

Enterprise Management

  1. Socialize & collaborate with Senior Execs
  2. Voice quality related concerns
  3. Ability to make a point and get agreement from C-level executives
  4. Oral and written communication skills

Vendor management

  • Designing vendor contracts
  • Acceptance of test schedules
  • Managing offshore vendors goals and day to day activities


Test Strategy

  • Design test strategy in line with Tech stack, product / business use case & project constraints
  • Identify test coverage gaps / unexplored potential risky areas
  • How to push tests down to lower levels of tech stack
  • Strategy to leverage automation
  • Prioritize test scenarios
  • Design bug reporting flow


  • Using BDD to increase collaboration
  • Best practices for writing feature files
  • Cucumber / Serenity
  • Any other BDD tool

Exploratory Testing

  • Questioning requirements and assumptions
  • Developing testing heuristics
  • Using developed testing heuristics
  • Teaching testing heuristics
  • Usage of effective documentation methods (e.g. Mind Maps)

Test Cases

  • Writing test cases (efficient and easily maintainable)
  • Understanding of which test to automate
  • Using testing heuristics to develop test scenarios
  • Test management tools

Automation in test

Automation architecture design

  • Designing API automation frameworks
  • Designing UI automation frameworks
  • Developing test harnesses
  • Test data creation tools / programs
  • Developing synergies between automation teams
  • Automation best practices, design patterns and anti-patterns

Fundamentals of framework design

  • Develop Maintainability in framework design
  • Develop Reusability in framework design
  • Develop Scalability in framework design
  • Develop Robustness in framework design


  • Writing clean and professional code
  • Seasoned practitioner of coding patterns
  • Developed coding guidelines and principles for teams to follow
  • Usage of static analysis tools (e.g. SonarQube)
  • Skilled in any one strongly typed language (Java, C# etc.)
  • Skilled in any one loosely typed language (JavaScript, Python etc.)

Operational Acceptance Testing

  • Performance testing
  • JMeter
  • Gatling
  • Security testing

API Automation

  • Hands on experience solving API automation challenges
  • In depth understanding of HTML methods
  • RestAssured
  • WebDriverIo
  • Any other API automation tools
  • JSON
  • XML

UI Automation

  • Hands on experience solving typical UI automation challenges
  • In depth understanding of how browser automation tools work
  • Open source browser automation tools / libraries (e.g. Selenium, etc.)
  • Enterprise tools (e.g. UFT / TestComplete)
  • Junit, TestNG
  • Allure
  • Maven / Gradle

Mobile Automation

  • Experience solving typical mobile automation challenges
  • Understanding of how Android and iOS work and interactions during native apps automation
  • Appium
  • XCUITest

Continuous Integration


  • Worked with Git using proper branching and merging strategies (e.g. BitBucket, GitHub etc..)
  • Raising and approving pull request
  • Collaborating on code reviews


  • Setting up Jenkins
  • Creating pipeline jobs
  • Configuring automation framework hooks in Jenkins (using maven, ant etc..)
  • Configure to generate telemetry
  • Troubleshoot jobs and familiarity with Jenkins logs
  • Configure and troubleshoot automation reports
  • Gather metrics from execution data in the pipeline

Environment management – Containers

  • How containers work
  • Docker – creating and using containers
  • Orchestration tools (e.g. Kubernetes)

Environment management – VMs

  • Setting up VMs
  • Worked with configuring OS & tools to setup test environments
  • Provisioning Network access etc.

Environment management – Cloud

  • Usage of test environment SaaS tools (e.g. Sauce Labs)
  • Setting up these tools (e.g. Sauce Labs)

Technical & Test leadership

Team Leadership

  • Leading by example / servant leadership
  • Developing an open culture where people are free to share their thoughts and fail fast
  • Developing confidence in team members
  • Leading teams under 10 people
  • Leading teams from an enterprise level
  • Provide positive and constructive feedback respectfully
  • Build positive relationships with team members
  • Planning, organizing, and follow-up skills
  • Hire and mentor Software Quality Engineers

Thought leadership

  • Sharing and learning in the testing community
  • Collaborating with other thought leaders
  • Familiar with latest trends in the software and testing community

Technical Acumen

  • How technology stack works – Presentation, business, persistence and database layers
  • Micro services architecture
  • Front end platforms architecture (e.g. Angualr, Node JS)
  • Web development fundamentals – HTML, CSS and JS
  • Back end platforms architecture (e.g. Spring boots, .Net)
  • HTTP messages
  • MVC architecture
  • SQL fundamentals and schema design

Collaborating with Architects / Senior devs

  • Ability to understand complex product design
  • Review product architecture and provide feedback related to quality and stability
  • Ensure product architecture allows for testability

I’d love to hear your thoughts and what skills you would add / edit in the list.

Autonomy and Transcendence

By | August 5th, 2019|daily post|

Do super star individuals deliver greater results or super teams?

While we all might instinctively feel the team would do better but…

Super start individuals can sometimes deliver up to 10x results

That’s why companies tend recognize individual performers more.

However, super teams outperform other teams by 100x!

The ‘economies of scale’ come from alignment of purpose and empowerment

Now how do these 100x results come about? When scrum teams have:

  1. Autonomy. All the skills and needed resources reside within the team and they have no dependencies outside
  2. Transcendence. Alignment of purpose, everyone thinks and dreams of the exact same goals.


Reference: Scrum (By Jeff Sutherland)

My Experience at the Test Leadership Congress

By | July 22nd, 2019|Uncategorized|

Two weeks ago I went to the Test Leadership Congress conference in NYC, absolutely loved the content and speakers. It was at a very opportune time while we were working on IT transformation and myself looking after the processes and quality expectations in our new ways of working.

With the prevalent wisdom of fully automating ‘testing’ and less need for test leadership, the conference was loaded with evidence on the contrary. In the post-agile apocalypse, the system level thinking and the pivotal role of testers to question what and why we are building what is user story says and the current build demonstrates, is all getting lost in the mushroom cloud of buzz words and time to market.


There were a lot of amazing sessions including psychological techniques to figure out your own and your organizational values, using Improv to make a point and learn look at things from a holistic perspective, playing games designed to improve thinking and test design and a board game to understand the important aspects in continuous delivery. Most of the sessions were so great, it was hard to pick which one to go to.

The organizers especially Anna and Andrea did a great job in choosing the speakers to have a great mix and schedule the activities. Typically you would see topics around specific tools or technologies, this one was more about developing leadership which I feel is need of the hour.

Key learnings

It’s going to take me a while to digest and share my thoughts around the sessions. On top of my head here were the few learnings that really stuck with me:

System Theoretic Process Analysis – STPA.

Dr John P. Thomas’s keynote on systems approach to software testing was very refreshing. Having a similar background of working with safety critical systems, I have always felt the absence of certain things in the agile world like spending time in understanding and questioning the requirements, mapping the entire system and looking at how the control flow works. STPA was a process introduced to us by John which felt like a systematic process to codify how that system thinking is supposed to be done. Will share more in a separate post.

The Protreptic dialog.

Ive always struggled with finding out values of other people to act according to their and the organization’s commonly held values. I always try to do ‘only’ the right thing which now I feel might not always be the best way. In most cases should try to be resonant of the organizational values and try to start operating from there instead.

The protreptic dialog explanation and demonstration in which Ole and Anders did a great workshop which showed a way to understand other people’s perspectives and learn more about their values.

In the dialog, you ask the other person to describe an event and have follow up questions while being genuinely curious to understand what it means for them. Try to understand:

  1. What do you sense about the person (hear in their voice, body language)
  2. How do you think they feel (deduced from what you sensed above)
  3. Ask the person to reflect on their feelings
  4. Ask why this means so much to them, why does it matter to them.

If You Really Want to Make a Difference, Be the Flexibly Robust Leader

Ole S Rasmussen talk on Personal leadership was great and this stood out for me out the whole workshop. He explained what being robust and flexible meant and how to become a ‘flexible robust’ leader.

The technique to do a self assessment and find out what your personal values are and your own limits. In a short exercise we identified what does fragility mean for us and what corner is most significant for us in the philosophical triangle (shown below). It was a good demonstration to see how to journey inwards and understand your own self.

As a leader, understanding your own self is very helpful, gives an idea of your own limitations, strengths and weaknesses. For me the exercise revealed Fragility for me meant fearful, and from the triangle ‘attention to what matters most’ was most important. stitching them together we figured I may be fearful of not focusing on the right thing and waste my energy and my team’s on doing what does not matter the most.

The game of continuous delivery

Tanya’s session on continuous delivery was nice in which she explained the guiding principles for DevOps – CALMR. Working on SAFe framework I had been exposed to these principles, but what was new was the second half of the talk, a continuous delivery board game!

Looked like monopoly of DevOps. I’ve always been very passionate about having dry runs of complex problems to do some up-front thinking instead of just trying a whole bunch of failures and then finding what works. The board game instilled the importance of certain aspects in coding CI/CD which are otherwise hard to comprehend without practical experience.

For instance, how it’s important for features to be in production instead of having a whole heap of them at different stages in the pipeline, unless it’s out there, you cannot make money!

There were many other sessions which were great, I’ll add more details on them in separate posts. I learned not only in the sessions, but outside the workshops and presentations networking with others was a great opportunity to learn. Talking with leaders in other organizations and practitioners there was so much more we learned from each other.

‘No one’ has it all figured out

The biggest take away from these talks was: “EVERYONE IS STRUGGLING WITH CONTINUOUS TESTING”. One would assume the big names and thought leaders in our industry would have everything figured out, but we are all struggling, some are quite close, others might be far behind, but it seems no one has it nailed down with all their products working in a complete DevOps culture across the enterprise

That means,

those of us looking for greener grass on the other side, try to cultivate some green grass where you are, no one has the magic formula to continuous testing.

Fun with a Capital F

The games and round table session was amazing. We all had a blast designing test strategy for products of our choosing and then demonstrating them.

There was a separate games time in which Eddie and Jordan organized a lot of different games. I got pulled into playing story cubes, we all enjoyed it very much, it was so hilarious the kind of stories we came up with.

End of last day we had an after party, lots of great conversations and new friends. Had a wonderful time.

The most inspiring event

A fellow tester and I tried to meet during my last time visit to the US. This time he was determined and I’m glad we did it. He had to travel such a long distance in one day, just to learn and improve his skill set. I shred the details of the story in this post.

Travel back

Met a lot of people I had been interacting with in the testing community on social media, Ajay being one of them. While traveling back from the conference Ajay and I happened to be on the same flight. While waiting at JFK we recorded a short video about how the conference went and what we liked about it.

Accompanying me on this trip was Head to QA at Emirates, to whom I had suggested the conference. She loved the setup too and while going back we recorded our thoughts, what we learned and some key take aways, you can watch in this video.

And enjoying the comfy Emirates A380 business class 🙂

Passion to learn

By | July 18th, 2019|daily post|

The 900 miles journey in one night – just to meet and learn in person, that’s passion.


This was when Vignesh came over to meet in in NYC few weeks ago (details in post linked in comments)


Hard work and passion are a must if you want to advance your career


When I see people who don’t want to put the hours and want success, that’s like trying to learn swimming without getting into the water


I’ve also learned that’s not the only success criteria, you also have to be smart about what you are working towards and keep evolving your direction.


But by no measure does smart work mean you don’t put in the hours. There is no success without the grind.


If you are a tester and you haven’t been upgrading yourself, I wouldn’t lie your up for a tough time.


And it’s not just testers, the entire global economy is changing, t’s going to affect everyone, some a bit harder.


So instead of blaming developers and rest of the world, lets buckle up and get to learning.


More on that in the post below:


900 miles to seek knowledge


900 Miles to Seek Knowledge

By | July 12th, 2019|Learning Automation|

From the past few years whenever I travel, I usually try to meet people I know from social media if I get a chance. This year while attending the Test Leadership conference I did the same and dropped a message on the social channels.

Vignesh is one of the people who has been in touch and sharing ideas on testing and automation. Last year when I was in Philly we decided to meet, somehow our schedules got in the way. This time Vignesh again reached out and was adamant to meet.

The predicament

I was flying out on a Saturday and the only time he could make it was Friday evening. What I learned later, he was based in Virgina and wanted to meet me in New York! The best he could do was around mid-night, and I had to leave for the airport early morning for my flight back to Dubai. It would have been very late for me, but he was so passionate to meet I just couldn’t refuse him.

It was 1 AM when I got his message he had arrived in the Hotel lobby. It was such a treat to talk with him and see the passion to learn gleaming out of every sentence he spoke. We discussed around testing careers and what skills to focus on to advance as a tester.

Fundamentals of the next generation tester

I’ll try to summarize the main areas I feel a tester should focus on, the details of it will have to be a separate (and important) article I’ll have to pick up later.

I hope he learned something from me, here is what I learned from him:


Invest in yourself, and the best way is to learn in person.


We finished the conversation around 3 AM, after which Vignesh was to take the next bus back to Virginia! (I thought my 14 hours flight was bad).  Before he left, here are the two of us (with me in my PJs) happy to have spent time learning and sharing:

The secret sauce to enhancing your career

After all the self helpery books and my experience over the years, the most important ingredient which people often miss out on is consistent hard work. Most of us keep searching for the silver bullet to jump to success without putting in the hours, which does not exist. While surely there are many other factors which contribute to moving forward in ones career,

There is no substitute for hard work

So, to all those who want to move forward, putting in the hours to hone your skills and seeking the best ways to do it is most important. Nothing else will work unless this fundamental is there.

Do you need Test leadership?

By | June 17th, 2019|daily post|

I’m uncertain as to why sometimes it’s so hard to explain the importance of ‘test leadership’.

People can have a lead architect, a lead product owner, a lead developer and even a ‘lead of leads’, but having a test lead would somehow kill autonomy…

The argument is in agile world the team does the job, so they should be self-reliant, and no one needed to ‘manage’ them.

What they fail to understand is testing with technical competence is not something abundantly available in the industry.

Most companies have to manage with the few senior resources they’ve got and use them to train rest of the teams.

IMHO the root cause is this deep-rooted ignorance that testing is just a matter of doing some ‘monkey testing’ and that’s about it.

I’d argue testing and specifically automation take as much resources as developing the service, whoever plays that role requires critical thinking, strong technical skill and exposure.

One would assume after decades of blunders and evolution we would have realized why strong testing is important, no wonder restating your PC when software is not working seems to be ‘perfectly normal’.

Building context to requirements

By | June 12th, 2019|daily post|

Generally how does your team go about doing testing or automation?

Most people (in my experience) jump right into writing test cases or automate written tests… anything wrong there?

The source of tests is usually a bunch of written statements without any context from which testers start create test scenarios

Occasionally might have a chat with the BA or product owner if they find the time.

What’s missing here is the context, the understanding of what problem we are trying to solve

Now just if you wrote a ‘story’ doesn’t mean you got all the context.

It is imperative to talk to marketing, product and support to understand why we are building this product, how is our solution different from others in the market.

Understanding the competitive advantage and pain points of the consumers gives the testers context and a yard stick to gauge what’s important.

Shadowing how the customers use the product in the field is another good way of gaining context into the solution.

Any other techniques you’ve used to understand the context better?

Why Re-Orgs happen

By | June 10th, 2019|daily post|

Why do many enterprises go through Re-Orgs?

Here are a few reasons I’ve figured out so far:

  • To increase efficiencies
  • To reduce cost
  • Technological innovation
  • New management comes in with a new mandate

The root cause of most of these is large organizations having problems with adapting to change and having a hard time innovating

Could be because of:

  • People are far away from the vision of the organization, feel like a small cog in a big machine
  • Extra governance, lots of red tape,
  • People become complacent doing the same job day in day out
  • It gets harder to hold people accountable due to long and complex processes
  • People have no reason or motivation to change

IMHO the mother of all problems is lack of motivation.

Whatever course of action is taken to solve the organizational problems, if the teams are not motivated, long lasting change is highly unlikely to happen.

Give permission to challenge

By | June 9th, 2019|daily post|

Leadership lesson – Give permission to challenge


What does this mean:

  • People sitting at the meeting table should feel empowered to disagree with any point of view, especially if it is of the leaders in the room


Why is it important:

  • It is not individuals who take the day, teams are the ones to bring success. Physiological safety is the secret of team’s success
  • Unless the team feels they are empowered to speak their mind, physiological safety cannot exist.


How to do it:

  • The leader should not share his / her opinion at the outset, so everyone feels comfortable to share their opinion
  • Probe people to challenge the status quo
  • Do not let anyone feel punished for challenging the status quo – ever


Trouble shooting:

It is possible you might sometimes face confrontation for the sake of it and not for improvement. In such a case:

  • Time box the discussions and assert a decision must be taken before a set deadline
  • Try to use as much factual data as possible
  • If a decision is being taken against what the data says, bring back the discussion to deciding based on data


Reference material:

  • How Google works by Eric Schidt
  • Chapter – Decisions, the true meaning of consensus


Developing software an art

By | May 9th, 2019|daily post|

While redefining the QA function at work, I keep coming back to this question:

What is Software Quality?

If we deliver exactly what the requirements / user story says, is that quality?

We’d say that’s validation, so we must also do verification which is ‘are we building the right thing’,

The problem there is, in a large organization a bunch of ‘groups’ have to sign off.

Now the ‘end users’ (if you will) don’t align to a single version of what’s expected.

That’s why I sometimes feel developing software is not a science, it’s an art.

It’s an art to bring a vision of a select group of people to life.

The details of the vision for all might be different, but they all might be connected with a common emotion.

Therefore, in the end, it’s about answering to that shared ‘emotion’ of the stakeholders.