Have you ever bought something in a shop and only realized that when you go to use it, that you learn you’ve made another one of your mistakes and bought the wrong item?

Being on a vegan diet, I can not begin to count the number of times that I’ve done this with food items.

Blindly picking something off the shelf because it has ‘dairy-free’ on the label. But if I had taken the time to read the ingredients list in the shop. Rather than when I’m half-way through cooking a delightful pasta dish that evening. I would have discovered that the sauce contains eggs.

Not a good feeling.

But even though I dislike it when something like that happens. It’s a good opportunity to reevaluate my strategy for the situation and try to mitigate similar issues from occurring in the future.

So in this case, it would be “Don’t go by what is on the front of the label and read the ingredients before buying food.”

We can make mistakes in a wide variety of situations as well as occupations. They are inevitable if we ever want to get better at our craft.

For mistakes made in software testing, they can originate from a variety of different sources. Not limited to, communication issues, documentation problems, resourcing conflicts or just plain mistakes.

But whatever the source of the issue is. It is imperative that as software testers do we not only own the problems that are made to build trust in our teams. But to also learn from them and realize the lessons that they provide.

Ownership

Depending on the issue that has made it into the production environment and the hands of their users. Mistakes can have serious effects on the image of your company.

When an issue is first reported, some people may have the initial reaction to point fingers and try to find someone to blame the problem on. Even though this might seem like the right course of action at the time. Blaming people won’t get issues solved and creates a negative atmosphere within teams. It can often be toxic and gives life to a culture in which people don’t enjoy working in.

What everyone will appreciate is when a tester steps forward and owns the problem. Admits their part that contributed to the issue getting its way into the client’s code.
Now it may not be 100% your fault and there could be other reasons that contributed to the issue being present. But as testers, the least we can do is own our contribution to the process.

Mistakes can be compared to a tiny spark which has the potential to grow into a great burning fire that engulfs everything you know. Ignoring the problem, or not recognising your part that contributed to the spark existing in the first place, only feeds the fire further.

I know from my personal experience that admitting when i’ve made my own mistakes, either by missing something, or another error of my own. Can be I’velike admitting not only a personal failure. But also my inadequacy as a tester.

But we only need to remind ourselves that everyone has made mistakes. Every single person that we can think of.

So don’t beat yourself up about it and be honest with yourself and others.

Lessons to be learned

After owning the mistake that has already been made. Attention should now be turned towards ensuring that it doesn’t occur in the future.

First of all, you need to understand the problem and investigate all the contributing factors.

I find it useful at this point in the investigation to compile a timeline of the events from start, to finish. This enables me to look up a step which is responsible and either make amendments to my test steps if needed. Or make suggestions to other teams.

Again, this shouldn’t be a finger-pointing blame game. We are all part of the same team and responsible for delivering quality software to our end users. That should always be at the forefront of our intentions.

Once you present the evidence of a potential weak point in a process to another team. How they act on the information is beyond your control and you should instead focus on the things you can change. Like your documentation, training processes or test scripts.

Followup

It’s always a good idea to hold a follow-up session to not only talk to stakeholders about any changes to your test scripts. Or any steps taken to mitigate the mistake from occurring in the future. This also allows you to inform your team about the changes so that they are aware of anything they need to do.

It’s possible of course that no-changes need to be made to any of your test cases or test scripts.

Given the example of a step getting missed in a test-case. You may need to highlight that fact and be honest with everyone about it.

Conclusion

I read a quote a while ago that read “You’re only as good as your last haircut.“

I think that can be interpreted differently.

The way we react to mistakes that we have made or contributed to speaks volumes to others.

So when you make a mistake, choose to be honest about it and responsible for the follow-up actions.

I’m glad to say that this year, I’ve read a lot of books.

Unfortunately, I’ve not read a lot of books dedicated to software testing, choosing to read blogs, watch videos, and attend conferences to get my software testing inspiration.

But still, 41 so far, a personal best for me for books read in a single year.

I’ve achieved that number by always carrying my Kindle with me, reading instead of wasting time and most of all, loving the books I’m reading.

Reading has become one of my favourite ways to learn new ideas, discover concepts I find interesting, and upgrade my knowledge in new areas.

However, with the year (and decade), coming to a close, a new intention that I intend to adopt is to increase my software testing book library and read as many of the amazing books on the industry that I can.

Read More

Have you heard this before?

‘The software was working perfectly fine until the testers got their hands on it’.

What about this?

‘Don’t give it to the software testing team. They’ll break it!’.

Are any of these claims actually true?

Can testers really break a perfectly good piece of software by running a few test scenarios and pressing a few buttons?

Well… no.

Read More

Software is kinda like a 1000 piece jigsaw puzzle.

Once it is complete and in the hands of the end-user. It is entirely possible that they will start running into issues. Maybe they cannot find a crucial piece that they need, find that there are pieces that do not fit together, or even discover that the picture on the back of the box does not match the one they are assembling.

We often relate testers roles to the quality of the product we end up delivering to our client’s and ensuring that the quality is the best it can be,

So one metric that we might use to measure quality could be the number of bugs present in a system. You shouldn’t solely use this metric in a real-world scenario. But we’ll use it for this example.

So in the jigsaw’s puzzle case, we could add a test to ensure that we have all the pieces of the puzzle. This could be achieved by doing a count of all the pieces before the puzzle is put together by the customer. That would ensure there are no issues.

But what if something goes wrong that we didn’t test for, is that the complete fault of the tester? And why was it missed?

Read More

I remember hearing from a friend one day that they just ran a marathon. A monumental achievement for them considering that only a tiny fraction of people will ever run that distance in their lifetime.

But running a marathon isn’t just a quick decision that you can make on a whim one day, put on a pair of running shoes the next and then run the 26.2 miles.

I mean, I guess you could, but it probably won’t end well.

Having run two marathons myself. I know the months of preparation required to withstand the punishment that not only your body will go through but also the mindset required to not give up when everything hurts.

Not to mention thinking about all the potential variables that may go wrong in a race,

• What if suffer from crump?
• Can I get water on the course when I need it?
• What if I lose a shoe?

Ok, the last one is unlikely, but I always have the fear that my shoe will come off during a race.

Read More

I passed my driving test on the second attempt. My first attempt was a failure when I pulled out in front of a BMW. Which makes a change, I guess.

I remember the days following my success; I wanted to get a car of my own immediately and drive anywhere and everywhere in it. For too long, it restricted me to driving my instructor’s car around town centres like someone trying to locate a car parking space on a busy Saturday afternoon.

I wanted to use this new skill that I now had, and I wanted to apply it to everything.

But then I saw the cost of a car, insurance etc so I decided that I should just get a bike instead.

This urge to use a new skill can be like how we feel about test automation.

From unit tests, API calls to using a tool like Selenium and making it look like our application is being used by a ghost. Automation testing is not only cool, but having tests run by the computer can save us serious time and money.

Read More

An inevitable action in our lives often requires us to give a piece of unwanted news to someone we don’t really want to give it to.

Whether it’s telling them they didn’t get a job, their car has a flat tyre, or they have a grubby mark on their face. No-one wants to give someone some news they’d rather not hear or be the person who is seen to be criticising the actions of someone else.

Software testing can be difficult sometimes for this reason. The bug reports we raise and the very nature of the job can often be seen as a negative activity to developers.

And I can understand why, if a developer writes a piece of software and they’re proud of what it does and how it was constructed. It can be quite deflating for them to see a tester to get a hold of it and raise six bug reports in quick succession.

Read More

The golden rule is to test your features before you show them to your customers to prevent embarrassment. But I guess Elon didn’t get the message.

If you didn’t watch the reveal event for Teslas new electric-powered pickup truck on Friday. Let me just quickly recap the key moments of the event.

Elon comes onto the stage and talks about how pickup trucks haven’t really changed in recent memory, then Elon reveals something which kinda looks like a picture I drew back when me was 5 years old on the stage.

Elon then talks for a bit about the truck (I’m not a car guy, so didn’t pay much attention here). But then he talks proudly about the glass and how tough it is, along with the truck’s metal exoskeleton.

Read More

Show me a piece of software, and I will show you the same number of issues with it.

Ok, that’s not an actual quote from someone, but the point that is conveyed is that all software has at least one bug present in its code waiting to be found.

But why is this?

With fancy developer environments and in-built error checking, don’t a lot of bugs get caught in the developer stage?

I can understand how puzzling of a question this can be, but the fact is that even with all the tools in a developers arsenal, buggy code is still and will forever be a thing.

But what is the source of these bugs? What factors contribute to their existence?

Read More

It seems common for many people wanting to learn a new skill to go through three main phases, deciding what to learn, going through a tutorial on the subject, then deciding it’s too hard and thinking the skill isn’t really the best one for them, and then either giving up, or moving onto a new skill that might be easier to learn.

When I first started programming back in the late 90s’, I too went through these phases, asking myself if I should spend my time learning this programming language or perhaps a different one. Is this really the best way to structure my code, or do I need to do more reading first?

This cycle of self-doubt can debilitate for a lot of newcomers and makes it seem impossible to get past those early stages and onto a level where you feel confident in your abilities with your new tool.

Read More