alikhalid

About Ali Khalid

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

In sprint automation not happening because?

By |2020-10-12T18:57:21+05:00October 11th, 2020|daily post|

If automation is not happening within the same sprint, who is at fault?

We testers immediately feel that’s somehow our fault – whereas in 90% of the cases I’ve seen it’s not.

I spoke about this yesterday, and some folks were not confident about this being practical (https://lnkd.in/en8GqEp)

Automating within the same sprint is the ideal world every team should target towards

However if that’s not happening (and mostly it doesn’t), that speaks more towards the ways of working of the organization and team instead of tester’s skills

The first step towards this is ‘commitment from management’ to treat automation equally important to developing the feature.

As long as we treat automation as an after thought, there is no way this (aka in-sprint automation) can become a reality – And this is most definitely not a testers issue!

#RedefiningSoftwareQuality ✔ #DevOps #TestAutomation #AgileTesting

Automation a spring behind?

By |2020-10-12T18:58:13+05:00October 10th, 2020|daily post|

Should automation be one sprint behind?

The argument in favor of this is mostly – we want to deliver quickly and automation slows us down.

IMHO there are a couple of reasons for why this is the argument folks make:

– Definition of Done not defined
– Testability not built into the product architecture
– Automation is only the automation engineers job
– Automation is focused only on the UI
– Automation is considered only tester’s job..

If we agree with that, we are consciously making a decision to incur technical debt and have problems down the line.

To build your product well, you have to spend do things properly and upfront thinking.

#RedefiningSoftwareQuality ✔ #QualityTransformation #TestAutomation #Testing #Agile #AgileTesting

Learn to test and code well

By |2020-10-12T18:58:51+05:00October 9th, 2020|daily post|

Learning to test well is equally important as to code well..

For decades we’ve managed to keep the wall between dev & test, now it’s just common knowledge that you can be either or.

I can’t see a justification of why an individual can’t have both skills..

Test plans – not contracts

By |2020-10-12T18:59:40+05:00October 8th, 2020|daily post|

Let test plans just be ‘plans’ – not fine print of a contract to limit the liability of testers!

I know it’s not fair sometimes testers have a lot of ground to cover and are unfairly blamed if bugs come from production

I talk about the problem the way I see it and how teams can go about making test plans something to bridge the gap – not fortify dev & test positions in their own bubbles..

Fix the source of bugs, not the symptom

By |2020-10-07T21:14:59+05:00October 7th, 2020|daily post|

Is there a proper way of fixing bugs?

Yes – Fix them AT THE SOURCE

I’ve noticed many times engineers lacking simple understanding of ‘due to which design flaw’ a bug is coming up

And as we humans commonly do, engineers try to fix the ‘symptom’ not the problem.

Let me explain:

A new field introduced in a form on a web page. This data is used by this application, also this data is fed into other applications.

Now our new field here is one big text area, where users are expected to enter let’s say name and phone number.

Naturally every person will write the values in a different order & different formats, which will lead to complications for applications using this.

Now to handle the varied type of inputs we can get, engineers spend time trying to build Regex to ‘extract’ the name & phone numbers. – This to me is suppressing the symptom

The thing to fix is – break that giant field down into first & last names and phone number fields separately with field validations..

This might seem very obvious, you’d be surprised how many times we get this wrong..

#RedefiningSoftwareQuality ✔ #Bugs #Development

✔️ Follow me to transform your quality practices

Proper way of fixing bugs?

By |2020-10-12T19:00:33+05:00October 7th, 2020|daily post|

Is there a proper way of fixing bugs?

Yes – Fix them AT THE SOURCE

I’ve noticed many times engineers lacking simple understanding of ‘due to which design flaw’ a bug is coming up

And as we humans commonly do, engineers try to fix the ‘symptom’ not the problem.

Let me explain:
A new field introduced in a form on a web page. This data is used by this application, also this data is fed into other applications.

Now our new field here is one big text area, where users are expected to enter let’s say name and phone number.

Naturally every person will write the values in a different order & different formats, which will lead to complications for applications using this.

Now to handle the varied type of inputs we can get, engineers spend time trying to build Regex to ‘extract’ the name & phone numbers. – This to me is suppressing the symptom

The thing to fix is – break that giant field down into first & last names and phone number fields separately with field validations..

This might seem very obvious, you’d be surprised how many times we get this wrong..

#RedefiningSoftwareQuality ✔ #Bugs #Development

Testing is everyone’s job

By |2020-10-06T19:36:33+05:00October 6th, 2020|daily post|

Is testing only tester’s job?

All engineers on the team should be involved with testing in some shape or form..

Doing exploratory testing, providing enablers for exploratory tests

Writing automated tests, fixing scripts, creating enablers for automated tests

Some argue – Testers have a unique skills, due to which only they can do testing

IMHO we haven’t been very good at explaining ‘how to test well’ and therefore find it hard to train developers to test well

If you want get on the DevOps journey, This should be part of your DevOps transformation..

#RedefiningSoftwareQuality ✔ #Testing #TestAcumen #QualityTransformation #DevOpsTransformation

Stop that release

By |2020-09-26T19:57:24+05:00September 26th, 2020|daily post|

Due to many reasons, a wide spread perception about testing has been ‘the blockers to release’,

Not just because of time, IMHO also because the internal goal of testers is somewhat ‘stop the release from going’!

Here how I’ve seen it happen:

– Testers have lots to cover, and less time
– Anything goes wrong in production, tester’s get blamed
– To avoid that situation, testers try to mount substantial evidence that there are risks in the release, so ‘Release at your own risk!’

The main problem here is NOT testers or testing – it’s this blame game mentality

To improve quality in such a setup, start working on build psychological safety first, rest will follow..

[Recording] – A DevOps Test Strategy that Works!

By |2020-10-20T19:47:14+05:00September 25th, 2020|webinars|

In an ideal world:

  • At what stage should you have automation and exploratory testing?
  • What testing practices will help us reduce number of issues & identify issues quicker?
  • What testing / quality related KPIs should we measure?

A test strategy is expected to answer many of these questions

Typical old school test strategies usually don’t speak directly to these pain points and are difficult to develop, use & maintain. To help teams design a test strategy that helps them TRANSFORM their practices over time – I designed the ‘DevOps Test Strategy Mindmap’ – DTSM

How to develop ‘collective’ ownership of quality?

One way is having a test strategy that speaks to everyone on the team. Every action taken by anyone in the team contributes to quality, knowingly or unknowingly, positively or negatively.

So it’s important to develop ways of working which improve quality of the product. In this talk I’m introducing a test strategy that accomplishes just that.


Slide Deck


Session Recording

Quick intro to risk based testing

By |2020-09-23T19:38:01+05:00September 23rd, 2020|daily post|

A 20 second intro to risk based testing..

What – Identify and rank features according to risks, and focus on high risk areas

Why – Instead of buck-shot approach, try a targeted approach to testing

Two approaches – Inside out risk analysis & outside in risk analysis

Inside-out risk analysis: Brainstorm internal working of a component, walk through the design and understand the vulnerabilities, threats & victims

Outside in risk analysis: Explore a functionality from the outside, use different type of ‘risk checklists’ like risks from past experiences, ‘ilties’ list, domain / industry specific check list

Best to create risk matrices giving an overview of different features, their risk level and associated heuristics to use

Go to Top