Bug Defect Tracking

Categorize the similar tasks into groups. The tasks can be easily tracked and it is easier for finding them for each member of the team. It is wise to separate the tasks by type.

When the number of tasks is large, it is hard to track the bugs. The tasks grow when they are shared among members of the team without much intention. The tasks should be small and not include multiple tasks in them. The larger tasks should split into smaller tasks, which helps the team members to review them easily.

Write down certain steps to reproduce bugs for developers, and avoid the steps which are large in number. Have smaller number of steps which is easier for identifying a but for a developer.

The tasks must always revert to the person who created it or required for reviewing it. If it is a bug, it should be reverted to the tester. The tester can close the bug, since he/she is the one who saw the bug first and can be sure for fixing it. A task should ‘never’ be closed by another person other than the one who created it.

Try to hide the tasks which are currently not having priority. Focusing on the important tasks, get the team to overview better.

If any bug found is confusing, it should be discussed with the developer.

The bugs should follow a proper cycle until closed.

If any bug closed by developer is not fixed, it should be reopened.

Never assume while tracking a bug.

New: In finding an issue in testing, all relevant checks are performed, like whether is was occurring in the previous release. If the issue is so, reopening the bug and creating new defect is done by changing the status of that defect to ‘new’.

Open: When a new bug is opened, development or project manager revises it, followed by assigning the task to the developer, and changes the status from ‘new’ to ‘open’.

The different bugs are:

1. Show-stopper / critical bugs: The core dumps, products abnormally shuts down and no work around will be found out, like OS automatic freezing.

2. Major Bugs: The work around is found, but the implementation can be done, like performance degradency.

3. Medium Bugs: These bugs include database errors, link errors, low response time

4. Low/minor Bugs: These bugs are typos, simple GUI errors.

A small and a comprehensive task description should be written for the developers to understand.

Steps to reproduce the step should be written.

Tasks with similar categories should be grouped.

The bugs should be prioritized on the basis of impact.

The module where the bug was found should be mentioned.

Depending on the nature of the bug, it can be supported by screen shots.

Expected results must always be written.

A statistical technique for making decisions which is used for selecting a limited number of tasks which produce significant overall effect. Pareto Analysis uses the ‘Pareto Principle’ – an idea by which 80% of doing the entire job is generated by doing 20% of the work.

When many possible courses of actions are completing the attention, the technique ‘Pareto Analysis’ is useful. In essence, the delivered benefit by each action is estimated by problem-solver, and selects the number of most effective actions which delivers the total benefit.

A bug is an error, mistake made in programming. An application is usually expected to be bug free. Bugs prevent the application to respond or behave the way it is expected.

Various categories of defects:

Omission: Failure to include or gather a requirement which causes a defect.

Lack of knowledge: When failure to understand a requirement due to lack of knowledge causes a defect.

Miscommunication: When incorrect or communication or misunderstandings in communication cause a defect to occur.

Accidental: When the requirement is gathered correctly and knowledge is available and even then a mistake is done.

A bug is defined as an error that was found before the application goes into production. A bug gives a subliminal impression which crawled into the developer’s code quite independently of the software developer.

A defect is defined as an error that was found after the application goes into production. It presents cold harsh reality which the engineer, analyst or designer actually get something wrong.

The following steps involved in the bug cycle process:

1. Bug investigation – when the tester find the bug

2. Bug assignment – when the tester assigns the bug to the developer

3. Bug fixing – when the bug is fixed by the developer

4. Bug retesting – when the developer fixes the bug and given to the tester

5. Bug closing and reopening – when the tester retested and the status is changed to ‘closed’.

A bug caused because of not understanding the requirement.

Null pointer exceptions.

Access violation bugs.

Incorrect format of dates.

Bugs due to incorrect syntax.

A bug is a fault in a program which causes it to behave abruptly. Bugs are usually found either during unit testing done by developer of module testing by testers.

A defect is found when the application does not conform to the requirement specification. A defect can also be found when the client or user is testing.

CAR identifies problem and perform a root cause analysis of the same. CAR needs to be performed at every project phase. Fishbone diagram is one of the ways to perform CAR.

CAR – Causal analysis and resolution

CAR identifies problem and perform a root cause analysis of the same. CAR needs to be performed at every project phase. Fishbone diagram is one of the ways to perform CAR.

DAR- Decision Analysis and Resolution.

This is to analyze possible decisions using a formal evaluation process that identifies alternatives against current resources.