Components of a Defect Report

Excelon prides itself on providing one of the best documented bug reports in the industry. Our talented team of Quality testers has experience working with a wide array of reporting tools including Quality center, PVCS, PeopleSoft and Bugzilla.

A good bug report consists of the following elements:-
1. Bug Title: Concise but should be clear enough to briefly described the encountered problem
2. Steps to reproduce: Provide clear and concise steps to reproduce the problem. Augment with as much information as possible to help the development team reproduce the problem
3. Actual and Expected Result: What was the actual and expected outcome of the test case
4. Severity: This describes the degree to which the product or service is affected by the encountered scenario.
5.Priority: This describes how quickly the reported problem needs to be fixed.
6.Environment: This is critical if the product is being tested on multiple servers, databases, browsers or operating systems. Clearly specify the environment being used for testing in this column.
7.Files \ Attachments \ Screenshots: Augment the bug report by adding all relevant files used in testing or obtained as output, Server or console logs as attachments and screenshots of any encountered error

There can be several more fields added to bug reports depending on the requirements of the clients. This includes the sub component of the project, version, external or internal reported defects etc. Excelon will work with you on an individualized basis to customize the reporting solution best suited to your needs

Defect Tracking and Bug Reporting

Our bug reports are detailed with stepwise procedure to recreate the issue. They are assigned priority and severity according to a set protocol mutually agreed on by the development team. The bug reports are augmented with screenshots, server logs and database validations whenever required.

Defect Life Cycle
The life cycle of a defect (Bug as it is normally referred to) starts with its creation. The following statuses are generalization and they might differ slightly from organization to organization but the crux remains same

1. New \Open
The Quality Engineer encounters a deviation from the requirements and opens a defect. The defect is then in the open status

2. Assigned
The project manager\dev lead\QA lead assigns the defect to a developer for fixing and the defect is in Assigned status. In this status it is being worked on by the developer. Once the developer has fixed the bug and verified the fix on the development environment, he marks the bug as Fixed\Ready for QA and assigns back to the Quality Engineer

3. Fixed\Ready For QA
In this state, the bug is owned by the Quality Analyst who verifies that the fix made by the developer has indeed fixed the issue. The QA also performs a regression of any other feature that he\she thinks may have been impacted by the changed

4. QA Accepted\Closed
If the Quality Analyst is satisfied with the fix made to the change request, he closes the bug and mark it as fixed\QA Accepted. If the bug is not fixed, It is rejected and goes back to the developer in Assigned status.