alikhalid

About Ali Khalid

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

Fault injection post Agile

By | October 7th, 2019|daily post|

Fault injection / mutation testing is among the things I miss from the old waterfall days.

More on fault injection in my talk at QA&TEST conference this month end.

In waterfall days it was okay to spend time on improving testing and coming up with better testing techniques.

After the agile apocalypse, many teams found excuses to get away with perfecting their craft under the inaccurate pretense of urgency.

In my understanding, agile never meant not to get half cooked stuff out of the door, in fact quite the opposite, important activities should be part of the Definition of Done.

The only difference was to break a big project into very small deliverable.

So essentially all the good practices from before should continue, just implement in bite sized pieces.

Fault injection is one of those practices.

#QsDaily #Agile #Testing #MutationTesting

Fault Injection at QA&TEST Conference

By | October 2nd, 2019|daily post|

I am furious on hearing a tester saying ‘this is out of scope’.

I’ll be talking about one way to solve this at QA&TEST this month (https://www.qatest.org/ali-khalid/?lang=en).

Most of the time I’ve seen testers say this because they don’t know how to test that feature.

Instead of trying to go under the hood and understand the architecture and code base, they just raise their hands.

What really should be done is understand how that piece of code can be tested.

Yes developers should be doing unit tests, but even then tests on module / component level should be figured out

In the world of embedded systems and especially safety critical devices, letting a functionality go untested is not in the cards.

Using fault injection / mutation testing is one technique which I’ll be discussing at the conference.

Big data and Data Quality

By | September 28th, 2019|daily post|

Like industry types, testing applications dealing with big data is very different.

One of the biggest quality challenge in the big data space is of ‘Data Quality’.

Big data mostly deals with analyzing large data sets and extracting useful information / insights from it.

The real currency here is data, therefore quality of the data you get will heavily affect the results, hence quality.

What ‘data quality’ would mean for each product & insight will be different.

So the first step is, figuring out the ‘definition of data quality’ for a particular product and the insights we are trying to get.

#QsDaily #BigData #DataQuality

User Journey testing instead of End to End testing

By | September 23rd, 2019|daily post|

I very much dislike the word end to end testing,

It means different things to different people, instead I use testing the ‘user journey’…

End to end can mean:

1. From the UI to the DB level and back (ends of the tech stack)
2. Can mean a user story executed from the UI
3. A feature (group of stories) demo over the UI
4. The end user’s complete journey which cuts across multiple applications

For me, only no. 4 is end to end, but it’s so hard to explain to certain people.

I find testing the ‘user journey’ much easier to get across to the audience.

And this part of testing is the most neglected, where a user flow is going through multiple systems,

Each team’s feels responsible from the start and end of their product only..

#QsDaily, #testing #softwarequality

Reorgs and centralizing decision making

By | September 19th, 2019|daily post|

Many re-orgs are done to change the culture and how decisions are made,

Often I’ve noticed in the process they end up centralizing decision making even more,

This notion of a select group of people having enough background to make right decisions has to go away,

The typical old management style of information flowing up and decisions coming down, like in the military just does not work.

The complexity of today’s work place is far too much for any select group to be able to make all decisions.

Although the re-orgs mean to decentralize but letting go is just so hard,

Ultimately going even further way from the goal of gaining efficiencies by reducing waste in decision making

If we stick to the fundamentals of reducing waste, making these structural changes might become more easier.

For more, refer “scrum” By Jeff Sutherland

#QsDaily #agiletransformation #scrum

Waterfall from NASA

By | September 11th, 2019|daily post|

Did you know ‘phased program’ – (waterfall SDLC) was developed by NASA

And inspecting the failed programs, this process was found to be extremely inefficient

The phased program / gated development process / waterfall model was said to be very good at trying to show an over-glorified picture of the software

The focus was on documenting rigorously and proof.

I guess that’s where the Agile manifesto said – we value working product over comprehensive documentation

Many of our teams might have moved into an ‘agile’ model, but this idea of valuing working software over documentation still has not gone away

We insist on over documenting nonsense stuff, and under-documenting where needed.

Classic example – still maintaining those long test cases, and having very less context around stories or importantly writing feature files to agree on the product’s ‘behavior’ with the team

#QsDaily #agile #testing

You are paid what you are worth

By | September 10th, 2019|daily post|

A guru of mine once said – You are paid exactly what you are worth – I thought he was joking

Looking back, I can say he was right, at least in the long run, here’s one reason why..

I was having a chat with fellow testers the other day talking about tester’s career progression.

The biggest mistake IMHO people make is to not learn how to solve problems..

In today’s world, all businesses are focused on solving their customer’s problems, especially in tech.

Folks hired in these tech firms primary role is to develop solutions to solve these problems.

A few people find this very taxing and unexciting, because they never trained themselves in problem solving.

If you are working in tech, regardless of your position in the org, your primary role is to develop solutions for the target market’s problems.

If you can’t handle that job, you have no place in tech, and let’s then stop talking about career progression (or griping about it).

If you are solving problems, and your organization is not treating you well, you can get a better opportunity and leave.

So, in the end, you are paid what you are worth..

 

Most Important KPI for Software Quality

By | September 4th, 2019|daily post|

I figured it out.. the first and most important KPI for software quality..

Can you guess?.
.
Time from ‘prioritizing a feature’ to the time it is ‘ready for deployment’ in production.

Now some might say testers don’t have control over the whole process, that is true but we should be working to develop that maturity

Or we might say time to market is not as important as quality of the product,

My answer would be – Quality is subjective, best to get feedback from people spending money determine quality

That does not mean we ship crappy stuff, some things are no brainier, seeing exceptions, basic functionality not working are obvious

The part which is subjective is, certain features we might feel are very helpful, or as the user expected and therefore give the product a higher quality,

In the end customer’s experience, they might see that as a hindrance in using the product and would have a different perspective of the level of quality here

So, anyone working towards developing software (including testers), the foremost measure should be: How quickly we can go from ideation to deployment.

Thoughts?

#QsDaily #testingmetrics #transformation

Quality Metrics Headings

By | September 1st, 2019|daily post|

After years of going around in circles, I’m going to get it done.

A set of quality metrics that help improve productivity, and I need our community to pitch in..

I’ve gone through relevant content I could find, and to be honest there is just so much on this topic, both good and bad content.

The mistake I have done and see other do is, we measure things we ‘think’ will generate value, like automation coverage, but never the actual outcome we want – time to market and product quality.

Also there are some process factors which usually get skipped, which are also responsible for hitting these goals

In lieu of these, want to classify the metrics in three categories with some “SAMPLE” metrics, not an exhaustive list, just to explain the heading better.:

  • Practices maturity
    • g. Scrum ceremonies and best practices in them
    • Three amigo sessions
    • Defining the complete user journey for each epic & feature
  • Continuous testing
    • Automation pyramid
  • Business value
    • Time taken from pull request to ready for demo
    • Trend of issues coming from support which have to be fixed

Under these three headings will be a list for each.

Thoughts?

Learning Vs Money

By | August 31st, 2019|daily post|

Tech stack, money, growth or company culture, what is most important when accepting a new position?

From this list I’d say tech stack and company culture.

Technology stack is an important factor. Working on a platform which has demand in the industry certainly is more lucrative.

Company culture – Learning better ways of working is often not given due importance.

Being exposed to better ways of working where taking an idea from concept to implementation in the shortest possible time is vital. This is the core of a DevOps culture.

Money and growth are by products IMHO,

As one matures technically and learns efficient ways of working, money and growth should follow.