MANUAL TESTER

Workshop
1

Bug
Agenda

01 Daily Scrum (stand-up) – discussing what we managed to achieve yesterday and what we plan
to achieve today.
02 How to report defects? – practical tips on how to report defects so that they are legible for
developers.
03 Exploratory tests of the MyStore app

2
Reporting defects 3
Reporting defects

Properly reporting defects is an equally important element of a Tester's work as nding them.
It's not as easy as it may seem - it requires some practice and forming some good habits. A defect
report must be clear, concise, and legible, as it may have many recipients:

Developers - they will attempt to x the

reported defects
4
Testers - we will be executing con rmation
tests
Any other member of the team working on
developing the software in question (analyst,
product owner, stakeholders, etc.)
Quality of reports vs quality of work and developed software

The quality of our defect reports is evidence of the quality of our work

The imperative purpose of our report is to explain to a developer what does not work and how to
reproduce the defect step-by-step. The quality of defects that we report is proof of the quality of
our work. If our reports are written incorrectly or are incomplete they will shed a bad light on the QA
team and delay development work. 5

In order to improve the quality of software, it is important that teams collaborate

The sole nding of defects and their reporting does not improve the quality of software. Only once
the defect is removed we can speak of any improvement. We must collaborate as testers and
software developers, therefore it is very important that our reports are not o ensive to any person
or their abilities. They should always remain neutral and professional.
Is it certainly a defect?

Sometimes we may be uncertain if what we have discovered is in fact a defect in the application. We
should report it if:

Software is inconsistent with the requirements

The actual result di ers from the expected result of a test case
Data has been lost
6
Graphical elements of the application are displayed incorrectly

We may also sound our opinion based on our experience. But if we still remain uncertain as to
whether the report is actually a defect, or not, we should ask a more experienced tester or
analyst of their opinion. If no such person is within reach, it's better to report whatever we
have discovered.
What a defect report should look like?
Defect reports can take di erent forms depending on the software used for managing them and the
organization we are working for. They do, however, include some key elements, such as:

• ID - it allows for the defect report to be located quickly.

• Title - a very important element of the report, the most di cult one to create. A title should
include information on what is actually not working and where (in which module). In order to
provide the location of the defect, we can use brackets, e.g. [Settings]. Keep in mind that the title
shouldn't be too long or too general. 7

• Environment - operating system, browser, components of the computer, screen resolution, etc.
• Version of the tested application - environment (e.g. development, testing) and version number
of the app, on which the defect was discovered. If we don't provide a particular software version
there is a large chance that we will hear the famous "it works for me" response from a developer.
• Priority - it de nes how quickly the given report should be taken care of and how signi cantly it
in uences how the software works.
What a defect report should look like?

• Author - the best possible case is when the reporting person is also the person who will execute
con rmation tests, as this will take less time. Additionally, if a developer has any questions
regarding the report, they know whom to turn to for further explanation or help in reproducing
the defect.
• Initial conditions - all conditions which have to be met for the defect to be reproduced
successfully. These can include some speci c type of activity performed in the software (e.g. a
user is logged in as a mentor) or other applications working simultaneously (e.g. rewall, antivirus,
8
etc.).
• Steps/Detailed description - step-by-step instructions on what should be done to reproduce the
given defect. If a defect only occurs for particular data used in the test case, they should be
included here.
• Actual result - how did the software behave. Describe the improper activity of the application
here.
• Attachments - all additional attachments which can help reproduce the defect, e.g. URL,
screenshot, video, logs.
What else can a defect report include?

Test cases can include many di erent elds, such as:

• Reproducibility - indicates how often the defect is successfully reproduced. Before registering the
defect we should try to reproduce it at least once. If we are unsuccessful, we should make
additional attempts and determine what is the reproducibility of the defect. If we achieve the level
of 3 successful attempts out of 10 we can assess reproducibility at 30%. If we do not determine
the degree of reproducibility, and a developer will not be able to reproduce our reported defect in 9
the rst instance, our report will most probably be rejected, and we will hear the famous "it
works for me" line again.
• Expected result - the expected correct result of the performed steps.
• Category (type) - we can create our error categories which will allow us to easily identify the areas
in which there is the highest density of defects.
Examples of defect reports

10
Ways to report defects
Once we identify a defect there are two ways in which we can communicate our discovery to the
development team:

Verbally

This is a very quick way, but not very e ective, as the recipient may often forget what we have told
them, and other people on the project will not even know that we have reported anything. This type
of communication may only be used as a supplement to written communication. 11

Written communication

Writing down any information regarding a defect takes more time, but it allows for a better way for
the report to be managed and it gives us a degree of certainty that we will not forget how to
reproduce the defect. We may report a defect by e-mail, but a much better tool for this particular
purpose is a dedicated BTS (Bug Tracking System).
Bug Tracking Systems

Popular bug trackers allow for e ective reporting, cataloging, and management. Some of them,
aside from the functionality related to defects, also provide the means to manage entire projects
(like JIRA). Some of the more popular ones include:

12
Bug Tracking Systems - work ow

BTS systems additionally allow each team member to very easily monitor defects and testing
progress. We know exactly what happened to each defect report since it has been created until it is
xed. This allows for the proper work ow of the reported issues, which makes defect management
more e ective.

13
Good practices

While creating reports

Retest before registering a report.

Make sure you're not reporting a duplicate.

Report a defect immediately after it is

discovered. 14

Read your report before registering it.

Report only one defect per report.

Remember to retest the issue before closing

it.

Add screenshots/videos/logs to your report.

 Exercise
15
Review the MyStore app documentation
Review the MyStore app documentation
Within this exercise, you should review the documentation for the MyStore app.

The document is available here.

Duration of the exercise: 20-30 minutes

16

REMEMBER to update the appropriate issue in JIRA.

 Exercise
Execute exploratory testing of the MyStore app - 17

defect registration
Execute exploratory testing of the MyStore app - defect
registration

It's time for some testing!

Test! Test! Test! - report as many defects as you can possibly nd.

Address of the testing environment: https://courses-presta-dev.visuality.pl

18

Assign all of the identi ed defects to your lecturer.

REMEMBER to update the appropriate issue in JIRA and control all of the reported defects.
THE END 19