change request manangement in software testing

As companies strive to manage their Software Development Lifecycle (SDLC) projects, they are inundated with requirements, software and data changes, and defects. In order to manage costs, customer expectations and priorities, a Change Request Management methodology must be developed early in the process.

Like sailing a boat in a true straight line, continuous course corrections are needed. In software development organizations, knowing how to triage, prioritize, organize, and manage change allows the boat (the SDLC) to stay on course.

Since change is inevitable, it would be insane to know it was going to happen and to do nothing to manage it. The Change Request Management (CRM) System is a tool to be used throughout the SDLC.

Here are just three benefits of a Change Request Management System:

A solid risk management program requires detailed information from the CRM.

Metrics from the CRM allow a project manager to evaluate the efficiency of and the effectiveness of the SDLC process.

Triaging and prioritization of issues and resources are determined by reviewing the details of the CRM.

1. How Does Change Request Management Work

Change Request Management is the process of tracking all of the changes that come from different sources and become part of a product. These Change Requests are tracked from the first awareness of need until the final disposition.

To define “How” with respect to Change Request Management requires a definition of actions and workflow. Actions are described below. A discussion of workflow requires more in depth knowledge of the specific situation and an assessment of the gaps that need to be bridged.

Identification

This is the point at which a change request is recognized. It is an important step in the process. Changes may be initiated from many interactions. Discussions, analysis and use of the product are very common initiation points for change requests. It is important to capture the context of the discussion, analysis or use accurately so that the change request can be evaluated from the appropriate perspective. Identification is part of the Submitting Phase.

Instantiation

This is the point where the change request is documented. It can be referred to as the creation, entering or inserting of a CR into the Change Request system. We recommend that the CR be documented in an on-line system. For the purposes of this document, all potential change requesters are provided access to the Change Request Management System for the purpose of instantiating new change requests. We understand that some organizations limit this access and perform Triage (see below) before instantiation. On-line submission is facilitated with a form designed to enter critical data for triage.

The form has key fields like a Description, Title, Reference Number, Assignee, Submitter, Severity, Priority, etc.

Triage

If all change requestors are able to enter Change Requests, an efficient and effective means of disseminating work and defining the disposition of each change is needed. We suggest that a team be created. The team is called the Software (or System) Configuration Control Board (SCCB). This group’s members typically include the following: QA, Development, Test, Product Management and Business Analysis.

There are two primary concerns for this group. The first concern is to review the fields entered by the requester with the following question in mind, “Is the CR properly categorized \ classified?” This means that the SCCB is tasked with maintaining consistency in the content of the CR as well as overall enforcement of a common standard for the assignment of severity and priority. The second major concern is to define the next step in the life of the CR.

Update

The CR record tracks each step in the life of the Change Request. An online system has a form to record updates. Permissions vary by user, group, type of field and state of the CR. Because permissions vary by user, group, type of field and state of the CR, the forms for updating vary in the fields that are displayed.

The update form invariably contains many of the fields that are on the submit form. Permissions determine the user’s capability with any given field on any given form.

Some reasons to update a CR are:

A new assignee is needed

More requirements are needed

More information is needed

A comment is needed

The change is ready for testing

The change is completed

Closure

This is the act of setting a CR to the closed state. There is special processing and meaning associated with the process. “Closed” means the CR is ready for deployment. It has successfully completed testing.

When a CR is closed, the following fields are typically set:

State (gets set to “Closed”)

Date Closed

Version Resolved

Release Name

RELATED POST

DAY 1 MICROSOFT DOT NET FRAME WORK

DAY 2 MICROSOFT DOT NET BASE CLASS LIBRARY

DAY 3 MICROSOFT DOT NET CLASSES AND STRECTURES

DAY 4 METHODS IN FRAME WORK

DAY 5 INPUT VALIDATIONS IN DOT NET PART ONE

DAY 6 INPUT VALIDATIONS IN DOT NET PART TWO

DAY 7 DATA TYPES IN DOT NET

DAY 8 DATA TYPES IN DOT NET PART TWO

DAY 9 IMPLEMENTING PROPERTIES IN DOT NET

DAY 10 DELEGATES AND EVENTS

DAY 11 OOPS INTRODUCTION

DAY 12 POLYMORPHISM

DAY 13 INHERITANCE AND POLYMORPHISM

DAY 14 EBUGGING TOOLS IN DOT NET

DAY 15 DEBUG AND TRACE IN CLASSES

DAY 16 UNIT TEST PLAN

DAY 17 EXCEPTIONS IN VISUAL STUDIO

DAY 19 ADO.NET INTRODUCTION

DAY 20 DATA ACCESSING IN DOT NET

DAY 21 DATA BASE OBJECTS


No comments:

Post a Comment