Preparation of bug tracing report

By preparing defect tracking report for each build or cycle, it becomes easy to Estimate the bug density which is generally calculated as

                              “Number of defects/Lines of code”

This will help us in estimating the time requirement for the next build or cycle. Apart from this, it gives a clear view of the project bug tracking

Software Test Reporting the Results

When you have completed the execution of the test cases you will come up with

The result. Report the result to the team lead/project lead /Project manager.

(Note) Do not report a bug to a developer directly (Until you told to do so)

(Note) If the organization at which you are working has a bug tracking tool log the bug In the tool

Bug logging/tracking tool: -

A bug tracking tool is used to log all the bugs build wise/product Wise. It is configured centrally so that every one can access it through browser with the given privileges. Most of the bug tracking tools provides a facility of mail configuration and customization of the fields in it. When a bug is logged or updated the status will be sent to the TL/PL/PM as configured.

The process generally goes like this

a) Test engineer logs a bug in the bug tracking tool

b) A mail will be sent to the TL/PL/PM (if it is configured)

c) TL/PL/PM will review the bug and allot it to the corresponding developer

d) Developer fixes the bug and updates the status in the bug tracking tool. Mail will be sent to the TL/PL/PM about the updation & to the test engineer (If it is configured)

e) Test engineer will validates the bug and update the status as one of the following

  New

  Open

  Close

  Reopen

  FAD (Function as designed)

  DL    (Design limitation)

  Duplicate

 * Step “e” is called as a bug life cycle.

(Note1) 5&6 points will be updated in the bug tracker by a developer.

(Note2) If any bug that you have reported and developer updates its status as Fad or dl,     but still you feel it is a bug you can call for meeting and discuss its impact on the product and explain why you want to make it as a bug

(Note3) Never report a bug to a developer directly.

A bug logging /tracking tool has the following fields (In General):-

a) Bug id (This is a tool generated number)

b) Title    (Title of the bug)

c) Setup   (Give the installation details)

d) Steps to reproduce (includes expected & actual result)

e) Product

f) Version

g) Build

h) Operating system

i) Bug category (functional, design, documentation, GUI etc)

j) Bug Severity (High/major, medium/minor, low/trivial)

k) Status (New, open, closed, reopen, Fad, DL, duplicate)

l) Comments/notes

m) Attachments

(Note) These fields might be differing among bug tracking tools.

(Note) You can also customize fields as per requirements

Note on bug severities:

a) Major/high        : System inoperable, causes system to hang or crash

b) Minor/medium : Incorrect results or behavior with known reasons

c) Trivial/low        : Affects limited areas of functionality, cosmetic changes ETC

Reasons for software having bugs:-

Following are the most common reasons for a software application/system/product

Having bugs in it

a) Software complexity

b) Programming errors

c) In sufficient application requirements & poor design

d) Time pressures

e) Frequent changes in requirements

f) Usage of third party tools & software’s in the product/application/system

Test case Execution

This activity starts once the test case review has been completed. All the test cases are executed and results are marked as pass, fail or blocked.

Pass: - a test case(s) is marked as pass if it‘s expected result is matched with the Actual result

Fail: - a test case(s) is marked as fail if it‘s expected result is not matched with the Actual result

(Note1) Before you submit a failed case(s) as a bug try to reproduce it to ensure that

              It is consistent and it can be reproducible.

(Note2) Bugs which are not reproducible but occur unconditionally or unexpectedly but 

 Very frequently, such bugs can be reported by giving the sequence of steps you   

  Followed, system configuration at that Movement ETC

(Note3) You can take a snap shot of that bug and send it as an attachment for more clarity

  To the development team

Blocked: - a test case(s) is marked as blocked if the test case(s) is not executed because of non availability of the functionality or environment ETC.

(Note) Report the test case(s) with suitable comments why it is marked as blocked

Test cases Review

Review of test cases should be done in order to eliminate the duplicates, this activity makes easy to map the each test case(s) with its requirement. Once the test case review is completed we can prepare a test tractability matrix.

Test tractability matrix:

Is basically prepared to ensure that all requirements are covered and each Requirement has one or more use case(s).It is represented in a tabular format. This makes easy to identify which requirement has what test case(s).

It looks like the following.

SRS id	1.0
Use case id	1.1
Test case id	1.1.1

Use Case

The use case is made up of a set of possible sequences of interactions between   systems and users in a particular environment and related to a particular goal. The use case can be thought of as a collection of possible scenarios related to a particular goal, indeed, the use case and goal are sometimes considered to be synonymous. Use cases represent the interfaces that a system makes visible to external entities and their interrelationships. It has following components

a) Use case name

b) Brief Description / Goal: what is to be achieved?

c) Flow of events for <name> use case

d) Preconditions: what the situation must be before the use case can take place

e) Main Flow: the basic successful flow of events

f) Sub Flow (if applicable): subordinate flows

g) Alternative flows: variations in business conditions

i) Trigger: the event that causes the use case to happen (usually by an actor)

Test Case

A test case is a document that describes an input, sequence of actions and the expected output, in order to determine a product/system/applications requirement is correctly working or not. A test case should have the following information

a) Test case number

b) Test case name/title

c) Objective

d) Test conditions/setup

e) Input data requirements and sequence of steps

f)  Expected result

(Note1) Always prepare test cases from use cases it’s a good practice.

(Note2) Preparation of test cases should be started once SRS & design documents are

              Frozen. This type of approach is changed depending on the life cycle model

  That is selected for the execution for the project.

(Note3) IEEE – is a standard(s) for writing test cases.

Software Testcase Preparation

The primary objective of test case(s) preparation is to see weather requirements of the application/system/product are fully covered or not. Test Cases can be prepared from the use cases. If use cases or not available then, test cases can be Prepared from SRS & design documents.

Test cases are prepared using following techniques

Boundary value analysis

A test data selection technique in which values are chosen to lie along data extremes.  Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a systems works correctly for these special values then it will work correctly for all values in between.

Equivalence class path: -

Is a technique where test cases are designed with a valid and invalid range of Values Range is decided with reference to SRS. Examples are

a) Range

b) Set

c) Number of inputs

d) Exists/constraint

Error guessing

Is a test case design technique where the experience of the tester is used to guess what faults might occur and to design test cases specifically to expose them.

Few of the techniques are:-

a) Null input.

b) Long input.

c) Random input.

d) Almost correct input.

e) Spaces in strings.

f) Quoted strings.

g) All CAPS.

h) Negative numbers.

i) Special characters

(Note) All the above mentioned techniques for error guessing are valid if SRS has a Limitation(s) on it.