How do you "Maintain and resolve bugs" as a Junior tester?

🙋 Questions
, ,
1

Hi all,

Today, we conducted another task analysis session for the Junior testing curriculum based on the Job Profile we captured with the support of the testing community.

For this session we were considering the task:

Managing and resolving bugs

Combining a series of community activities including social questions and our curriculum review sessions to identify the steps we need to take to successfully achieve this task and have listed them below.

  • Contribute to the review of a bug backlog
  • Arrange the product under test so that it includes bug fixes to retest
  • Become familiar with the bug and it’s potential fix
  • Retest the bug and communicate outcome to team
  • Carry out further testing and/or regression testing around resolved bug

What we would like to know is what do you think of these steps?
Have we missed anything?
Is there anything in this list that doesn’t make sense?

1 Like
2

Managing and resolving bugs

Bug reports? People use “bugs” metonymically for the reports that describe found and documented product problems, but conflating the two means that terms that apply to one are thought to apply to the other even when they don’t.

We should also consider that the bug reports in question are written reports, stored in a bug report management system. They could be part of a verbal discussion or company white paper.

So, managing, to me, suggests that we’re talking about bug reports. It involves creating written reports, adding them to the management system, and updating them with new information. It could include deleting them, advocating for them to get them to move, following up with blockers to get them seen.

Resolving, to me, could be about either. Resolving could mean deciding on a course of action (“I resolved to eat fewer doughnuts today”), then what we do about a bug or its report is decided on by many people, say in triage - it’s not up to me if a bug gets fixed. Bugs could be resolved in the sense of settling on a solution (“I resolved the argument about the last doughnut by eating it”), so fixed and retested in terms of bugs themselves, or perhaps “closed” in the management system in terms of reports.

So we could talk about bug reporting, or related artefact management. As the profile already talks about reporting testing, including writing up bugs, I’ll mainly talk about bug report artefact management.

From the existing list I wonder about contributing to the review of a bug backlog. Does a backlog mean all bugs we intend to fix, all bugs we found, or an excess of either of them? What does a review entail? How much of it belongs under the role of tester, rather than team member?

Here’s the list I came up with so far, which includes things from the old list reworded just for my comfort:

Bug Report Management

  • Create high quality bug reports, with suitable advocacy
  • Link reports to evidence, documentation or other related bug reports
  • Review bug reports, where appropriate, with their intended audience to aid communication and improve future reports
  • Update reports with new information and evidence
  • Follow up on stuck or stale bug reports and help to resolve blockers
  • Update reports to reflect testing of fixes in available versions of the product
  • Consider the change risk of bug fixes and other testing to perform to mitigate it
1 Like
3

I think it’s important that testers can recognise the difference between the the bug-as-originally-reported, typically steps to reproduce a visual or behavioural issue, vs the root cause of the bug, typically a flaw in the code somewhere. In most cases in complex software, the flawed code will affect more than just the reported issue, which can be thought of as a symptom, so testing the bug fix should cover more than just repeating the steps to reproduce. Sometimes the root cause is in a completely different area to the particular symptom that has been caught, or the steps to reproduce are just one aspect of how the bug shows up.
All of this could come under “Carry out further testing and/or regression testing around resolved bug”, but it could be more specific about testing being focused on the root cause/fix rather than the symptoms

1 Like