Daily Posts

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

Testing starts with a quality vision

By |August 9th, 2020|

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

608, 2020

Risk based testing for exploratory tests

By |August 6th, 2020|

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

408, 2020

Risks vs Dependencies

By |August 4th, 2020|

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

2907, 2020

Sprint & system demos

By |July 29th, 2020|

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

2807, 2020

Think globally act locally

By |July 28th, 2020|

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


2707, 2020

Effective meeting guidelines

By |July 27th, 2020|

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

2507, 2020

Traditional test case writing

By |July 25th, 2020|

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.

2307, 2020

Hire the right people and give them freedom

By |July 23rd, 2020|

There is a lot that goes into building a great team,

IMHO hiring the ‘right’ people and then giving them freedom are key ingredients.

The ‘right’ people may not be just highly skilled, but also have the right attitude and social skills.

Giving freedom is even harder part. But remember, your building a great team to ‘think’ and give you solutions, not so you tell them what to do.

Giving freedom not only leads to good decisions, but also increases ownership in the team

When they are taking decision, then they try their best to make it a success – if you decide on their behalf, there’s less ownership.

And all of that leads to good quality. Ultimately quality is not something you paint on top – it’s the way you build software determines the quality.

#RedefiningSoftwareQuality #AgileTransformation #TeamBuilding #Hiring

2207, 2020

Default to open

By |July 22nd, 2020|

“Default to open” (from how google works by Eric Schmidt)

Many of us designing platforms, gathering information / insights, generating product documentation, source code – the default state is to keep it all secure location

Then we start thinking about giving access on ‘need basis’ and ask people of ‘evidence’ why they need access

At first this may seem like common sense and harmless, but before you know you have all sorts of things under lock and key

Different project source codes, product documentation, analysis, features being developed, CI pipeline test results… and the list goes on

This stifles progress and engineers to do their job well, most of their time then is spent ‘unblocking’ themselves.

The default setting to EVERYTHING should be ‘OPEN’, not ‘CLOSED’.

Engineers in your teams are not hired to do dummy jobs like building walls, they are hired to THINK

And if you want to help them take good decisions, they need to be exposed to first hand information / stats & figures.

To have true autonomy, you should have free flow of information.

#RedefiningSoftwareQuality #AgileTransformation #Transformation

2007, 2020

Agile & positivity

By |July 20th, 2020|

Today I learned positivity has a special place in ‘being’ agile.

Unless your team does not have a positive vibe, they wouldn’t be able to self-organize and be productive.

From my personal experience, when I’m feeling down my productivity starts to dwindle.

For many of us, we are driven by our past experiences and most of us don’t expect really great things at work. We’re just waiting to find something negative and start with our rant.

If we treat “The past as a place of reference, not a place of residence” [1] things would be a lot better.

“The past is a place of learning, not a place of living” [1] – live in the present with a positive attitude!

[1] Roy T. Bennett

#AgileTransformation #Positivity

1907, 2020

Automation run reports

By |July 19th, 2020|

Flakiness kills automation..

The worst team I’ve seen, their scripts flakiness was around 70 – 80% !

With that kind of failure rate, looking at the reports was impossible, so instead they saved ‘error’ messages from the AUT separately and look only at those

That was an extreme, but more than often I see teams having inadequate details in their reports

I’m happy to see over years reporting libraries have improved, still sometimes come across teams not doing it well.

Further on automation test reports in the linked article (first comment)

#TestAutomation #TestReport

1807, 2020

Plan for iterations

By |July 18th, 2020|

Crystallize your target state, but plan for only few weeks ahead..

The mistake I’ve made in the past is to plan every step of the way on how to reach the target state.

Being agile, to me, means have a very clear picture of where you want to go but only plan the steps you’ll take in the next few sprints.

We’re bad at planning and cannot predict very well, so plan just enough.

For this to work, management and the team need a little faith.

You’ll get there, but by taking small steps in the right direction and course correcting, not by planning every step of the way’.

#RedefiningSoftwareQuality #AgileTransformation #Agile

1607, 2020

Testers & programming

By |July 16th, 2020|

Should tester’s learn programming? And is it just for automation?

IMHO, every software engineer should be able to program, and it’s not just for automation,

Rather the ability to understand production code and how the control flow works across the tech stack.

Not everyone has to be a wiz at the whole architecture, but not completely clueless either –

IMHO the justification of: “I test just like the user, hence I have no need of knowing how the product technically works” is extremely wrong

Every software engineer should have the capability to look at code and make sense out of it.

#RedefiningSoftwareQuality #TechnologicalExcellence #Automation #Transformation

1507, 2020

Automation ROI calculated incorrectly

By |July 15th, 2020|

Most common calculation of Automation ROI:

Savings = Manual execution time * no. of times expected to run

Except, this doesn’t give any real value..

These tests we are calculating under time ‘saved’, mostly never get tested!

A lot of times testers just try to fit in whatever they can in the given time duration, and many of these tests just cannot be done

The real value of automation is the quick feedback you get

Instead of regression issues being reported weeks later, devs get instant feedback and takes a lot less to fix the issue.

Automation does save effort, but not in the way we usually calculate it.

Details on this and other ROI calculation aspects in the linked blog post

1407, 2020

Code for maintainability tomorrow, not for releasing today

By |July 14th, 2020|

Don’t write code just good enough for releasing today,

But so it’s usable & maintainable a year later.

There are quite a few short cuts teams take under the pretense of Agile, this is one of them

Agile does not mean to release work which will have to be redone again, or with tech debt

Smaller release cycles never meant bad quality, and yes bad coding practice IS bad code quality

#RedefiningSoftwareQuality #Programming #CodeQuality

1307, 2020

Unicorn employees

By |July 13th, 2020|

Job Seekers, Here’s what I call a “Unicorn employee”:

1. Hands on technical skills

  • Has sufficient technical background and exposure to the job that needs to be done.
  • Ability to demonstrate that knowledge

2. Is a Natural leader

  • Mostly ends up leading people
  • Ability to rally people behind a cause, not through authority, but by motivating them

3. Can communicate

  • Ability to express themselves clearly to engineers and senior management (two very different set of skills)

I know, as engineers we dislike too much talking, or leading people.

From employers perspective: at certain level you need people with these skills, and are extremely rare to find

Unlike unicorns, these people do exist. so:

Become them, search for them, hire them and look after them , they are the drivers of your company.

#RedefiningSoftwareQuality #Hiring #JobSearch #CareerAdvice

1207, 2020

Testing is a Technical skill

By |July 12th, 2020|

“Testing IS a technical skill”, if there is no code involved, does not mean it’s not technical..

There are two extremes, one says testing is a mystical unique art which you are born with, either you have it or not

The other extreme says it’s not really a skill, it’s more of a chore you do, no learning required

IMHO both ends of the spectrum are wrong, it’s a technical skill which MUST be LEARNED and EXPERIENCED in (I call this #TestingAcumen).

So, if your a developer and will be involved in testing activities: testing is a skill you have to LEARN and PRACTICE, you don’t just wing it.

And for testers, more than half of them I meet are horrible at testing. If you’r a tester, just having ‘tester’ in the title does not mean you might be good at testing.

Testing is not an innate gift you were born with. It’s again a skill you have to lean & practice.

I’m all for agile transformation, that’s what I do on a daily basis, but not building your team’s testing skill and hoping your CI/CD is going to do some AutoMagic is a fallacy..

#RedefiningSoftwareQuality #QualityTransformation #Testing #AgileTransformation #DevOps #ContinuousTesting

1107, 2020

Test architect still an alien concept

By |July 11th, 2020|

For teams operating in DevOps ways of working, test code needed to be written sometimes can be as much as production code itself.

Still having someone to build and advise on test code architecture & automation seems like an alien concept to many teams.

I’ll be talking about our transformation journey and developing this role at the #TestLeadershipCongress 2020

Event link

807, 2020

Test Automation KPIs

By |July 8th, 2020|

What would be the most effective test automation KPI?

Few candidates in my opinion:

  • % (Flaky scripts / total scripts)
  • UI tests vs API tests ratio
  • % stories with automated tests for the acceptance criteria (BDD / ATDD)
  • % (Tests running in CI / total tests)

What others can you think of?

#TestAutomation #Testing #KPIs

707, 2020

Writing user stories

By |July 7th, 2020|

There is a lot of good content out there on writing good use stories,

  • Here are few things I try to look out for:
  • Example mapping / Three amigo sessions – VITAL. This will crystallize your acceptance criteria and pointers for tests
  • Ensure the business objective & value is clear
  • Try to assign business value points when possible
  • Estimate relative to other work – Scrum poker helps
  • Definition of Done – Automation scripts, especially on services layer should be a part

The list can surely be longer, with these actions you should be able to write decent user stories resulting in highest value features delivered quickest.

#RedefiningSoftwareQuality #Agile #UserStories #Automation

407, 2020

Agile & documentation

By |July 4th, 2020|

Agile does NOT mean no documentation, most teams run into this trap.

It ‘values’ interactions over documentation – so interact with people then document the decisions from the interaction.

For instance, defining service contracts – white board the points, producers and consumers discuss what’s needed,

And after decision is made, then ‘document’ it.

#RedefiningSoftwareQuality #Agile #Testing

307, 2020

Coding doesn’t take much time

By |July 3rd, 2020|

Coding a feature is not the bigger problem –

It’s everything ‘around’ that development is what’s hard:

Effort that goes into:
– Making sure we’re building the right thing,
– Adequate testing of what’s developed
– Automated checks to test the functionality across tech stack
– Infrastructure to support development and testing
– Automating deployment across environments
– Observability & alerts to detect any anomalies

So you see, it’s not just ‘writing production code’ anymore. To be truly agile and having DevOps practices there is a lot more that has to be done.

#RedefiningSoftwareQuality #Transformation #DevOps #ContinuousTesting

207, 2020

Automation training start with learning testing

By |July 2nd, 2020|

Automation training doesn’t start with learning automation tools,

It start with learning testing fundamentals!

Learn what to test, where in the tech stack to test and how to test.

Next we can talk about what to automate, where and how.

The unfortunate part of many folks lerning automation – their training starts and ends with Selenium

And I say this all the time, you cannot pick a worse place than Selenium with Java to begin with.

Nothing against Selenium or Java, brilliant library & language but that’s not the starting point.

Most people feel what they lack is automation skills, unfortunately often engineers lack “Testing skills”.

If that’s not fixed, you’ll get garbage in and garbage out.

#RedefiningSoftwareQuality #Testing #Automation #TestAutomation #ContinuousTesting

Load More Posts
Go to Top