Daily Posts

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

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

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

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

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

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

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:

It’s crucial to have a good understanding of how testing and automation practices would look like in an ideal world.

For me that begins with having a quality vision.

You might say, well that should be the same for everyone – catch as much bugs as we can..

IMHO that’s not a good objective though, it’s a very generic target which doesn’t give much direction

Testing goals should be driven from product / business goals, that way what’s important for the business, becomes important for testing.

You can call this your test policy / testing objectives. I prefer using ‘Quality vision’.

So next time you start improving your testing practices, agree as an organization what is most important for the product strategically, and drive your test strategy from there.

Excited to be talking about this and more tomorrow at 11 AM Dubai time at the Test Leadership Congress 2020

#RedefiningSoftwareQuality #QualityTransformation #Testing #TestAutomation

Many engineers don’t use heuristics (guidelines / reference frameworks) to do exploratory testing (commonly referred to – manual testing)

One really good heuristic is – Risk based testing:

For exploring a newly coded feature, if time permits one can spend a lot of time ‘exploring’ and answering what if’s, obviously that’s not advisable.

Often this activity gets time bound by the time engineers can buy, or what is left at the end – and based on their own understanding, try to test whatever they can

Risk based testing allows to take a more holistic & systematic approach in allocating time and answering the question – what is important to test

This is one of the biggest mistakes in testing I see, hardly any thought process going into deciding ‘what should be prioritized to test & automate’.

In trainings I design, we ask engineers to learn and practice the basics of risk based testing BEFORE learning to automate.

#RedefiningSoftwareQuality #Testing #AgileTesting

When planning Program increments or sprints – How do you distinguish between a risk & dependency?

Let me back up here a little ..

If your working with Scaled Agile or any other large scale agile solution – you may have program increments (planning sessions for next 6 – 8 sprints)

If not, hopefully your teams do have sprint planning.

To complete specific tasks, you may have dependencies on some activities to finish first for you to proceed.

Ideally before / or during sprint planning you’d want call out these dependencies and raise them with concerned team / individual.

If the team / individual is not able to prioritize this activity soon enough for you to complete – then this turns into a risk.

Further, any unknowns you might be aware of, but have not been able to analyze should be called out as risks.

These however, are mostly result of inadequate planning and are a sign that this piece of work might not be ready to work on.

#Agile #Planning

Without regular demos a team cannot truly be agile

And for large scale organizations – include system demos

Sprint demos are perhaps the most valuable ceremony (for me at least)

The whole idea behind agile was to get quick feedback from the stakeholders

At the end of a sprint demo, there should be a yay or nay – which should then put the feature out in production, or action items for next sprint to be fixed

What’s even more exciting – System demos

These happen when multiple sprint teams together releasing different components form a larger solution – which ties the whole customer journey

System demos not only demonstrate the system working in a holistic fashion, but also provides excellent visibility into what all the different teams are doing.

Typically these can happen every 3 months (or Program Increment)

#AgileTransformation #ScaledAgile #Scrum

Just completed the slide deck for my talk at Test Leadership Summer, if I have to summarize the key take away that would be:

“Think globally, act locally” – Learned from my MBA

This is the middle ground between the two extremes of test planning:

No planning:
– Teams don’t have a target vision to work towards
– Often teams spend most of their time putting out fires
– In the end not enough synergies are built and no significant progress is made

Too much planning:
– When teams plan every little activity in extreme detail
– Within weeks the plan becomes obsolete because of unforeseen circumstances

Think globally – Have a very clear vision of your target state
Act locally – Have high level plan for few months, and detailed plan sprint by sprint

That way your plan is fluid, and everyone keeps moving in the same direction, towards the target state.

How to get that plan in place, join me to find out more..

https://lnkd.in/ei6xbQc

You’ll find yourself at a time in your career where you are crammed with meetings all day.

And often you might see more than needed people in meetings, some who are there just for ‘FYI’ and not necessarily subject matter experts to contribute

Our CTO Alex Alexander has some good guidelines to help avoid some anti-patterns like this and others:

1. Meetings are not free, schedule them carefully
2. Every meeting should have an objective, outcome and agenda
3. Invite only those who need to attend, not a person more than necessary
4. Attendees come prepared, do constructive discussion which is for that meeting only – Stay on point
5. Meeting ends with a set of actions
6. No meeting should have more than 9 people
7. Try to schedule most meetings for not more than 30 minutes

Make your meetings short and effective..

#AgileTransformation #Productivity

Traditional test case writing practices are extremely inefficient

When I say traditional, this is what I mean:

– After sprint planning, tester goes to his little corner and studies the user story / requirement
– Then based on hunches and how the day at the office was, figures out some test scenarios
– Next go about writing those tests ‘in detail’ and link them to requirements for traceabiility
– Once the feature is marked as ‘ready for QA’ then ‘executes’ the tests
– Then send reports based on the ‘test case execution results’

Next sprint, the PO want’s to try some changes in our user story, and the tester starts the cycle again – or chooses to not go through that hassle and leave the tests outdated.

Now that’s traditional 15 years old stuff – it never worked back then, and certainly does not work today

Then there’s the transformed ‘Agile’ team. In thier mind, since their agile they don’t write ANYTHING – that includes any kind of tests

Now the test coverage depends even more on our tester’s mood swings and the weather outside!

None of these approaches work, and certainly are not efficient of effective.