Starting out in the quality assurance field with no prior technical experience meant I had to learn at a fast pace to catch up with the industry.

I was beginning a new journey and learning something that was completely alien to me which was daunting, but there was something so rewarding and magical about progressing into a career that I have such a passion for and seeing where it leads me. 👽

As a girl who is into all of those gory CSI/murder mystery dramas, there is just something about being in testing that makes me feel like a detective who’s on a mission…to squish bugs, rather than lock up bad guys…but you get where I’m coming from. 🕵️♀️🐞

My first task as a tester

So, my first task was to log bugs I found in the platform.

I was given a brief overview of each mandatory section to include in my bug reports, from a simple summary to screenshots/videos and reproduction steps.

For my first few bug reports I most definitely went at a snail’s pace to make sure I was including all of the necessary fields meanwhile ensuring it was clear, concise and easy to follow, but that’s ok.

It’s all part of the learning process…take your time, there’s no prize for being the fastest. ❌🏆💨

Fast-forward a couple of years and I could probably write a well-described bug report with screenshots/screen recordings, reproduction steps, summary, errors, description and all other necessary information within 2 minutes.

But remember, it’s not a competition.

There are some people who could probably do it with their eyes closed, but this doesn’t make them any better than you.

Just like doing it in 2 minutes doesn’t make you “better” than someone who takes 5 minutes.

Every individual tester has their own methods and techniques when reporting bugs and none of them are wrong. 🙈 ✅

Just like anything…the more you do it, the faster and easier it becomes.

Sort of like riding a bike; you begin your journey a bit wobbly, taking it slow until you get the hang of it and then in no time you’re flying around doing no-handers and kerb-hopping (all of which I do not recommend).

Bicycles may evolve over the years just like systems will, but you can never “unlearn” it.

It sticks with you forever. 🚲💨

Avoiding burn-out…

Take regular breaks to avoid burn-out.

Logging bugs isn’t always as simple as it sounds.

Maybe some itty-bitty UI bugs are fast and easy to log, but others are more challenging and require additional time to find reproduction steps. 👌🐞💨🪜

What people don’t tend to talk much about is how frustrating and draining it can get when you are trying your utmost hardest to find steps to reproduce a bug and nothing is working in your favour.

The detective in you wants nothing more than to ‘solve this case’ (if we’re talking in detective terms) and being unable to solve it can sometimes leave you feeling as if you’re not doing your job right or maybe aren’t as experienced as you thought.

If you do feel this way when you’re unable to reproduce a bug, it really just shows how passionate you are about your work — although please don’t let it affect you too much, everybody knows you’re trying your hardest. 🔎💪🏻

Or do you ever find yourself in the midst of reporting a bug and you suddenly forget what the bug was regarding, or finding words to describe the bug you have just encountered have completely escaped your mind?

Brain fog may be a sign that you need to take a little rest too; grab a coffee, biscuit, whatever it is that you need in order to refuel yourself.

You won’t be performing at your best if your judgement is clouded. 🤯☕️🍪

My tips for creating bug reports:

1. Notes

‍Finding a lot of bugs in a short amount of time? Write a list of bugs in your ‘notes’ as you find them and log them after each hour or so.

If you find a potential high-priority / blocker bug, log this immediately.

This method is most effective for me when a new feature has been released and I find some bugs during my ad-hoc testing, not usually for day-to-day testing.

I also find that it works well for regression testing and creating test cases during test explorations (as displayed in screenshot below). 🗒

2. Take breaks‍

As previously mentioned, breaks will help to refuel and help avoid burn-out. ⏳

3. Communicate with stakeholders‍

Have you just encountered a high priority/blocker bug?

Avoid delays; log and communicate it with your fellow team members (product owner, tech lead, developers, testers, etc…) so it can be prioritised and fixed as soon as possible.

For this we use channels on Slack. 🗣

4. Finding bugs related to the same issue? Group them and log them in one bug to save time

‍This really depends on the bug and the context.

If you are stuck on deciding which bugs should be grouped, you can ask a team member for some assistance and you will eventually start to grasp which bugs can and cannot be grouped as time progresses.

But for example, if I see that a dropdown component isn’t working throughout the platform (in multiple areas), these can all be logged in one bug report. 💨

5. Time saving‍

Save time on the back-and-forth hassle between developer and tester by adding all screenshots/screen recordings necessary to your bug report.

‍Always add at least one screenshot or screen recording to your bug. 🕰

6. Make ‘summary’ as descriptive as possible‍

You want the summary to be as descriptive and to the point as possible so that somebody understands what the bug is about just by reading the main title.

It’s finding the balance between descriptive but not too long-winded as it’s only a summary after all. ⚖️

7. Description‍

Think about all of the questions the developer could ask you in regards to the bug and try to answer them all in this section.

Make it descriptive but not too lengthy as it may be difficult to retain the information.

8. Steps‍

Make sure your steps are clear and easy to follow so that even if somebody who was new to the platform was to follow them, they would be able to do so with ease. 🪜

Example of another bug report I created

What to include in your bug reports

This is different for every organisation but here are the main fields we use when logging bugs on Jira:

• Summary (mandatory field) — Title of the bug as mentioned above.
• Description — In here I usually add a brief description outlining what the bug is about with a file URL to the screen recording (if applicable) and any preconditions. Devices/operating system/version/screen display size (etc) would be good to add here too if appropriate. 📝
• Steps — Reproduction steps. 🪜
• Environment — Develop? Staging? Production? 🌍
• Attachment — this might be files of images/videos needed to reproduce a particular bug, it could also be screenshots of the bug in question or even console/network errors. 📎
• Assignee — assign to the person who will be prioritising and adding the expected result. In some organisations the tester will add the expected result but we do it differently. 💁‍♀️💁
• Lane/Section (mandatory field) — Section of the app where the bug occurred or if it’s related to “UI/Design” for example.

Thanks for reading!

See you on the next one!

Case closed.