Quality Assurance

Process
Document13
o

Browser(s)
o

Type (bug,
enhancement)
o
Severity (as
reported by QA
engineer)
o

Detailed
Description –
Elements (with
date/personnel
stamp)
!
Login: provide
user name,
password, access
rights, group etc..
!

Landing Page:
Define page you
are taken to.
!

Navigation:
Define
link/selection area
& link/selection
chosen
!

Navigation:
Define landing
page, describe
page (continue 3
& 4 asrequired)
!
Issue: Identify
the outcome
of the sequence
!

Issue
Clarification:
Identify the
expected results
!

Issue Exposure:
Identify how this
impacts every
area - other
screens,database
etc.
!

Issue Wrap-up:
Specific Details
eliminating
variables or
providingdevelop
ers insight into
problem
!

Testing Wrap-up:
when this was
last tested, when
it last worked,
how itlast worked
etc.
!
Final Emphasis:
Specific
Environments,
Specific User
Groups,
anythingpreviousl
y stated which
needs more
emphasis
!
Screen shots
where/when
applicable

3.3 Handling
Procedures
In order to
accurately
identify,
investigate and
report problem
issues over the
course of
multipletesting
cycles, AppLabs
executes a
thorough process
once a problem
issues has been
identified.This
process is shown
in the below
diagram.The
below flow is
used when a
problem issue
is found, while
executing the test
plans. The
diagramis not a
flow designed to
review fixed
bugs. That flow is
outlined in the
"Fix Verification”
section of this
document.
Quality Assurance
Process
Document14
Problem IssueIdentifiedBug
ID inDefectColumn?Bug
Details inBug
Tracker Reviewed
byTester Add'l
InfoRequired?Open?Check
CurrentBug Status inBTSBug
Annotated &Report, Sent w/
Daily StatusReport
"F" entered inStatus
ColumnBug Re-OpenedDate,
Build #& Commentsin
ResolutionFieldBug Re-
Opened (or)New
BugEnteredThis will be
based on Discussion
w/Client. Will depend
on whether Bug wasclosed
during "this" testing cycle
ANDprocess to close specific
bug.Re-OpenedList Sent
toClient in
DailyStatus Report
Issue RemainsClosedTest
Plan isUpdated to
ReflectIssue as "not
abug" (if applicableEscalation
Request?Bug Annotatedin
BTSIssueRetestedAgain
(onDiffernentcombos /Case
Re-examinedStillExists?Bug
Added toBTSBug IDEntered
inDefect ColumnNoBug
Added to"Annotation"Report,
Sent w/
Daily StatusReport
AppLabs toTest
whenstatuschangedEscalatio
nAdded to
DailyStatus Report
Escalation Request will
bemade for 1 of 2
Reasons(1) Tester believes
issue ismore severe than it's
currentstatus / fix date(2)
Issue is blocking testingof
Key
FunctionalityYesYesIssueClo
sedNoYesFixed?Closed?Rej
ected?Postponed?FinishedN
oNoYesYes"Not
aBug"?Duplicate?Tester Revi
ew &Agree?Bug Annotated
&Bug Identified in
Daily StatusReport
CannotReproduce?NoClientA
grees?Bug Re-
OpenedY e s
Y e s NoYesNo
YesNo
YesNoYesNoNoBugRemains
ClosedYesNo"F" entered
inStatus ColumnYesYes

3.4 Severity
Levels
A severity level is
supplied for each
problem issue
identified. AppLab
s identifies five
levels
of severity.Severi
ty Level 1:
CriticalProgram
aborts and the
system cannot
function further
Quality Assurance
Process
Document15

Severity Level 2:
HighMajor
functionality of
the application is
performing
improperly.Severi
ty Level 3:
MediumA minor
or non-mission
critical aspect of
the application is
performing
improperly. Thee
xistence of this
error does not
affect the users
ability to access
all crucial areas
andfunctionality
of the
application.Severi
ty Level 4:
LowThere
are cosmetic or
minor usability
issues. The
application
functions
properly even
withthe existence
of these
issues.Severity
Level 5:
ChangeThese
are
change suggestio
ns provided by
AppLabs QA
engineers. The
application
stillmeets its
functional and
design
requirements.
4.0 Fix
Validation
Process
The fix validation
process is
a critical
component to
success software
development. To
that end,AppLabs
relies on a series
of steps so issues
reported by
development as
“fixed” are
properlyhandled.

We retest each of
these items,
annotation item
details within the
bug tracker, and
changethe
issue’s status
accordingly