alikhalid

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/

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

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

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

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

• 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

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

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