Daily Posts

Daily Posts2018-05-15T15:19:35+05:00
1709, 2020

Test plan’s fine print

By |September 17th, 2020|

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

1509, 2020

Iron out requirements

By |September 15th, 2020|

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

1309, 2020

PDCA

By |September 13th, 2020|

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

1209, 2020

Them vs Us

By |September 12th, 2020|

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

1109, 2020

What is a PR pipeline

By |September 11th, 2020|

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

1009, 2020

Carrot and Stick

By |September 10th, 2020|

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

709, 2020

Testing & technical skills mutually exclusive?

By |September 7th, 2020|

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

209, 2020

Test Automation equals job loss?

By |September 2nd, 2020|

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

109, 2020

Starting with unit testing

By |September 1st, 2020|

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

3108, 2020

Quality is a team responsibility

By |August 31st, 2020|

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

2908, 2020

Testing future technologies

By |August 29th, 2020|

We have a very unique emerging industries like Immersive reality & human enhancement.

How to prepare to test these products?

IMHO there are three values engineers (yes engineers, not testers) must embrace to test well:

1. Technological excellence – having in depth understanding of the technology they are working with, not the business rules – the technology

2. Testing Acumen – Learn techniques to explore, collaborate, identify & communicate risks. You don’t just ‘wing it’, this is an art which has to be learned

3. Business value – Understanding how the product will help the customers, what is of strategic importance to the business and translate those into technical goals

I believe adapting these are three values will drive excellence in any software product.

#RedefiningSoftwareQuality ✔ #EmergingIndustries #Testing #Quality

https://atelier.net/strativerse/

2708, 2020

Regression in the DevOps world

By |August 27th, 2020|

Regression testing is not a phase in SDLC (at least not anymore)

Regression should be happening at multiple levels across the development process.

In a waterfallish setup, you’d typically have a few days where teams try to execute all ‘regression’ test cases

While there are a lot of things wrong with that picture, I want to focus only on what we call ‘regression testing’

In simple terms, all functionality we want to check & see if it’s still working after changes we’ve made – that’s regression.

In a DevOps culture, there should be decent automation in place, at unit, integration & System integration level.

All these automated tests are ALSO REGRESSION. Yes, a unit test which is important for us to ‘regress’ on is regression. I don’t know how come UI tests became synonymous with regression.

So holding on to that behemoth set of test cases which are supposed to be run ‘just before release’ is not efficient

And if that’s happening in your team, I wouldn’t be surprised if testing is considered a bottleneck.

#RedefiningSoftwareQuality ✔ #Testing #TestAutomation #RegressionTesting #AgileTesting

2608, 2020

Managing Tech Debt

By |August 26th, 2020|

Tech debt is a killer, if you keep accumulating and don’t have a plan to manage it – you’ll end up having a product refactor few years later.

And this doesn’t happen in few days, it’s usually a culmination of bad practices over a period of time.

First mistake –

The problem starts with incurring tech debt in the first place. Anything that is supposed to be done as part of that story, should be in your Definition of Done (DoD)

If that discipline is not there, teams end up incurring a lot of tech debt without even realizing.

Second mistake –

Let’s assume the DoD is good and something is dropped (e.g. writing automated tests), often it’s just left saying we’ll come back to it when we have time.

Instead, a tech debt story should be created to track this and must be prioritized instead of adding to a long list of tech debt. (I’ve seen 1000+ tech debt stories..)

Finally –

Have some capacity reserved to take up tech debt every sprint.

Mostly its a struggle to prioritize tech debt. Sometimes it helps to just say 20% capacity (for example) has to be allocated to tech debt every sprint.

What else do you try to mitigate tech debt?

#RedefiningSoftwareQuality ✔ #Prioritization #SprintPlanning #TechDebt #Agile #WaysOfWorking

2508, 2020

Technical Test Leadership

By |August 25th, 2020|

“Technical Test Leadership” – That’s what most teams need.

This is what my talk was about at #tmatlc2020 conf last, let me explain the term briefly:

Technical – Provide technical leadership to the teams. Have in depth understanding of the technology stack, best practices to develop automation frameworks & enablers

Test – How quality engineering works in the Agile world, understands testing and how to do it well

Leadership – Facilitate teams to build mastery & autonomy and let them do the magic

A high level summary of the talk is given in the linked post (first comment)

#RedefiningSoftwareQuality ✔ #QualityTransformation #Leadership #TechnologicalExcellence

2408, 2020

Alternate view of Automation ROI

By |August 24th, 2020|

An alternative way to look at Automation ROI:

1. How many people are using the automation results
2. Ownership of automated tests running in the pipeline

This was shared by Melissa Tondi today at a Tech talk session organized at Emirates, I was so happy she accepted the invitation.

She shared her experience around Quality engineering in the DevOps world, and what an amazing session it was, I’ve been getting messages the whole day about the session!

Back to ROI, we usually calculate it by saying how many hours saved, which I’ve always had an issue with

I liked the idea to step away from ‘hours saved’ and focus on utility & adoption of automation.

It’s about time we stop having to prove automation is needed, and instead focus on measuring: ‘is it helping us’.

If automation is an integral part of our decision making process, and a failure there is treated like the ‘Andon cord’, then it’s working or us!

#RedefiningSoftwareQuality #TestAutomation #QualityEngineering

2308, 2020

Ready to test the future?

By |August 23rd, 2020|

Are we ready to test products of the future?

With advancements in very diverse and new industries, the problem of maintaining their quality identifying risks is challenging.

Industries like Virtual Reality, AI / ML, Human enhancements, block chain are different than products we are accustomed to test.

IMHO being good in developing new heuristics to test these products and identification of risks would be very much needed.

A great link shared by Anna Royzman at the #tmatlc2020 #keynote showing how different industries are progressing (link in first comment).

Do you think we are ready to test product of the future?

#RedefiningSoftwareQuality #SoftwareQuality #testing

2108, 2020

Remote work tip – Over-communicate

By |August 21st, 2020|

An important tip on working remotely:
Over communicate – 85% communication is body language which is missing on an online call
I’ve worked both sides in off shore world which taught me a lot, and one of the biggest challenge was communication
It was always so easy to mis-understand what is being said. A lot of my time was spent in clarifying what the ‘intent’ of the message was
A big reason was due to lack of physical interaction, and that’s how I realized the importance of body language
That’s why at least few times a year meeting everyone made a big difference and took care of a lot of unnecessary back and forth
To compensate for that missing 85% communication:
  • Keep the camera on where possible
  • Go the extra mile to give background on your message – use more words
  • Communicate more often and frequent
  • Try harder in building a relationship – lots of things just go away by building trust
#Communication #RemoteWork #COVID19
2008, 2020

Eliminate waste

By |August 20th, 2020|

As a leader, one of the most important things to do is help eliminate waste

That means a lot of things:
– Prioritizing what’s important to focus on first
– Building infrastructure to do mundane tasks in a more automated fashion
– Removing impediments blocking the teams

We all have fixed capacity – 24 hrs in a day, and specific hours at work

So we move faster not by adding more hours, but importantly by working on what’s important and not have to waste time

#AgileTransformation #ServantLeadership #Productivity

1908, 2020

Leverage automation everywhere

By |August 19th, 2020|

While designing our automation training program, initially I was focused more on getting the learning path & content perfect..

I was forgetting the operational effort to run it all, few good suggestions I got were:
– Try to avoid workshops and try to use / create online courses as much as possible
– Try to automate the quizzes checking & delivering results

Took some time to develop all of it, but now we’re able to do a good potion of things automatically and saves a lot of time.

The point I’m trying to make: Automating tasks is not a new concept and is not limited to just test automation, it applies to almost other every thing we do in our lives

As engineers, we need to always try and leverage automation for even smaller activities

Freeing up your time even a few minutes here and there frees up your time to do ‘thinking’ work and less ‘remedial chores’

#Automation #Leverage

1708, 2020

Collaborate to build test strategy

By |August 17th, 2020|

Getting consensus around a test strategy is done best by designing it in collaboration with the team.

Sometimes the most experienced person in testing or software quality is given the responsibility, They’ll put together a strategy based on best practices they feel should be followed

The problem:
1. There is no shared sense of responsibility across the team, which makes this ‘my’ test strategy, not ‘our’ test strategy
2. The best practice we thought of might not always be the most appropriate
3. The target vision should be set, however how to get there will be an iterative process, is should evolve collectively as we move along

I prefer to set a target vision of where we want to be. The steps to get there will be taken:
1. Collaboratively
2. One step at a time
3. And the approach will evolve as we test and learn

Improving your quality engineering processes is going to an ‘evolution’, don’t make it a ‘revolution’ !

Just an hour left in the panel discussion I’m joining to tall about ‘Communicating Test Strategies’ followed by my talk on Transformation and the role of test leadership at #tmatlc2020

#RedefiningSoftwareQuality #QualityTransformation #TestStrategy #AgileTransformation

1608, 2020

Transformation an art & science

By |August 16th, 2020|

I feel transforming team’s behavior is both an art and science.

A science since it helps to learn processes to facilitate test & learn new practices and build technical enablers

An art because transformation has a lot to do with changing human behavior

Improving quality engineering & testing practices is the same, it’s a science and an art.

You only get better with using some systematic structure & practice, also you’ll always face new challenges which you might not have come across before.

Attached slide shows a few points you might want to consider on your transformation journey. (from my talk at the #tmatlc2020 conference)

Event link in first comment

#RedefiningSoftwareQuality #QualityTransformation #AgileTransformation

1508, 2020

Quality dimensions

By |August 15th, 2020|

Data engineering & data science have unique problems,

A big one is validating data ingested into the pipeline.

It so often happens that data being ingested is not as per expectation

There are generally 6 broad categories classifying the different problems you may have, called data quality dimensions.

To ensure he quality of your data models and analytics, its vital to validate quality of the data BEFORE any processing happens.

Reference video linked below

#RedefiningSoftwareQualiy #BigData #DataScience #DataAnalytics

1408, 2020

Getting ideas in risk based testing

By |August 14th, 2020|

Exploratory testing is supposed to be unscripted, but that does not mean one shouldn’t use any patterns / heuristics to ‘explore’ better

There are a couple of techniques you could use, risk-based testing is one of them.

There are quite a few recommended practices & activities, one of the I learned recently was to ask others to give their suggestions.

Think of ideas like a tree with fruit, we have a couple of methods to get that fruit, but sometimes shaking the tree also helps

In our context, it’s about getting those untapped ideas which I might not be considering

A good way of doing that is to get help from a person or group of people in a time-boxed session:
– Provide some context to the problem
– Some oracles and reference material
– Giving a time-boxed window to think about all possible risks

Often you might come across some which you might not have think of.

Nothing novel here, but ‘collective’ thinking like this had not been a priority for me before.

Reference link in first comment

1208, 2020

Non-practical test strategy headings

By |August 12th, 2020|

Traditional test strategy documents have some very non-practical headings

The one I find most amusing is ‘entry – exit’ criteria

In the world of continuous testing, – well testing is continuous, testing is not just one phase anymore..

TDD / unit tests, component tests, integration tests, contract tests.. all these are no longer phases / JIRA ticket stages an item goes through

Many of these should just be a part of your pipeline and would run automatically. If it fails,the pipeline goes red, that’s it!

So the question of having an entry & exit criteria of the testing phase is completely irrelevant.

Even with a bit waterfall’ish processes, how many times did your team enter a testing phase and exit a testing phase as described in the strategy doc? I wrote those docs a couple of times, I didn’t always look back at them..

Test strategies have to be leaner with topics the team actually can follow.

Any other typical headings you’d call out?

My version of a test strategy linked below

#RedefiningSoftwareQuality #DevOpsTestStrategyMindmap #Testing #QualityEngineering

1108, 2020

Innovation and Planning (IP) sprint

By |August 11th, 2020|

Don’t plan activities for your Iteration & Planning (IP) iteration, it’s meant for other activities.

Let me explain:

In Scaled agile, sprints / iterations are clubbed into ‘Program Increments’ (PIs), typically span over 6 sprints.

Priorities, dependencies for the whole PI are planned in what is called PI planning

In a PI, the last sprint is usually called an IP sprint

Typical activities in an IP sprint are to:
– prepare for system demo,
– Inspect & adapt workshop (Retro for the PI),
– Continuous education & learning,
– Pre-PI planning activities

Therefore it’s not a good practice to plan work in the IP sprint and you might want to reserve that capacity for above mentioned activities.

More here:

Load More Posts
Go to Top