alikhalid

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

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

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..

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..

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

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

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

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..

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