alikhalid

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

PDCA – Plan Do Check Act..

The old and gold secret to superior quality

Although PDCA’s roots were from TQM, I feel its the same concept of ‘lean’ which has been defined and refined through Agile & DevOps

It’s all about planning ‘enough’, doing what’s important, delivering it and analyzing the results.

#RedefiningSoftwareQuality ✔ #Agile #Lean

Testing does not have to be ‘they’ vs ‘us’.

Traditionally teams talk about what should be done ‘before’ a user story is handed over to testing.

Shouldn’t be that way, if everyone is testing in some capacity, the need to ‘hand over’ wouldn’t be there anymore.

#redefiningsoftwarequality

What is a PR pipeline?

PR (Pull request) pipeline is a CI pipeline to run tests on EVERY pull request.

Let me explain the terms in there:

– CI : Continuous Integration – term used to run jobs to merge code, deploy code, run automated tests and give alerts.

– CI pipeline: A group of CI jobs stringed together to complete a set of activities on any event trigger

– Pull Request : A term used by Git users when an engineer has created some new code on his feature branch and raises a request to merge his / her code with the master branch

– Tests on PR : Tests running on every PR have to be very quick and localized since the application is not deployed at this stage.

Let’s repeat, what’s a PR pipeline?

Tasks & activities that run once an engineer raises a Pull request.

For more details on which tests can run on a PR pipeline refer blog post on #DTMS (link in comments).

Also doing we webinar on #DTSM, again link in comments.

#RedefiningSoftwareQuality ✔ #TestStrategy #DevOps #DevOpsTestStrategyMindmap #TestAutomation

Trying to change behavior – Carrot & stick might help..

Unfortunately most of the time we don’t change until it becomes a necessity (the stick).

That’s why ‘necessity is the mother of all invention’.

Recently I’ve been banging about a specific topic with teams for a while, and somehow still struggle to get buy in.

Once, out of necessity they are being forced to do it and they have no choice, suddenly all the problems are starting to go away.

Take remote work for example. Pre-coivd some folks were hell bent that remote working cannot work.

Now that we all are forced to work from home, suddenly those problems don’t feel challenging anymore.

The ‘stick’ can be many things – a declaration to achieve something, create circumstances to force certain behavior.

Summary:

Preaching, explaining, collaborating is all needed to change behavior – but sometimes so is the stick.

#RedefiningSoftwareQuality ✔ #Testing #Automation #Transformation

Are testing skills and technical skills mutually exclusive?

IMHO:

1. let me start from: being technical does NOT mean being an automation engineer

2. Technical skills would be: Understanding of how your product’s tech stack works, ability to understand the product’s control flow and code base.

3. Having testing skills does not mean you cannot have technical skills or vice versa

I think the problem stems from when we see technical skills and exploratory testing on two opposite sides

To me they are both very related and compliment each other, one SHOULD fuel the other.. therefore:

1. One cannot test a product very well UNLESS they understand the tech stack

2. One cannot develop a great product UNLESS they understand looking at the product from different perspectives..

This argument of testing vs development skills is not helping anyone – ALL ENGINEERS ON THE TEAM SHOULD KNOW BOTH

Yes some would be better at on thing, and might play a bigger role there, but should have the capability of doing both.

That’s why the very first thing I talk about in #RedefiningSoftwareQuality is #TechnologicalExcellence

#RedefiningSoftwareQuality ✔ #Testing #Automation #Transformation

Why do folks assume test automation = people loosing jobs?

I think because elsewhere automation = loosing jobs.. let me explain:

Over the past few decades, to build efficiencies we’ve automated every mundane task we can, and has been growing exponentially ever since

And this is not limited to a specific industry, this has happened all over, finance, medical, manufacturing, services you name it

Mundae tasks that were done by humans, have been taken over by machines, from small things like a bank teller vs an ATM / deposit machines to robotics on a manufacturing assembly line

Subconsciously we end up equating this automation to test automation, and start inferring the same results

However – test automation isn’t actually automating the whole testing process, it’s actually ‘automation in test’

A major portion of testing is exploring, collaborating and thinking compared to checking, which cannot be done by a machine.

#RedefiningSoftwareQuality ✔ #Testing #AutomationInTest #Automation

When starting to get in the habit of writing unit tests, don;t start with an expectation of 80% code coverage ..

I’ve also experienced teams where they start with 80% code coverage, it becomes so difficult to get there at the start

Teams ended up not pushing code to the master branch which caused even bigger problems

Her suggestion was to start with something like all new code should have a decent amount of code coverage, which makes more sense

Writing unit tests sometimes can be tricky, and time consuming without libraries and frameworks to support

It takes a while to get some helping libraries in place, so take it step by step.

Treat it as an evolution, not a revolution !

#RedefiningSoftwareQuality ✔ #QualityTransformation #UnitTesting #TDD

We always say “Quality is a team reponsibility”,

But how do we actually make it everyone’s responsibility?

1. Everyone, that means ‘everyone’. Engineers (dev & test), the PO, Scrum master, end user and everyone in between

2. Every person is affecting quality of the product negatively or positively, regardless if they think they are or not, you’d ask how?

Every person in and around a software product is helping in shaping the outcome, quality is an inherent attribute of what we do & how we do it

3. To make every person (role) feel responsible, they should hands on contribute to quality practices at each stage

4. Dev role engineers write sensible code, do code reviews, pairing on risk analysis, write unit & component tests,

5. POs actively particiapte in designing BDD acceptance tests, test the product from a customer’s perspective

6. Tester role engineers write integration, system integration and other automated tests and to exploratory testing

7. All engineers ensure the pipeline remains green and make it a top priority to fix it as soon as it goes red

A few ways to implement ‘quality is everyone’s responsibility’

#RedefiningSoftwareQuality ✔ #QualityTransformation #DevOps #AgileTesting