Ministerul Educaţiei, Culturii și Cercetării al Republicii Moldova

Universitatea Tehnică a Moldovei

Facultatea Calculatoare Informatica și Microelectronică

RAPORT
Lucrare de laborator Nr.2
Disciplina: Calitatea Software

Tema: Bug Review

A efectuat: st. gr. TI-171, Iepuraș Daniel

A verificat: asist. univ., Lungu Mihai

Chișinău 2020
Laboratory task:
Try to execute bug steps on a new version of website. Apply right statuses and
modifications for existing bugs. Find any bug description discrepancies on opened
bugs(missing, attributes, or incorrect definition for bug fields).
Give a detailed answer why statuses have changed in bug comments.

Introduction to errors categories and those states:

Defect can be categorized into the following:

Wrong: When requirements are implemented not in the right way. This defect is a
variance from the given specification. It is Wrong!
Missing:  A requirement of the customer that was not fulfilled. This is a variance
from the specifications, an indication that a specification was not implemented, or a
requirement of the customer was not noted correctly.
Extra: A requirement incorporated into the product that was not given by the end
customer. This is always a variance from the specification, but may be an attribute
desired by the user of the product. However, it is considered a defect because it’s a
variance from the existing requirements.
ERROR: An error is a mistake, misconception, or misunderstanding on the part of a
software developer. In the category of developer we include software engineers,
programmers, analysts, and testers. For example, a developer may misunderstand a
de-sign notation, or a programmer might type a variable name incorrectly – leads to
an Error. It is the one which is generated because of wrong login, loop or due to
syntax. Error normally arises in software; it leads to change the functionality of the
program.
BUG: A bug is the result of a coding error. An Error found in the development
environment before the product is shipped to the customer. A programming error that
causes a program to work poorly, produce incorrect results or crash. An error in
software or hardware that causes a program to malfunction. Bug is terminology of
Tester.
FAILURE: A failure is the inability of a software system or component to perform
its required functions within specified performance requirements. When a defect
reaches the end customer it is called a Failure. During development Failures are
usually observed by testers.
FAULT: An incorrect step, process or data definition in a computer program which
causes the program to perform in an unintended or unanticipated manner. A fault is
introduced into the software as the result of an error. It is an anomaly in the software
that may cause it to behave incorrectly, and not according to its specification. It is the
result of the error.
The software industry can still not agree on the definitions for all the above. In
essence, if you use the term to mean one specific thing, it may not be understood to be
that thing by your audience.
Various States of a Bug during its Life Cycle are:
1. New Bug: When a bug is posted for the first time, its state is called “NEW”. This
implies that the bug is not approved yet.
2. Open Bug: Once the software tester posts a bug, the team leader approves it after
satisfying himself about its genuinity, and changes its state to “OPEN”.
3. Assigned Bug: Once the lead changes the state to “OPEN”, the bug is assigned to
the concerned developer team. The state of the bug is changed now to “ASSIGNED”.
4. Test Bug: Once the developer fixes the bug, he transfers the bug to the testing team
for next round of testing. After fixing the bug & prior to releasing it back to the
testing team, the state of the bug is changed to “TEST”. In other words, the state “Test
Bug” implies that the bug has been fixed and is released to the testing team.
5. Deferred Bug: When the bug is expected to be fixed in next releases, its state is
changed to deferred state. Many factors are responsible for changing the bug to this
state. Few of such factors are priority of the bug may be low, lack of time for the
release or the bug may not have major effect on the software.
6. Rejected Bug: If the developer feels that the bug is not a genuine one, he rejects it.
This leads change of state of the bug to “REJECTED”.
7. Duplicate Bug: If a particular bug gets repeated more than once or two bugs point
towards the same concept, then the status of one of the bug is changed to
“DUPLICATE”.
8. Verified Bug: Once the developer fixes the bug and its status is changed to
“TEST”, the software tester confirms the absence of the bug. If the bug is not detected
in the software, the tester approves that the bug is duly fixed and changes its status to
“VERIFIED”.
9. Reopened Bug: If the bug is detected again even after the bug is claimed to be
fixed by the developer, the tester changes its status to “REOPENED”. The cycle
repeats again & again till the bug gets ultimately fixed & get closed.
10. Closed Bug: Once the bug is fixed & the tester confirms its absence, he changes
its status to “CLOSED”. This is the final state which implies that the bug is fixed,
tested and approved.

Work progress:

The bugs have been retested on the new domain of the website. The retest results were
added as comments for those bugs.

Figure 1. Comments after retesting

So the bugs still exist on the new version of the app and have therefore been
transferred to "In Progress" to specify that they still affect the app and the developers
continue to work on fixing the bugs described in the previous lab work.
 Figure 2. Retested bugs marked as InProgress

Conclusion
In this lab work the error steps on the new version of the website were executed:
https: //adoring-pasteur-3ae17d.netlify.app/mens.html. Specific states were also
applied, corrections were corrected for existing errors, and comments were added
about changes to the bug description.