BUG REPORTING:

SUBMIT ISSUES
LIKE A PRO

NOT ONLY FOR SOFTWARE TESTERS

Artur Gula
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Table of Contents
Why should you read about bug reporting?.......................4
Is this handbook for you?..................................................5
Few words about me.........................................................6
Perfect bug report..............................................................7
0. Before you start - 3 rules...............................................9
1. Title..............................................................................12
2. Steps to reproduce .....................................................16
3. Expected results..........................................................20
4. Environment................................................................24
5. Data.............................................................................27
6. Screenshots and movies ............................................29
7. Error messages ..........................................................33
8. Other attachments ......................................................37
9. Priority ........................................................................39
10. Links..........................................................................43
11. Fix version or due date .............................................47
12. Assignee ...................................................................50
13. Labels or tags ...........................................................53
14. Additional comments.................................................56
15 Status.........................................................................59
Bonus - if you can't reproduce ........................................60
Summary ........................................................................62
Checklist .........................................................................63

Page 3 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

WHY SHOULD YOU

READ ABOUT BUG
REPORTING?
Let me quote some of my friends:
• 'I like fixing the bugs which you report,' they say.
• 'I'm glad that you test our software,' my colleagues
constantly repeat.
• 'When you report a bug, I always know what to do!'
I used to hear that many times.

Do you want to be that guy too? The person who provides

precise but not overwhelming bug reports? I'll guide you
step by step through the bug reporting process — no
matter where you start. Even if you have never reported
any bug, you will do it like a pro at the end.

Page 4 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

IS THIS HANDBOOK
FOR YOU?
I dedicate this handbook mainly to software testers or
quality assurance engineers. But, it may be helpful for
anyone who works with the software apps. Even
developers report bugs — the same for business analysts,
product owners, or project managers.
I firmly believe that you and your teammates will find many
benefits after implementing the methods described in this
manual.

Page 5 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

FEW WORDS
ABOUT ME
My name is Artur Gula. I started my journey with software
testing in 2009. It all started from Ron Patton's classic
book about software testing. Then I participated in more
than 40 software projects. Currently, I'm a project
manager and business analyst.

But I still enjoy testing software and reporting defects!

Page 6 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

PERFECT BUG
REPORT
Let's look at the exemplary bug report on the next page.

Our goal is to understand what to do in each section. I'll

also point out what to avoid, so you will not fall into
common traps.

Are you ready?

Page 7 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Illustration 1: Exemplary bug report

Page 8 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

0. BEFORE YOU
START - 3 RULES
Before jumping into the details, I have three must-have
rules for you.

Less means more

Your goal is not to write another episode of 'Harry Potter.'
So the bug report must be clear and short. It must provide
enough data for fixing it. And nothing more.

I recommend following the rule: separate bug reports for

each defect. Do not combine many not-related issues in
one ticket. It will be confusing hard to maintain and fix.
Simpler means better!

And one more - some of your colleagues may not be

native speakers. So do not try to be a poet. Instead, use
uncomplicated phrases and essential words.

Page 9 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Facts not people

What do you feel when someone points out that you are
wrong? It may be anger, offense, irritation. It's a similar
mechanism when you report an issue in someone else's
code. Your bug reports say: 'you made a mistake, men.'
Of course, you can't change that. But the form of the issue
may affect that feeling in both directions.

In the defect description, you should focus just on facts:

• What happened?

• When did it happen?

• Under which conditions?

Avoid judging the person or their work. Phrases like: 'it's

stupid, it makes no sense, you are lazy, you don't
understand, etc.' are unnecessarily aggressive. They don't
bring any value and don't help fix the issue.

We don't have the right to judge anyone in private or

professional life. So please don't do it, and the quality of
your work and relations will improve.

Page 10 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Reproduce the bug

Do you know what would happen when you report a bug
that you can't reproduce? 99% of developers will return it
as 'unable to reproduce.' That remaining 1% is for
newbies who don't know the rules yet. No reproduction
means no fixing.

By reproducing, I mean achieving the same result at every

attempt. So you can crash the system whenever you want.
Isn't it lovely?

There are some exceptions when you should still report

the bug without the reproduction steps. I'll share those
tricks with you at the end. At this moment, I assume that
you know how to repeat the incorrect behavior.

The good news is that it's possible to reproduce most

software issues. I hardly remember bugs, which I couldn't
repeat. So it's sometimes a matter of time and
persistence, and you will find that faulty path.

Did you find it? If yes, then let's report the bug!

I prioritized chapters based on their importance. If you

don't have much time, just read a few sections from the
top. It will impact your bug reporting process significantly.

Page 11 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

1. TITLE
Please look at the list of tickets from the bug tracking
system. Titles are visible up to some number of
characters. It's a common constraint of the tools.

Now tell me, which one is about a login page?

Illustration 2: Titles of bug reports

You don't know? Mee too!

Your goal
That example shows how important it is to use good titles
for the bug reports. Programmers often scan the list
looking for the bugs from their areas of specialization —
the same for testers and other people.

Page 12 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Another reason is to support searching for the specific

bug. It's common when someone asks, 'have we reported
this issue already?' Then people try finding the matching
bug report. It's much easier when your titles are correct.
You can't effectively manage the work with messy titles in
your ticketing system. The goal is to write a short and
unique title that points to a bug occurrence.

What to do?
Some hints for good titles:

• Start with crucial information.

• Use short sentences - a maximum of 12 to 15

words should be enough.

• The not grammatical form may be better than

correct, but a long one.

• Use unique titles.

• Use acronyms or jargon, but only when every team

member will understand them.

• Optionally - use tags or keywords at the beginning,

for example, in brackets, like [tag1][tag2].

Page 13 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to avoid?
On the other hand, anti-patterns are:

• Describe everything about the issue in the title.

• Add any subjective comments or judgments.

• Repeat the same title every time.

• Make typos - people will search for bugs using their

summary.

Examples
I'll show you some good and bad examples:

• 'When I tried to open a page with a registration form,

it didn't respond' → change it to 'Registration form
doesn't respond.' (essential information at the
beginning).

• 'System doesn't work' → change to 'Can't open the

main page' (to be more precise).

• 'Annual report doesn't generate data for last year

when turning off all the filters' → change to 'Annual

Page 14 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

report — no data for last year' (don't describe

everything in the title).

• 'I don't like the new design of the landing page' →

the title could be 'Landing page is not intuitive' (avoid
judgments, they are not bugs).

• If you want to use tags, it may look like '[Users]

[Create] problem with special characters.'

Page 15 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

2. STEPS TO
REPRODUCE
You already know the basic rule — no reproduction steps
means no fixing. So let's describe them as a next step.

Your goal
The purpose of this section is to guide anyone on how to
repeat the issue which you observed. Anyone, so
programmers, other testers, analysts, or project
managers. And what's not apparent, even to guide
yourself. After a few months, you won't remember all the
details.

Believe me!

Now let's imagine that the way of reproducing bugs is not

clear. So software developer spends extra time trying to
find the right way. Then it returns to the tester, who needs

Page 16 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

more time too. Finally, after some testing, it turns out that
we misunderstood each other, and a bug still exists. So it
returns to the developer. And so on.

It's a waste of time and energy. And you could avoid it by

providing clear steps of bug reproduction.

What to do?
I prefer to use a numbered list for this purpose. It creates
a clear structure, and everyone can refer to the specific
step, like 'I can't reproduce step number 3'.

So, the steps to reproduce bugs are the list of actions

necessary to observe the error in the system. It's
essential to verify if all the steps from your list are needed.
Maybe bugs will occur without some of them?

Other than that, I add information about:

• The initial state of the system — maybe you need

to clear a cache, reset some data, etc.

• Necessary credentials - for example, if the issue

appears only on my account.

• Hyperlinks to the systems and tools — to shorten

the time needed for executing the steps.

Page 17 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• Expected results at some intermediate steps — they

would help validate if someone follows them
correctly.

• Actual results at the final step - what's wrong with

the system.

What to avoid?
When describing the steps, please avoid:

• Weak phrases, like 'maybe, in some cases, if you

want, etc.' — it must be a precise guide without
subjectivity.

• Long sentences, full of actions.

• Steps, which don't bring anything.

• Referring to data that exists only in your

environment, which no one else can access.

Examples
The correct, exemplary list of steps would look like this:

1. To avoid caching issues, open the incognito window.

2. Navigate to the https://your-page-address.

Page 18 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

3. Click log in — popup with input fields appears.

4. Type existing login, but the incorrect password, for

example, artur-gula / password123. Try for different
passwords as well.

5. It navigates to the main page. The system doesn't

validate the password.

The opposing (wrong) version of that scenario could be:

1. Open the main page (no URL provided, nothing

about the initial state).

2. Try to log in to the system (no specific action

described).

3. I observed that sometimes I could get into the

system even when my password is not correct (too
long, not precise).

Page 19 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

3. EXPECTED RESULTS
You found the issue, and you know how to repeat it at
every attempt. Good!

But what is the expected behavior? If you don't know,

don't write the bug report yet. Instead, ask a business
analyst or product owner first. Remember — what you
report is what you get at the end, for most cases.

Your goal
The goal of this section is obvious - programmers need to
know the expected result. You don't have to guide them
on how to write proper code. What you need is to describe
the correct system behavior precisely.

With steps to reproduce, developers and testers have

enough information to handle the issue.

Page 20 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to do?
Be precise. According to the expected result description,
it must be possible to say if the programmer fixed the bug
or not.

I recommend describing the expected results based on

the system specification or other forms of the
requirements documentation. Then, you can add more
information about why the system must behave in that
specific way. It's good to refer to the particular chapter
from the specification or ticket that describes the result.

The end effects may depend on the other conditions. In

that case, cover them in the expected results too. For
example 'System must navigate to page A (after action B)
or page X (after action Y).'

What to avoid?
Unclear and vague justifications, like 'I'm not sure,
probably, maybe, etc.' Avoid giving two or more open
options, for example, 'system must close the modal
window, or keep it open with the error message — I'm not
sure.' — it's usually not the programmer's decision to find
a proper answer to that question. If you don't know, then
ask analysts.

Page 21 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Don't leave a space for improvisation when you expect

some error message. For example, don't describe it with
'display error message, that user exceeded the limit.' —
every programmer may invent their own version of the
message. It may not be correct.

Examples
Some of the good expected results would be:

• 'The system must display the performance indicator

as 7.5, not 3.5. Check the calculation rules
described in the document XYZ.'

• 'The system can't accept text longer than 20

characters. The system must inform the user by
displaying a standard validation message (compare
with the First Name field).'

• 'Page must respond in less than 2 seconds. It's

required according to the issue ABC-123.'

And some bad examples too:

• 'It should not process the form without a postal

address, I believe' (reporter is not sure about the
expected behavior).

Page 22 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• 'For me, it would be good to show just a notification,

but maybe we need a proper entry in the log as well
(it is too generic, with many possible solutions).

• 'Think about some clever solution to fix that' (it's ok

to challenge programmers to find a solution, but they
need to know the expectations).

Page 23 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

4. ENVIRONMENT
Data matters. Configuration matters as well. Some bugs
appear when using a specific environment only. That's
why you must provide the information about the
environment in which you observed the issue.

This information may already be part of the reproduction

steps. But some ticketing systems have a separate field
for it. This information helps filter out issues related only to
the specific environments.

You goal
Every person trying to reproduce the bug (even you!)
should know the URL, where to log in, and how. Names of
the environments don't change very often.

often. So it's a good practice to define a dictionary to pick

the environment from the predefined list. It would prevent

Page 24 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

users from describing the same configuration in various

ways, for example as 'test, TEST, test-env, TST, etc.'

What to do?
Add information about the environment in which you
detected the issue. It may be helpful to verify if the bug
appears for other configurations, for example:

• You detected a critical bug on the local

environment→ verify if the same appears on the
production server. If yes, then add this information to
the issue.

• You observed a critical bug in the production→try to

reproduce it in the local environment to be easier to
debug and fix. Add the investigation results to the
report.

What to avoid?
• Skipping the information about the environment.

• Providing the information about the environment, but

without the necessary credentials or URLs (if it's not
a standard).

Page 25 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Examples
It's usually just one value. You may also describe it as
'detected on Test environment, but works correctly on the
Production.'

Page 26 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

5. DATA
Data matters — again. Especially when you upload the
file, send the message to another system or type a lot of
information. It may not be possible to describe all of those
into the reproduction steps. A much easier way is to
attach the data file to the bug report.

You goal
The goal is to create the same conditions for anyone who
would work on the issue. If the bug depends on the
external files, why wouldn't you just attach them? It's the
easiest and fastest solution.

What to do?
Get the file that you used for the testing. It may be the
Excel you imported, an image you uploaded, or maybe an
XML file received from the 3rd party system. Then attach it
and describe that in the steps to reproduce.

Page 27 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to avoid?
Don't ask people to prepare the data by themselves. It's a
waste of time. It may also lead to mistakes and
misunderstandings. Even one single character may
change the behavior of the system under test. Don't risk
that!

Examples
Attach your files and add short explanations to the
steps, for example:

• 'Upload the data from the attached file test_1.xlsx.'

• 'I received the result from system X, attached here

as result.xml.'

And some bad examples:

• 'Upload a file with the proper structure' (but a bug

reporter didn't attach any examples).

• 'You will find the issues in the file generated by the

system X' (again, without attaching the exemplary
file).

Page 28 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

6. SCREENSHOTS AND
MOVIES
A picture is worth more than thousands of words, they
say. And animated pictures, so the video is worth even
more. I fully agree!

Always consider replacing the lengthy description with an

image or movie. It protects you from costly
misunderstandings and saves everyone time.

You goal
The goal is straightforward - present the steps to
reproduce and the final result on the screenshot or
movie. Reduce the text. Increase the readability.

Be aware that screenshots may contain information you

must protect from unauthorized access. It's usually part of
your NDA. It may also have some personal data or other
sensitive details.

Page 29 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Ensure that you store them in the place approved by your

IT or security department. Don't use a random 3rd party
tool only because it's more intuitive for you.

What to do?
You may use one of the thousands of available tools. Just
Google for the 'screenshot tool.' Your operating system
also has built-in tools, like 'Snipping Tool' for Windows.
There are no extensive requirements for that app. It must
take screenshots and allow you to draw some shapes.
That's all.

The same goes for a video. First, search for 'Screen

capture' or 'Screen recording' tools. Then, pick some
easy-to-use apps and start recording.

When you attach the screenshot or a movie, then:

• You should add many arrows, indicators, text,

and what's needed to fasten the process of
understanding the defect.

• Reference its name in the bug report. It will help

others understand what you mean if more than one
image is attached. Write, for example, 'Check
login_error.png for more details.'

Page 30 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to avoid?
When attaching the image, don't:

• Use a picture of low quality. People must be able

to read the details.

• Hide the critical information about the context, like

the URL or the page name. Sometimes, I can see
just a button or field on the screenshot, which exists
in many places. Without the context, I can't
reproduce it.

• Attach large files with hundreds of MBs or even

GBs of the size. It will take a long time for everyone
who would like to see them.

• Use formats dedicated to your operating system.

Use the standards instead, like .png for images or
.gif for short videos.

Page 31 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Examples
Here is the exemplary screenshot:

Illustration 3: Screenshot from the bug report

Page 32 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

7. ERROR MESSAGES
You can write in detail about the bug, with precise
reproduction steps. You may attach perfect screenshots
and movies. But there is something more. In some cases,
it's everything that programmers needs.

I'm talking about the error messages and all that 'technical'
side of the bug reporting process. Sometimes just one
line of the system error message gives enough
information for fixing the issue.

You goal
Your goal is to add any logs, server, or browser error
messages with helpful information. But, of course, you
don't have to understand what they mean. It's a
programmer's job. But, you need to know how to get them
right.

Page 33 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to do?
There is one magic feature in your browser. It's a
Developer Tools console. You can open it using an F12
key or through the browser menu. If you can't find it, just
Google for help.

There are two critical tabs in that console:

• Console - it contains the front-end issues, so ones

generated in the browser.

• Network - it helps track all the communication with

the server.

Illustration 4: Development Tools - Console and Network

As a rule of thumb, look for the information displayed in

red color. It means that something is wrong. Then attach
the essential details.

What's essential?

I recommend to ask your teammates. Maybe they need

the complete API request, but perhaps just one Id could

Page 34 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

be enough, and they can find the rest in the logs. But,
again, it depends on the team.

Don't guess. Just ask your colleagues.

Developer Tools in the browser is just one example. The

tool will differ if you work with mobile apps or desktop
ones. Don't worry. Developers will guide you on how to
find the logs. It's very beneficial for them.

What to avoid?
Avoid attaching everything you find in the console.
Sometimes browsers display errors on every page. It may
be some minor thing not related to your specific issue, like
missing css style. Don't mix that with the bug which you
observed.

Be also aware that log files grow fast. They may have GBs
of data. Don't attach the entire log. Just select that part
that refers to the bug which you report.

Examples
It's similar to images and videos. Just point the proper
place, like:

• 'Find the attached logs: log_login.txt.'

Page 35 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• 'I'm attaching the payload which returned 404

(payload_404.json).'

Page 36 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

8. OTHER
ATTACHMENTS
Whenever you report a bug, ask yourself that question —
if my computer would crash today, will I have
everything I need to reproduce and re-test this bug?

If not, then you still need some attachments or references.

You goal
The purpose of this section is to think about the whole
environment. What did you use for testing this part of the
system? For example, maybe you use a testing script for
the Postman tool? Or perhaps there is a user manual that
explains the expected system behavior?

Remember to link or attach all of those. All information

may help you or your colleagues to fix the issue faster.

Page 37 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

I already gave you hints about the attachments — rules for

what to do and what not are the same in this case.

Page 38 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

9. PRIORITY
Which of those bugs is more important:

• 'The color is wrong on the landing page.'

• 'Tax report crashes for some regions in California.'

The gut feeling suggests that color is low and the reported
crash is high. But what's the correct answer?

I don't know. Seriously.

Think about the scenarios, when:

• The wrong color makes the landing page illegible -

it's a high priority from the ASAP category. We may
lose potential customers.

• The color significantly differs from the company

branding, and it reminds the trademark of our
competition - it's also an ASAP kind of bug. As a

Page 39 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

result, customers will be confused, and competitors

may even sue us.

• For the crash of the tax report - maybe it's a once-

per-year kind of report? In that case, we might have
a few months to fix it. Priority could be lower.

• Maybe our business doesn't operate in those

regions at all? So even that bug is technically
critical, it won't harm anyone. Priority will be the
lowest possible until we start a business there.

You goal
Your teammates expect clear information if it's an urgent
bug to fix or not. For some of the issues, it's obvious. For
example, when the main page doesn't load or users can't
execute the primary action, it's a high-priority issue. On
the other hand, you may don't know the answer at the
beginning. It's fine. But there is someone who knows,
right? Find that person and ask.

So your goal is to understand if the bug is essential not

only from the technical point of view but also from the
business side. Then assign the proper priority value.

Page 40 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to do?
When deciding about the priority:

• Clarify with your colleagues what does it mean

priority high, medium, low, etc. for you.

• Assess the technical side of the bug. If it's, for

example, a crash in the commonly used feature,
then it must be a high priority.

• Think about the business impact. The higher

impact, then the higher priority.

• If you are not sure, then ask the analyst or product

owner.

What to avoid?
• Don't use a default priority value all the time.
• Don't define a priority level by examining the
technical impact only.
• Don't guess! Assign priority based on the specific
criteria for all the items in the backlog.

Page 41 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Examples
I showed some examples in the introduction to this
chapter. Now, look into your backlog and reassess the
priority levels for some of them.
Are they correct?

Page 42 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

10. LINKS
'There must have been some bug related to this one' — I
repeatedly hear that.
Issues are often related. One of the software testing
principles says that bugs cluster together. When you find
one, it's a bigger chance to find another one in the same
area, the next one, etc. It would be good to link them
because they may have the same cause.

Another case for linking is dependency. For example,

some fixes will enable another or unblock testing activities
for a different ticket.

We can't forget about traceability and statistics. I mean

linking bugs with related requirements or system
components. Then analyze the results - find areas with
high bug rates or a team that delivers excellent quality.

Page 43 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What's important is that you don't link issues for others,

but you do it for yourself too. I bet you won't remember all
the relations in a few months.

You goal
The goal is simple. Link the bug to any other related
tickets. If you are not sure if you should link something or
not, then connect it. Of course, you can always delete the
relation if needed.

What to do?
Consider linking the following items:
• Requirements that describe the expected behavior.
• Tickets with more information about the problem (for
example, in the comments).
• Bugs or tasks blocked by this one.
• Issues that stop your bug from being fixed or tested.
• Duplicated tickets.
• If you split the main item into a few smaller ones,
the parent or child.

What to avoid?
It's usually better the link item than not. But you shouldn't:

Page 44 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• Link tickets without any relation tag or comment, so

no one will know if it's a dependency or maybe just a
relation.
• Link the items to which some of the team members
may not have access. In that case, it's better to copy
the content instead of creating the relationship.

Examples
You can find examples of the links from the Jira tool
below.

Illustration 5: Exemplary links from Jira software

Typical ways of connecting are:

• 'Before fixing this, please fix the BUG-123 first.'

Page 45 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• 'You can find the diagram describing the flow in

FEATURE-456.'
• 'It's split from the BUG-789. Please fix all the related
issues for the release.'
• 'It's already been reported in the BUG-105. So I'm
canceling this one as a duplicate.'
• 'This issue blocks STORY-12 and STORY-34.
Please fix ASAP.'

Page 46 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

11. FIX VERSION OR

DUE DATE
Use this one with care and only if you have some
experience and a good understanding of your project. You
may help plan the work by providing the due date or the fix
version for the bug. But, you can easily mess up with the
plans if you do it incorrectly.

A significant benefit of assigning bugs to the sprint or

version is that they don't get lost in the never-ending
backlog list. As a result, you, as a team, can plan the
work better, with fewer surprises.

You goal
Project managers usually split work into versions and
sprints. And each version has a release date. Your goal is
to assign the must-have tickets to the upcoming release,

Page 47 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

so the project manager or product owner may catch those

in advance. It's a much better approach than realizing that
we have a few more critical bugs to fix on the release day.

What to do?
At first, talk to the project manager or a team leader. Ask
them if you should assign the tickets to the versions.
Some managers will welcome that. You will do the job for
them. Save their time and reduce the risks of skipping the
critical bugs. But some managers will not. It's ok too.
Then follow the agreed rules.

What to avoid?
On the opposite, avoid managing the version
assignment just by yourself. Usually, the project leader
works on plans, agreements, timelines, budgets, and
business priorities. Without that complete understanding,
your judgment may be incorrect.
If you are not sure, then ask.

Examples
Versions or sprints are usually predefined. So you pick the
proper value from the list, which could be:
• Sprint: SPR-12

Page 48 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• Version: 1.2
And so on.

Page 49 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

12. ASSIGNEE
Who is your favorite software developer from the team?
Or maybe another way around - to whom would you
assign the most complex and tedious issues to fix? I hope
you don't select the assignee based on personal relations.
I'll tell you about better ways of doing it.

Assigning bugs at the moment of reporting helps

organize the backlog. In addition, it reduced the time for
planning the work. But there are some risks as well.

You goal
Your first goal is to understand the rules. Exemplary
ones are:
• Assign front-end bugs to the front-end team leader.
• Assign critical bugs to the project manager for
prioritizing and planning.

Page 50 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• Assign bugs based on the areas of specialization,

which are written down somewhere in the wiki.
Once you know the rules, implement the process and
validate it. If you are new to the team, you will need a few
weeks to feel confident in assigning proper people to the
bugs. And don't worry if you make a mistake. It's normal.
The good news is that modern tools may do the job
automatically for you. For example, when area =
Reporting, the algorithm will assign a John Smith to the
bug.

What to do?
Here is the list of some good practices:
• If the bug is critical, I recommend contacting the
programmer directly. They may not notice that you
assigned some tickets in the system.
• Make sure that person to whom you assign bugs is
available. You will wait long days for fixes by the
person on holiday.
• If you have doubts, ask the potential assignee,
'Hey! I found a bug in the search mechanism.
Should I assign it to you?'

Page 51 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to avoid?
• Don't assign tickets randomly. It's better to leave
them unassigned.
• Please don't believe that once you select the
person, it means that they will work on it
immediately.

Examples
Examples are straightforward - you assign a specific
person to the bug report. It's usually just one person, but
there may be two or more in some cases. For example,
when two different people will fix the front-end and back-
end.

Page 52 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

13. LABELS OR TAGS

We are close to the end. But maybe you think about some
other categorizations, which didn't fit into any of the
previous sections. For example, you may need that for
separating UI from server issues. Or to tag bugs with free-
text keywords.
The labeling system may be a proper solution.

You goal
The first question is why. Why do you need to
categorize the bugs? The typical answer is to create
different views for the front-end and back-end teams. Or to
present statistics per each type of bug. Once you know
the goal, you may decide which tags you want to use. But
please, treat them as some extra information, the nice-to-
have data. If you require a strict categorization, use a
mandatory dropdown list instead.

Page 53 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

What to do?
When introducing an issue labeling, the most important is
to agree with the team about the list of possible values. In
the beginning, when team members are not used to the
tags, you may create views that present the ones with
missing information. Then ask reporters for updating the
gaps.
You may also prepare a report that counts the number of
issues per label. Thanks to this, you will know which ones
you commonly use and which don't. Or you will indicate
the misspelled tags.

What to avoid?
Avoid using many tags without any purpose. It will be
confusing for the reader with no benefits. Also, be careful
if people don't invent new labels instead of using the
agreed ones. It will make your reporting impossible.

Examples
Typical tags used for bug reporting are:
• 'FE' (as a front-end)
• 'BE' (as a back-end)
• 'UI' (for user interface issues)

Page 54 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

• 'DB' (for database problems)

• 'hotfix' (to indicate the need of fixing the system
immediately)
• 'users' (to categorize the issue by the system area)

Page 55 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

14. ADDITIONAL
COMMENTS
You are unsure if the observed behavior is a bug or a
feature. So, you ask the product owner. She explains to
you how the system should behave. Based on that, you
report a bug. And after a few weeks, when it goes to the
development, the programmer returns it to you. The
comment is short 'it's against the specification ....'
'Oh yes, it's really in contradiction to the documents. So,
why did I report it?' - you may ask yourself.
You could avoid it by noting down any comments and
clarifications.

You goal
Don't be afraid of changes. But let everyone know if any
change appears. Your goal is to keep track of all the
agreements and additional information. Bug tracking

Page 56 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

systems usually have a place for comments. Use that one,

or find another way of tracking changes with the team.
When you do it properly, you will save time and improve
the quality. You want that, don't you?

What to do?
Be like a recorder. Note every change. Keep track of the
discussions which impact the scope, priority, or other
parameters. For example, note that down if someone
confirms that the bug is a bug.

What to avoid?
There is one very, very important topic. Never change the
content of the tasks in progress without a consultation. For
example, imagine someone working on the item for two
days, and then you change the description quietly. It will
generate a lot of frustration when the results are much
different from the ticket description.

So, if you realize that you need to update the bug

which you just reported, make sure that it's not in
progress yet.

Page 57 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Other than that, avoid adding clarifications without the

source of information. It may be a document or a person.
But you must indicate it.

Examples
I often add comments like:
• 'Confirmed with Marry White at 11.03.2022.'
• 'John agreed that it's a high-priority ticket.'
• 'We reviewed it on the team call at 19.04.2022 and
agreed to lower the priority.'

Page 58 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

15 STATUS
I leave it to the end. It's important information in the
ticketing system but rarely changes in the process of bug
creation. New bugs are usually in 'TO DO' status or
similar. But there may be some exceptions:
• You know that the bug is blocked by another issue -
change status to 'Blocked.'
• You need support from the analyst - change the
status to 'To analyze' if you have something like that
in your workflow.
• The bug requires fixing the UI design first - change it
to 'To design' and again if it's a part of your process.

From my experience, the new bug in at least 99% needs

to be in the default status. So don't spend much time on
this section. And so do I.

Page 59 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

BONUS - IF YOU CAN'T

REPRODUCE
Here is the hint about reporting bugs when you can't find
steps to reproduce. There is one source of information,
which may be enough for programmers to find a reason
for the issues in this case. It's an error message or system
log. So, the text that means nothing for the average
reader. For example:
Exception in thread “main” java.lang.NullPointerException
at com.example.project.Book.getTitle(Book.java:28) at
com.example.project.Author.getBookTitles(Author.java:64
) at example.project.Bootstrap.main(Bootstrap.java:14)

But it has a lot of valuable information. It may guide the

developer on how to debug and fix the issue. Maybe they
will be able to reproduce it based on the log.
So, ask your teammates what will be the most
valuable source of information for them. It may be a

Page 60 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

log stored on your computer, records from the cloud

monitoring tool, or an error in your browser.
And then, when you observe the issue which you won't be
able to repeat, store the part of the logs and attach it to
the bug report. The good practice is to check the
timestamps to find the messages related to the observed
malfunctions. Then, with a bit of luck, you will find the root
cause of the issue.

Page 61 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

SUMMARY
Congratulations, you made the first step to being a pro
bug reporter. The next one is more challenging.
Implement all that knowledge in your everyday work. It
should be your habit!

Some of the mentioned sections may not be available in

your current project and tool. Or you may find new custom
fields. But, don't worry - principles remain the same. You
will know what to do. I'm sure.

If you would like to share any comments or ask questions,

please feel free to reach me on LinkedIn:
https://www.linkedin.com/in/arturgula/.
I'll be happy to help you with your bug reporting process.

Page 62 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

CHECKLIST
Keep the checklist always with you.

Good luck!

Page 63 of 65
 BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Principles: less = more; facts not people; reproduce it

Title: short, searchable with key information, unique

Steps: sequence, with all the necessary information
Expected results: precise, no open questions
Environments: URLs, credentials
Data: everything you used, save the time!
Screenshots: good quality, annotations, light
Error messages: the right one - ask what dev needs
Other attachments: when your computer crash - what
would you need?
Priority: color and system crash may be equally important
Links: help your memory, link related items
Fix version: support planning, but be careful
Assignee: follow the agreed rules
Labels or tags: use the ones which are needed
Comments: keep track of all the agreements
Status: follow the process, but rather leave in default

Page 64 of 65
BUG REPORTING: SUBMIT ISSUES LIKE A PRO | ARTUR GULA

Page 65 of 65