daily post

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.