Bug Life Cycle or Defect Life Cycle?

Bug Life Cycle or Defect Life Cycle:

Following is a Diagrammatic Representation of Different phases of Bug Life Cycle

 
 

 

 Today I am going to be share what is Bug Life Cycle or what is Defect Life Cycle and what are types of status are there. Defect Life Cycle is explain entire history of the defect. When it was found, who was founded and now it is which status like these details we will get.

               In Bug Life Cycle or Defect Life Cycle we have different types of Status.

·         New

·         Assigned

·         Open

·         Duplicate

·         Fixed    

·         Verified        

·         Re-Open

·         Closed

·         Deferred

New: When testing team doing testing, testing team will find some Bugs. Whenever testing team will find the Bug they wants to raise the Bug, then only Development team will know what the issue. For that some Organization’s using some tools (Bug zilla, QC).  Some Organization’s using Excel Sheets.

               Whenever testing team will find the Bug they want to raise the Bug, when a defect is logged and posted for the first time then we can, Status is NEW.

Assigned: Once the testing team posted a BUG, and then development team lead will check and assign that bug to his team. At they set status Assigned.

OPEN: Once the defect is raised, automatically mail will generate to the Assigned Person. While raise the Bug at the time only testing team to will assign whom we are going to be Assign the Bug. For that we have one option “Assigned to”. Then The Assigned Person will open the Bug and try to fix the Bug. At the they will change the status “OPEN”. By using theses Status we can track the Bug is in which Status.

Duplicate: Sometimes testing team will open same bug more than one time. When development team open the bug to fix, if they identified the raised bug is already logged then they will set the status as Duplicate.

Fixed: Once the Development team is fixed the Bug, they will change the status as “Fixed”. Then testing team will do Re-testing based on the output testing team will “Re-open or Close” the defect.

Verified: Once the defect is fixed by the Development team then testing will verify the modified code. May be it will take some time to verify that code at the Testing team will set the Status as Verifying.  If the modified code is working  is working based on the Requirement Testing team will set the status  “Closed”, Otherwise testing team will  Re- Open the Defect.

Re-Open: After fixing the Bug, testing team will do Re- testing the Application based on the Output testing team will Re-Open or Close the defect. If the application is not working based on the Requirement then testing team will Re- Open the Defect.

Close:  If the application is working based on the Requirement then testing team will close the Defect.

Deferred: If the bug is changed to deferred state means the bug is expected to be fixed in next releases.  

Quality Standards

1)ISO: 

International Organization for Standardization known as ISO. It is an International Standard setting body composed of representatives from various national standards organizations. The three official languages of the ISO are English, French and Russia.

CMMI: The Capability Maturity Model (CMM)[1] is a development model created after study of data collected from organizations that contracted with the U.S. Department of Defence, who  funded the research. This model became the foundation from which Carnegie Mellon created the Software Engineering Institute (SEI). The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.

The Capability Maturity Model was originally developed as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project. The model is based on the process maturity framework first described in the 1989 book managing the Software Process by Watts Humphrey. It was later published in a report in 1993[2] and as a book by the same authors in 1995.

Levels of the CMM (Capability Maturity Model)

There are five levels of the CMM:

Level 1 - Initial

• Processes are usually ad hoc and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.
• Organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.

• Software project success depends on having quality people.

Level 2 - Repeatable

• Software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
• Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.
• Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).
• Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimate.

Level 3 - Defined

• The organization’s set of standard processes, which is the basis for level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.
• The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.
• A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

 Level 4 - Managed

• Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. At this level organization set a quantitative quality goal for both software process and software maintenance.
• Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques.
• A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

  Level 5 - Optimizing

• Focusing on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.
• Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.

• Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.
• A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.

 

Difference between Verification and Validation

Verification: In Verification we are verifying weather the project is done according to the specification or not. In Verification we don’t want to execute the code for finding the defect. Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.

Example: I am giving one simple example to understand what Verification is.  Nowadays we are trying to buy products through online only. Suppose we are trying to buy cloths through online.  In websites just we are checking the color and size of the product. If it is available without any trail we will try to give order. Here we are checking the product is reaching our requirements or not. Once the product is reached to us then only we will trail that product. If we will satisfy then well, otherwise we want to resend. Now we will come to the subject like that , just we are checking the application how it is look like the Application developed  is according to the specification or not. Mainly we are checking how they designed the application.

Validation: In Validation we are verifying weather the product meets the customer requirements or not.Validation is carried out with the involvement of testing team.In Validation we want to execute the code for finding the defects.

Example:Here I am giving some clarification for the above example. Without buying through online just we step in to the show room and select which is suitable for us and once trail then we will buy definitely the product will be good. In Validation we are checking how the product is working, if we are checking any application then how the application is working, the application meets the customer requirements or not.

Verification	Validation
1. In Verification we are verifying weather the project is done according to the specification or not	1. In Validation we are verifying weather the product meets the customer requirements or not
2. In Verification we don’t want to execute the code for finding the defect.	2. In Validation we want to execute the code for finding the defects.
3. Are we building the system right?	3. Are we building the right system?
4. In Verification human beings are checking of files and documents.	4. In Validation is computer based execution of program.
5. It is Static type of testing.	5. It is dynamic type of testing.

what is Requirement Treasability Matrix (RTM)

Requirement Treasability Matrix (RTM) is a Document. Usually it is in the form of a table. RTM is showing the relationship between Test Requirements and Test cases (or) Test scenarios. The purpose of the Requirement Treasability Matrix is to make sure that all the requirements are covered in test cases and all the requirements are tested. Treasability Matrix links a Business Requirement Specification Document to its Corresponding test cases.

Types of Traceability Matrix:

·         Forward Traceability – In Forward Traceability Matrix we are trying to map from Requirements to Test cases this is Forward Traceability Matrix.

                               

Sl no	BRS ID	Test Scenario Id	Test Case Id
1	1.0	1.0	1-4
2	1.0	1.0.1	5-8
3	1.0	1.0.1	9-12
4	1.1	1.1	13-18

·         Backward Traceability – In Backward Traceability Matrix we are trying to map from Test Cases to Requirements this is Backward Traceability Matrix.

Sl no	Test Case Id	Test Scenario Id	BRS ID
1	1-4	1.0	1.0
2	5-8	1.0.1	1.0
3	9-12	1.0.1	1.0
4	13-18	1.1	1.1

We think that you will get a clear idea of RTM. If you people have any example on RTM? Then you can share it in comments the section below.