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

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

Test plans are not ONLY to improve quality,

They are also a defense mechanism against – why was this bug not caught

More like a legal disclaimer saying ‘Release at your own risk!’, we’ve done what the test plan says

This behavior leads to adding in fields like the ones shown in the image..

So instead of trying to build a defense like an attorney, let’s try and build a test strategy to which EVERYONE agrees and contributes towards..

Something one of the points I discussed in yesterday’s webinar. If you missed it, you can still register, will put up the recording later.

#RedefiningSoftwareQuality ✔ #QualityTransformation #Testing #TestStrategy

Don’t just ‘understand’ requirements – IRON OUT requirements !

Let me explain..

No one has a clear picture of exactly what we want to build, that is the reason we build iteratively.

Therefore while discussing requirements, engineers are mostly interested in – just tell us what to develop.

The approach instead has to be – let’s ‘brainstorm’ what to develop.

The product owner should have a decent picture of what they expect, but they’d lack technical insights

Plus they CANNOT know everything and most proably have not thought of all the risks / assumptions

It takes different engineers wearing different hats (Dev, test etc.) to point out assumptions & risks BEFORE we lock in what to develop..