How do you actually prevent bugs?

It’s not hard to find articles or pieces of research claiming that the sooner you find a bug, the cheaper it is to fix. But I’ve found there isn’t actually a whole lot of information out there on exactly how to prevent bugs in the early stages of a software development project. i.e. before code is written, while requirements/user stories are being written or just after the requirements/user stories have been written

Here I would like to share exactly how I help prevent bugs on projects and how I help others come up with ideas on how to prevent bugs as well.

During feature walkthroughs

Get yourself invited to these. They may be called something different at your company/project but they are essentially a meeting, presentation or discussion around the general gist of the feature you are about to work on. There may or may not be designs at this stage yet.

If designs exist, ask the designers for access to the designs before the meeting if possible so you have a bit of time to process your thoughts before the meeting, also ask if they are open to feedback before the meeting or if you should wait until during the meeting.

If designs don’t exist, I do find this trickier as I’m a visual person and designs help make things more “real” for me. There are, however, still ways you can cope with this.

Here are a few things you can ask about during feature walkthroughs:

Along with the questions above, you can also help trigger further discussion by stating how you understand how the feature will be used in the feature walkthrough.

Yes, you may be wrong - but that’s fine. The value here is that by making your thought process and understanding explicit, then others can step in and correct you - this helps enable a shared understanding. You will also help others ask questions about things by verbalising your thought process.

Once the requirements/user stories are written

I’m going to assume here that the requirements/user stories are still subject/open to change, but limited to a certain extent. (no massive changes)

Make sure that your assumptions are made very clear - state them in your testing notes and also at the start of any testing discussion you have with your team

Have a testing focussed discussion with the developers in your team. Here you can share exactly how you will test and what you will expect - also make sure to highlight that you may have misunderstood things, and that you are open to testing ideas from the developers in your team. I tend to go with testing notes, instead of test cases - but ultimately it’s up to you to decide on what’s best for your project and realistically, what you can do a walkthrough with.

Where possible, use examples in your testing discussion, if there’s examples of test data you could utilise - then use these concrete examples of what you would be doing to test, and what you would expect in these examples.

For example:

Let’s say you are asked to test login functionality. Then you can write examples of email addresses and password combinations, and the error messages you expect to appear.

test@example.com / –> Please enter your password

nicolaemail.com / ********* –> Please enter a valid email address

After the discussion, make sure to share the notes you took and how your testing notes/ test cases have been updated to reflect what has been discussed.

If you want to read more, in depth, of how to prevent bugs, you can look at Chapter 11 of my book, Starting Your Software Testing Career.

To stay updated with new blog posts, including ones like this one, you can follow me on Twitter: @NicolaLindgren

📹 If you enjoyed reading this post, check out my YouTube channel and subscribe.

I post videos that can help you with your software testing career.