Bug Defect Tracking Interview Preparation Guide

Download PDF

When a bug is found in a module, it must have followed a series of steps. The steps must be noted down by the tester in order to replicate the bug again. Reproducing a bug means following the same steps to find the bug.

Bugs that remain dormant or unhidden are latent bugs. These bugs are not found until one or more releases of the product. Example of such bugs can be the date issues like the y2k.

Golden bugs are bugs that may affect the critical functionality of the system.

When the bug is found by the tester, the status is marked as NEW. Once this bug is verified by the test lead for its validity, the status is changed to OPEN.

To analyze possible decisions by using a formal evaluation process which identifies the alternatives against established criteria is done by the DAR. For example a project is to use a third party tools and will not depend on only one tool but evaluate by using three to four tools. In this process certain alternatives are available in case of problems.

Causal Analysis and Resolution is the process of analyzing

- defects, problems and good practices/positive triggers in a project.
- Root cause of the same
- Identity the respective corrective and preventive actions
- Tracking these tasks to closure.

The identification of the root causes scientifically and carrying out their corrective and preventive actions is the advantage of CAR. At the initial stage, all phase and at the end stage of the project, the CAR is needed to be performed on a monthly basis. CAR can be done by using ‘fishbone’ diagram.

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.

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.

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.

A bug caused because of not understanding the requirement.
Null pointer exceptions.
Access violation bugs.
Incorrect format of dates.
Bugs due to incorrect syntax.

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 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.

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.

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 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.

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 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.

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.

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’.

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.

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

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.

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.

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.

1. Title should be clear:

A good title is a must, which the essence of the bug report be well grasped by the developer.

2. One but per report:

A bug report should have only one bug and not more or no less. In case more bugs are placed, some of the bugs may be overlooked.

3. Minimum, quantifiable steps to reproduce the problem:

This is a very important tip. Developers need to get the problem in the shortest possible time. So the tester needs to help them for doing just that task. Testers need to have few rounds of testing and be able to produce the problems using minimum steps.

4. Expected and observed results:

A bug report should always contain the expected and the observed result. The developer does not think that the bug is a real bug. Testers should take the responsibility to explain the developers that went wrong.

5. The build that the problem occurs:

It is common the daily builds. If the exact problematic build is not specified by the tester, it is hard for developers to resolve an already-solved problem.

6. Pictures:

‘A picture is worth a thousand words’! Certain times, the words do not flow. If such situations, it is better to have a clear picture that perfectly illustrates the problem.