How do you actually prevent bugs?

This blog post was originally posted on my personal blog: nicolalindgren.com

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:

• Error scenarios – how will errors be handled; where will validation be done (backend or frontend) etc.
• Ask for the backend documentation and how things will be validated there, then make sure that things have stricter validation in the front end (where possible), this helps prevent problems where the FE accepts data and you submit a form but the backend rejects it (e.g. mandatory fields, all mandatory fields the backend requires MUST be mandatory in the front end)
• Are there any mandatory fields we need to consider?
• Are there any other features we expect this feature to be consistent with? (For more on consistency heuristics, check out my blog post here) Some examples of this could include: how errors display, positioning and colours of buttons, user feedback when submitting a form (if you already have these sorts of things in place, you can then ask about these and if this new feature will be aligned with the existing behaviour within your site/app)
• Are there any dependencies within the app we need to be aware of?
• Are there any external dependencies (e.g. 3rd party ones( that we need to be aware of?
• 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.

[e-mail] / –> 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.

Follow me on Twitter: @NicolaLindgren