Ultimate Guide to Reducing the Amount of Defects and other Waste in your Product

What’s a defect? I like this definition.

A defect is anything that threatens the value of the product.

Before we start, let’s agree that:

  1. we don’t want to defects that threaten the value of our product
  2. we want to give our customers as much value as possible at all times.

If you don’t agree with 1 and 2 then, don’t waste your time and stop reading now.


Software defects aka Bugs

Testers are normally associated with finding defects. Some testers get very protective with the defects they find and some developers can be very defensive about the defects they wrote. Customers don’t like defects, developers don’t like defects, product managers don’t like defects, let’s be honest, nobody likes defects besides some testers.

Why would that be? The reason is that the focus of a lot of testers is on detecting defects, and that’s what they get paid for in a lot of organisations. If you are a tester and love your defects, you might find this article disturbing, if you decide to proceed, do so at your own peril.


Defects are waste

Let’s be clear from the start: defects are waste. Waste of time in designing defective products, waste of time in coding defective routines, waste of time in detecting them, waste of time in fixing them, waste of time in re-checking them. Even writing this sentence took a good while, now think how much time it takes you to produce, detect, fix, recheck defects.

Our industry has developed a defect coping mechanism that we call defect management. It is based on a workflow of detecting => fixing => retesting. Throughout the years it has become best practice (sic) to have defect management tools and to log and track defects. Defect management approaches are generally cumbersome, slow, costly and tend to annoy people no matter whether you are a tester that gets his defect rejected, you are a developer that gets a by design feature flagged as defect, or a product manager that needs to spend time prioritising, charting and trending waste.

Another dangerous characteristic of defects is that they can be easily counted and you will always find a pointy haired manager that decides he is going to shed light on the health of his product and on the efficiency of his team by counting and drawing colorful waste charts.

But, if we agree that defects are waste, why are we logging and tracking waste, creating waste charts seems even more ridiculous, wouldn’t it be easier to try to prevent them?

Oh, if only we could write the right thing first and reduce the number of defects we produce! I say we can, be patient and read on.

Software development teams have found many ways of being creative playing with defects, see some examples below.

Example 1: Reward waste

Reward for the wrong reason

Reward for the wrong reason

Some years back I was working on a business critical project in one of 5 scrum teams . Let me clarify first, that our scrum implementation was at best poor, we didn’t release every sprint and our definition of done was questionable.

Close to an important release, we found ourselves in a situation where we needed to fix a lot of defects before going into production. We had 2 weeks and our teams had collectively around 100 defects to go through. Our CTO was very supportive of the defect killing initiative and he was eager to deliver with zero defects. He put in place a plan that included free food all day and night and some pampering for the developers that needed to focus 100% on defect resolution. Then he decided to give a prize to the team that would fix the highest amount of defects.

I remember feeling frightened of the possible future consequences of this reward. I spoke to the CTO and told him that I would have liked more a prize for the team that produced the lowest amount of defects rather than the one that fixed the most. Our CTO was a smart guy and understood the value proposition of my objection, he changed his approach and spoke to the teams on how not introducing defects in the first place is much more efficient than fixing them after they have been coded. Soon after the release, we started applying an approach that focussed on preventing defects rather than fixating on detection. We never had the problem of fixing 100 bugs in 2 weeks again.

A typical defect prioritization meeting

A typical defect prioritization meeting

Example 2: Defects metrics

In my previous waterfall life, I remember when management introduced a performance metric directly linked to defects. Testers were to be judged on the Defect Detection Index calculated as (Number of Defects detected during testing / Total number of Defects detected including production)*100. An index lower than 90 would mean nobody in the test team would get a bonus. Developers were individually judged on the number of defects found in their code by the testers and business analysts were individually judged on the number of defects found by the testers in their requirements.

Welcome to the battlefield!

The bug prioritisation meetings were battles where development managers argued any bug was a missed requirement, product managers argued that every bug was a coding error or a tester misunderstanding and the test lead (me) was simply shouted at and criticised for allowing his testers to go beyond the requirements and make use of their intellectual functions outside a scripted validation routine.

Going to that meeting was a nightmare, people completely forgot about our customers and simply wanted to get their metrics right. The amount of time we wasted arguing and defending our bonuses was astonishing. Our customers were normally unhappy because instead of focusing on value delivery we focussed on playing with defects, what a bunch of losers we were!

Our customers were very unhappy.

Example 3: Defects as non-conformance to requirements

Let the nitpicking season start

Let the nitpicking season start

In the same environment as Example 2, testers, in order to keep their Defect Detection Index high used to raise large amounts of minor or non-significant “defects” that were in reality non-conformance to requirements. Funnily enough such non-conformances  were generally improvements.


Testers didn’t care if they were requirements, code defects or even improvements, to them they were money, so they opened them. Improvements were filed as defects as they were in non-conformance to requirements. In most of the cases, these were considered to be low severity and hence low priority defects to make the testers happy and had to be filed, reviewed, prioritised and used in trends, metrics and other useless calculations.

This activity could easily take 30% of the tester time. Such defects would not only take testers’s time, but would also affect developers, product managers, business analysts and eventually clutter the defect management tool.

Waste that creates waste, exponentially, how wonderful.

A colourful dump

A colourful dump

 Example 4: Defect charts, trends and other utter nonsense

Every week I had to prepare defect charts for management. These were extracted from our monstrous defect management tool and presented in brightly coloured useless charts. My manager got so excited at the prospect of producing useless information that she started a pet project to create charts that were more colourful than the ones I presented. She used 2 developers for 6 weeks to create this thing that was meant to wow the senior executives.

In the process of defining the requirements for wowing the big guys, she introduced a few new even more useless charts and consolidated it into an aggregating dashboard. She called it the product quality health dashboard, I secretly called it the dump.

Nobody gave a damn about the dashboard, nobody used the numbers for any reason, nobody cared that they could configure it, but my boss was extremely proud of it. A legend says that she got a big raise because of it. If you play with rubbish, then you will start measuring rubbish and eventually you will end up doing data analysis and showing a consolidated view of the rubbish you store in your code.

How can we avoid this?

1. Focus on defect prevention

Many development teams focus on delivering features fast with little consideration for defect prevention. The theory is that testers (whose time is sometimes less expensive than developers) will find the defects that will be fixed later. This approach represents a false economy; rework disrupts developers activities and harms the flow of value being delivered. There are many approaches available to development teams to reduce the amount of rework needed.

Do you want to prevent defects? You can try any combination of the below:

  1. With BDD/ATDD/Specification By Example or other test first approach, delivery teams test product owners assumptions through conversations and are more likely to produce the right feature the first time.
  2. The ability to have fast feedback loops also allows for early removal of defects, automated unit and integration tests can help developers quickly identify potential issues and remove them before they get embedded into a feature.
  3. Tight collaboration between business and delivery teams helps teams be aligned with their real business goal and reduce the amount of unnecessary features. This means less code and as a consequence less defects. Because, your best piece of code is the one you won’t have to write.
  4. Reducing complexity is very powerful in preventing defects, if we are able to break down a complex problem in many simple problems we are likely to reduce the amount of defects we introduce. Simple problems have simple solutions and simple solutions have less defects than complex ones.
  5. Good coding standards like for example limiting the length of a method to a low number of lines, setting limits on cyclomatic complexity, applying good naming conventions to help readability also have a positive impact on the number of defects produced
  6. Code reviews and pair programming greatly help reduce defects
  7. Refactoring at all times also reduces defects in the long run

Moral of the story: If you don’t write defects, you will not have to fix them.

2. Fix defects immediately and burn defect management tools

If like me years back, you are getting tired of filing, categorising, discussing, reporting, ordering defects I have a very quick solution. Fix the defects as soon as you find them.

It is normal for a developer to fix a defect he finds in the code he is writing as soon as he finds it without having to log it, but as soon as the defect is found by a different individual (a tester for example) then apparently we need to start a strict logging process. Why? No idea really. People sometimes say: “if you don’t do root cause analysis you don’t know what you are doing, hence you need to file the defects”, but in reality nobody stops you from doing root cause analysis when you find the defect if you really want.

What I am suggesting is that whoever finds a bug walks to a developer responsible for the code and has a conversation. The consequence of that conversation (that in some cases can involve also a product owner) should be let’s fix it now or let’s forget about it forever.

Fixing it now, means normally that the developer is fresh on the specific code that needs to be fixed, surely fresher than in 4 weeks, when he won’t even remember he ever wrote that code. Fixing it now means that the issue is gone and we don’t have to worry about it any longer, our customer will be thankful.

Forgetting about it forever means that it is not an issue worth fixing, probably it doesn’t threaten the value of the project and the customer won’t care if we don’t fix it. Forgetting about it forever also means that we won’t carry a stinky dead fish in a defect management tool. We won’t have to waste time re-discussing the same dead fish forever in the future and our customers are happy we are not wasting time but working on new features. If you decide to fix it, I’d also recommend you write an automatic test for it, this will make sure that if the issue happens again you’ll know straight away.

I have encountered huge scepticism when suggesting to burn defect management tools and fix just in time. Only very few seem to think this is possible. As a matter of fact all my teams were able to do this for the last 6 years and nobody ever said, “I miss Jira and the beautiful bug charts”.

Obviously this approach is better suited for co located development teams, I haven’t tried it yet with a geographically distributed team, I suggest you give it a try and let me know how it goes.

Playing with defects waste index:


Epidemic: 90% – The only places that don’t file and manage defects I have ever encountered are the places where I have worked and have changed the process. In the last couple of years, I have heard of two other places where they do something similar but that’s just about it. The world seems to have a great time in wasting money filing, categorising, reporting, trending waste.

Damaging: 100% – Using defects for people appraisal is one of the worst practices I have ever experienced in my long career, the damage can be immense. The customer becomes irrelevant and people focus on gaming the system to their benefit. Logging and managing defects is extremely wasteful as well, it requires time, energy and can among other things, endanger relationships between testers and developers. Trending and deducting release dates from defect density is plain idiotic, when with a little attention to defect prevention defects would be so rare that trends would not exist.

Resistant: 90% – I had to leave one company because I dared doubt the defect management gospel and like an heretic I was virtually burned at the stake. In the second company I tried to remove defect management tools I was successful after 2 years of trying, quite resistant. The third one is the one where people were happy to experiment and as soon as they saw how much waste we were removing it quickly became the new rule. I have had numerous discussions with people on the subject and the general position is that defect management must be done through a tool and following a rigid process.

Because “that’s the way we do things here!”

Recommended Reading

Lean Software development – An Agile Toolkit (Mary and Tom Poppendieck)



This is a reviewed and improved version of an article I first wrote in 2015 (old version here)

How a highway car wreck can help us improve collaboration

A knowledge worker’s tale 5th episode.

Things were getting better, the headless chickens that were once running around were a memory of the past and the good folks of team X were now concentrating on a few work items at a time. The frenetic pace had turned into something much more sustainable and people had time to think about what they were delivering.

It had been more than 2 weeks since Gus had been with the team, one morning he decided to pay Team X a visit. When he arrived at their open area, he noticed a strange dynamic. Rick and Jane the testers were huddled over Ricks desk clicking and typing frantically while speaking hurriedly with a worried tone. Ther rest of the developers were sitting at their desks, with headphones on, not a worry in their life.

Gus didn’t even need to ask Rick and Jane what was going on when he looked at their kanban board and saw five cards in the “exploratory testing” column. The team had a WIP limit of five, that meant that those were the only cards on the board.

“Oh Damn!” Gus thought, “non-testing developers alert…”

Gus walked to Rick’s desk and asked “Hi guys, how can I help you?”. Rick immediately goes “Not sure Gus, we are behind with testing and must finish this stuff now, we’re blocking development, they can’t pick any new cards”

“Oh wow” Gus said “developers must be going crazy with you, you are blocking them”, he said it again, louder, making sure that the rest of the team heard him “DEVELOPERS MUST BE GOING CRAZY WITH YOU, YOU ARE BLOCKING THEM”. The ones not wearing headphones realized something was going on, turned and asked what the problem was.

Gus looked at Mike, the senior developer and said “Mike, would you please tell your temporarily hearing-impaired colleagues to follow me to the board, please?” Mike poked his headphone-loving colleagues one by one and told them to follow Gus to the board.

Gus pointed at the board and said “what do you see?”. Silence. “I see 5 cards in a column” Gus continued, “what does that mean?”
Peter , a junior developer, went “well there are 5 cards that need exploratory testing and they’ve been there for a while, this means that we can’t pull any new cards because the WIP limit is 5 and testers are blocking everything”.

“Very interesting” said Gus “well, allow me to retort, what I see is a team that doesn’t understand what flow is. I think that we need an example with something you are all familiar with, like driving in traffic”.

The team moved closer to the side of the whiteboard that they used for drawing flows and sketching UI elements, Gus started drawing parallel lines on the board and continued.

“Imagine you are driving on a highway, three lanes, you are doing 100Km/h and there are a few other cars but it flows very well, you will be home in time for the football game you really want to watch.  All of a sudden 10 Kilometers in front of you an accident occurs and from the original 3 lanes, now only 1 is free for cars to go through. What do you think will happen?”

“The cars close to the crash slow down to fit in the only free lane and a long queue develops” says Mike. “Very good” Gus continued “you are 10 Km behind, you slow down to 20Km/h then down to 5 and that’s your speed for the 10 kilometers up to the accident”

“How come you can’t go 100 km/h any longer? The reason is simple, you are as fast as the slowest point on the highway. You could have 100 lanes instead of 3 now, but you’d get out of the bottleneck always at the same time.”


“How would you fix this problem to make sure you make it home for the football game?”

“Well we need to get a truck to take the crashed cars out of the lanes, we need to unblock the bottleneck” Peter quickly goes.

“Very good” Gus goes “the same principle applies to your kanban board, you people are the highway lanes, and the cards coming through are the cars. There is a bottleneck because we have only 2 people working on the full stream of cards”.

“You guys leaving Rick and Jane working on the full stream of work has the same effect of the car accident that leaves 1 lane only in the highway.”

Gus paused, let the people observe the 2 boards, the one with their work and the one with the picture of the traffic jam that Gus had drawn. Then he asked.

“Do you understand that?”

Mike, then Peter than the rest of the team nodded and agreed. “How do we fix this Gus?” Mike asked.

“In this case, there is a simple way of resolving the problem, we remove the car wreck from the highway and we add lanes to remove the bottleneck, how would you do that Peter?”

Peter looked at the 2 pictures a couple of times, he was a smart kid, young but smart, he wasn’t going to give the wrong answer. After 30 seconds, he went

“Well to add lanes it means that the rest of the team needs to help Rick and Jane with what their cards until the backlog of cards is gone and the flow can continue. But this can’t make sense, I am not a tester, Rick and Jane are testers, I am a developer”

Gus swallowed hard, paused for 10 long seconds of total silence and said “Folks, for the moment let’s start like this, all of you guys go into a room with Rick and Jane where they will explain what needs to be done. Once you are up to date, you will help and assist in any possible way they want you to help until the bottleneck is gone. When the bottleneck is gone and flow is re-established we will have a chat about who tests, who develops and what being a cross-functional team means.”

“But I am a developer, I don’t test” said Peter. “Come on Peter, this is an emergency, don’t you see? There is car wreck on our board, we got to clear the lanes, this is making our customers wait? We’ll talk about responsibilities later” said Mike

It sounds like we will have an interesting conversation, Gus thought.

Read until you find it, it’s subtle


How will the conversation go? Will Gus manage to convince the developers that they need to help with testing? Will Peter win and get to write code only? Stay tuned and find out in the next episode of “A knowledge worker’s tale”


Ultimate guide to use metrics to distract your teams and destroy your company

I have had a lot of conversations, with agile people and not, around the topic of measuring success of an agile team. I have heard all sorts of metrics thrown around, from velocity, throughput, number of bugs or lack thereof, and so on.

The fact is that those metrics are completely useless, let me tell you why.

Imagine that your team in a period of 3 months has increased its velocity from 24 to 48. What does that mean? Some people will tell you they are 100% better or even 100% more successful!

I say that they are 100% better at delivering stories (assuming they didn’t game the metrics)

More than likely they work in an organisation that measure success based on the old Budget-Time-Scope paradigm.

Unfortunately in your search for speed you are sub-optimising your system and not achieving the real goal of your company.

A team that bases success on the Budget/Time/Scope triangle I call it BuildEverythingFastAndPray)

What is a successful team?

A team is successful if they help the organisation they serve be successful, regardless of how many story points they deliver.

Let me tell you what a successful team measures.

A successful team measures business outcomes. What are business outcomes? Let me give you some examples:

1) x% increase week to week on downloads of your mobile app
2) y% increase in signups month to month
3) z% reduction of customer support calls month to month

or any similar outcome depending on your context where x,y,z>0


Because an organisation that obtains those outcomes is normally successful.

Even more importantly, the team will continuously monitor how their actions affect the business outcome metrics they have set to achieve so that they might decide to:

  1. Stop writing that feature, we have obtained the result and any further bell and whistle wont give us ROI
  2. Do more of this, the metrics are going in the right direction but not as expected
  3. Stop doing this and do something else, this feature is not producing the results we were expecting
  4. Ah, look at what the customer is doing instead of doing what we thought he would do! Let’s help them do it in an easier way…



Build Measure Learn

Now compare this to delivering all the 1 zillion stories in the fixed scope at the velocity of 48 per sprint.

What’s a successful team for you?


A short report on my agile experimental talk

Last week I asked the community for help on designing an agile talk rather than a talk on agile .

If you don’t want to read the full article here’s the TLDR: Can we embed the agile values in the format of a beginners talk so that people will learn by breathing them rather than hearing about them?

I received quite a lot of encouragement from a lot of people. I love the agile/lean community, thank you folks, you are incredible!

I got some great suggestions from Patrick Steyaert that recommended looking into Lean Coffee and Fish Bowl.

Both formats are highly participative and pretty much agendaless and gave me a great point to start at.

My goals in priority order:

  1. Do not bore an audience that for the first time hears about agile. Don’t push them away!
  2. Identify a format that embodies the values I believe to be the most important in agile and make sure the attendees feel and recognise them while they are attending
  3. Make sure people actively participate
  4. Have fun

To me the most important values in agile are: people, customer and responding to change.

The People

I asked 3 fantastic practitioners to help me on the day. The 4 of us were “the agile product team” that was going to deliver the product (learning) to our customers (audience)

Thank you so much to Claudio Perrone, Andrea Baker and Lisa Hickey for accepting to help with less than 24 hour notice and no details whatsoever on what i needed them to do (isn’t this ability to respond to change? :-))

my teammates.png
My Fantastic Team Mates: from left to right Claudio, Andrea and Lisa

The Customers

I told the audience that me and my team mates were going to give a product to them, they were our customers and as such they were extremely important.

To start we needed the customer help to understand what real value is to them.

We asked them to select with dot voting some agile topics from around 35 different agile topics (I took a subset including mainly basic concepts).

The topics were taken from ‘s wonderful Agile Topics card deck that I printed and laminated (for the quite steep price of €50)

The customers immediately queued towards the table where the cards and the markers for voting were. We time boxed the activity to 5 minutes. Claudio, ever the lean man,  immediately identified a bottleneck as the table was too small and only 2 to 3 people could vote at the same time.

Customers queuing to dot vote (bottleneck)

The activity had to be extended to 6 minutes to allow everybody to vote.

The team took 6 topics with highest number of votes and put them on the wall in dot voting ranking order.

We started with the first topic.

It happened to be BDD: First thing, I asked the customers if they knew what it was. One of the people in the audience started giving us his take. When he finished, I spoke about it a bit, then my 3 team mates took turns in adding their perspective.

Responding to change

This lasted for 5 minutes when the timer went off and i asked the audience to tell us by using thumbs up or down whether they wanted to continue talking for 5 more minutes about BDD or if they wanted to move to the next topic.

People voted for sticking to BDD for 5 more minutes

After 5 more minutes we voted again and we went to the second topic.

We made sure that the team swapped activities, everybody took turns in talking about the topics, we alternated roles like time keeping and pulling the cards from the wall.

We wanted to show team collaboration and cross functional abilities.

The topics selected by our customers

I got loads of feedback from the people in the audience and the team.

Claudio suggested that when talking about topics, the first couple of sentences need to describe it in a easily understandable recipe format, this is true in particular because of the audience low level of agile knowledge.

Davide Lovetere an enterprise Architect among our customers gave me a lot of incredibly valuable feedback around some contradiction in terms he had noticed during execution.

Other customers said that they enjoyed the format and want to use it for some of the meetings they do in work (yay!)

Other customers said that they enjoyed it but it finished too early, we only had time to talk about 4 topics and they would have loved to touch more

That’s me having a ball as usual when I speak at conferences🙂

I loved doing it, received valuable feedback to improve it and can’t wait for the next time!



5 Easy steps for Testers to Influence Developers

nobodylistenstomeA classic problem for testers in agile contexts is the fact that they feel they are not listened to by developers. Testers, often rightly, warn developers from doing stuff because the consequences could be very bad, but developers in many cases don’t listen to them.

This is very upsetting, testers find themselves lonely within an agile team because of this. They get frustrated and if they keep on asking and screaming their needs they risk being alienated by their team members becoming completely ineffective while growing dissatisfied with their job.

But, but, they are right in telling the developers what to do! WTF?

When working as a tester in an agile team you’ve got to develop a skill that before you really didn’t need that much.

It is called influencing. Before when you worked in your separate QA department/test team you didn’t need it because there was a test manager that was fighting the battles for you and deciding the test strategy to be applied.

Things have changed, you’ve got to become good at influencing.

This is what Gus did when he moved to an agile team as a tester many years ago.

First I tried barking orders, screamed and shouted, but it din’t work at all, so I decided to adopt a different approach.

  1. I started to really listen to what developers said instead of listening for finding gaps in their thought
  2. I listened and listened and listened a bit more
  3. Third I started asking questions showing real interest in what they were doing. Being mindful of their fears and feelings. I made sure they knew I was there to help and that we were all in the same boat
  4. I started praising them when they did something good, for example thanking them for adding testability to the application. Things like “without Roberto’s design I would have spent weeks doing what I can do now in 10 minutes, thank you so much Roberto, you made my life better”
  5. I started coaching them on how to test by testing with them. When they saw what testing really involved, they understood its importance and challenges and started asking interesting questions about it.

Who will developers listen to?

Now compare the developers’ reaction when faced with a suggestion raised by Gus to the one that Jack gets. Jack is a tester that uses the classic approach of “what the hell are you talking about? This is going to explode in production!”

You feel like this

Who do you think will be able to influence developers actions when something important for testing needs to be done?

Not Jack.

Me? Often, I always got the developers at least to listen to me and a lot of the times we did it my way unless somebody in the team had a better idea.

So, do you want to be Jack and keep on moaning about developers that don’t understand anything about testing?

If I were you I’d take Gus’s approach and build your influence within your team, start now, start listening.

How about an agile talk instead of a talk about agile?


Here’s the thing, next week I am going to speak at the Agile Tour Dublin . My talk topic is in the beginner track and it is a Quick Introduction to Agile.

How do I keep people awake and deliver something that will be valuable?

I could start with a timeline of the events that brought us to the manifesto and then continue towards the different frameworks, mention the important people, talk about the values etc.

Well, I could, but maybe nobody would care.

I could talk about how agile requires a fundamental change in the mindset and discuss potential problems people might find once they embark into a change journey.

Maybe slightly better

Or I could focus on the values and principles in the manifesto and explain how they apply to what people do within organisations

But people might go back asleep, etc.

Fundamentally I think that no matter which of the 3 approaches I take, it might be something that people could get from reading a wikipedia page, not good enough for my customers!

So I thought, how about I do an agile talk instead of doing a talk about agile.

How about before the start I ask my customers (the audience) to pick from a set of topics they want to hear about. And how about I get the audience to give me feedback while I deliver so that I can react quickly and change the subject when it is not giving value any longer?

This would embody the close customer collaboration, the fast feedback and the ability to react to changing conditions.

Also, how about I ask the audience if they want me to speak for exactly 30 minutes and go through all my slides or if they believe that they can collaborate and give me feedback so that I might be finished 10 minutes earlier if the topics are complete or maybe even 5 minutes later if they still need some answers.

This would reflect the customer collaboration over contract negotiation

How about if I told them that I am not going to send them the slides by mail but I am available all day long to talk to each and any of them discussing the content of the talk.

This would sound like face to face collaboration over processes and tools

Wouldn’t this format also embody Working software over comprehensive documentation?

Do you think a format like this would be valuable?

Do you have any other suggestions to do an agile talk instead of a talk about agile?

Please help me by using the comments or mail me at augeva@gmail.com






On Developers, Golf and Luck

empathyI love golf, I am quite atrocious at it, but still love the game.

According to legend, back in the 60’s, South African golfer Gary Player was playing a round with a friend. At the very start of the round, he sank two consecutive extremely long putts and got 2 birdies.

After his second long putt, his playing partner sad: “Wow, you are lucky!”.

Unfazed Gary replied “I am a great believer in luck, the harder I work the luckier I get”

What’s this got to do with the price of turnips in Termonfeckin, you might ask. Let me explain.

Just yesterday, I was discussing one of my previous blog posts with a tester I really admire and respect. The discussion was around whether developers can be taught testing and whether they really want or care to work with testers on improving their skills.

My experience says “Yes” and “Yes”, my interlocutor had a different opinion. Perfectly fine.

At a certain point he said, and I quote  “you’ve been in a great position to have people with the right mindsets, eager to learn and conduct testing activities”


I heard that before, I actually heard it too many times, in different forms.

In the last 10 years I was told: “you are lucky to be in that situation” or “you were fortunate to have the right people around you” and also “you have had the fortune of not having my situation where developers don’t care about testing, blah, blah blah…” and just about any other way of saying that I WAS LUCKY.

Honestly, I don’t think I have been lucky. Could I be lucky every time? Luck is about chance? I understand maths and getting lucky every time sounds quite, let me think, unlikely.

I made my own luck.

I learned to treat developers with respect, show them my appreciation for their work, empathise with their fears and expectations. When in this context, developers, or for that matter any category of people, become more interested in our own needs, more willing to help and learn something you might be teaching.

If we keep on saying that developers can’t test, that if there are no testers the world is going to end because developers are not able to do their job properly, how do we expect to have them listen to us and help us? First we shut them out of our little testing world and then we expect they want to learn what we do and help us, this is just not reasonable.

Funnily enough us, testers, are the biggest moaners of them all, always complaining that the industry doesn’t value us like it values developers, but we still don’t understand that empathy is important to get people to be on your side.

Don’t take my word on this, I am just a lucky man.