alikhalid

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