Testing_126 : Software Configuration Management

Software Configuration Management :-

• The process of identifying, organizing, and controlling changes to the software during development and maintenance.
• SCM is a support activity that makes technical and managerial activities more effective.
• SCM operates throughout the software life cycle.
• A methodology to control and manage a software development project.

Purpose of SCM :-

• Establish and maintain the integrity of work products.

Why do we need SCM :-

To manage :

• Multiple people have to work on software that is changing.
• Projects delivered in several releases (builds).
• Software must run on different machines and operating systems (rapid evaluation of software and hardware).

Problems Resulting from Poor Configuration Management :-

• Can't roll back to previous subsystem.
• One change over writes another.
• Which code changes belong to which version ?
• Faults which were fixed Re-appear.
• Tests worked perfectly-on old version.
• Shouldn't that feature be in this version ?

Using Configuration Management :-

Advantages :

• Multiple project members concurrent access.
• Orderly control of change.
• View diffs
• Rollback changes
• Release management
• History
• One of the key process area in SEI CMMI level 2.

The Sample List of Software Configuration Items :-

• Management plans (project plan, test plan etc.)
• Specification (Requirements, Design, Test cases etc.)
• Customer documentation (implementation manuals, user manuals. on-line help files)
• Source code (java, .net, php etc.)
• Executable code (exe's etc.)
• Libraries (packages,#include files, apis, dlls etc.)
• Database (data being processed, test data etc.)
• Production documentation (how to make our application or installable application)

SCM - How it is accomplished ?

All these goals are accomplished through Version control.

Version control :

Commonly used in engineering and software development Changes identified by incrementing on associated number.

Done in two ways :

1) Manually

2) Using Configuration Management Tool

1) Manually :

In company server, administrator creates the project folder and he can provide the access permissions to all users (project members).

2) Automation (Configuration Tools) :

Open source-Free :

• Cvs - http://evshome.org
• Subversion - http://subversion.tigris.org
• Darcs - http://ww.abridgegame.org/darcs/

Commercial :

• Pvcs - http://www.pvcs.synergex.com/
• Perforce - http://www.perforce.com/
• Visual source safe - http://www.microsoft.com

How does Configuration Tool works :-

• Vss & Cvs uses a client/server architecture.
• A sys admin would normally install the server.
• The server maintains the repository (database). 
• Developers and test engineers use the client.
• The client allows for check-in, check-out the files etc.

Repository :

A server where the files (project deliverables) are stored

Check-out :-

Copies a working copy from the repository

Check-in :-

Copy the changes on the local files to the directory

(The vc software takes care of changes since the last synchronization)

Undo Check out (Uncheck-out)

• The undo check command does just that the files returns to the status it had before it was checked out.
• This can be done even if changes have been made to the local copy of course, these do not go into the database.

Navigation to MS VSS 6.0 (Visual Source Safe)

• It is a commercial software from Microsoft
• Software is available in two types
• VSS server software
• VSS client software

• VSS server software is installed on organizational server machine by administrator.
• VSS client software to be installed in to our local machines (project member machines)
• Administrator will create the users for VSS and he will provide access permissions for all users (projects members) to access VSS repository.

Permissions :

• Read
• Check-out, Check-in
• Add, rename, delete

Navigation to Launch VSS :-

• Start -> Programs -> Click on Visual source safe -> Observe VSS login window -> Enter valid username, password and click on (ok) -> Observe VSS home page is displayed.

The test engineers responsibilities are :

1) Check-Out files (copy files from VSS)

2) Check-In Files

1) Check-Out (copy files from VSS)

• Go to projects folder, select the file and right click on the file and click on view and save as the file to local working folder (or) select files and right click files and click on get latest version (or) Right click on file and select CHECK-OUT.
• This is the way we can get the required documents (test plan, requirements specification, functional requirements, templates and test cases) from VSS.

2) Check-In files

• First check-out the file from VSS local working folder.
• Before check-out, we need create set working folder.
• Go to file menu -> click on set working folder browse and select existing working folder and click on (ok).
• Now go to the file and right click the file and click on check-out. Observe file is copied to local working folder. Do the necessary modifications in file and saves the file into local machine.
• Go to VSS, right click the file and click on check-in, observer modifications are updated successfully and new version will be created automatically with your modifications.
• Even we can go back to the previous versions, right click the file and click on show history.
• Even we can compare the files.

Testing_125 : Execution Process

In this article, We understand how the Test Cases Execution Process Goes in the Projects....

Process to Execute the Test Cases (Based on Sprint Release) :-

Testing Process starts after the Release notes and Requirement Documents...

Version 1.0 => In Ver 1.0, We created 150 Test Cases. Then Executed 50 Test Cases from which 30 TCS Passed and 20 TCS Failed. Then you reported Defects to the Developer. Developer separates defects based on Priority. He fixed the major (P-1) one first.

1) Project Name :-	XYZ Inc.	7) # of Test Cases Blocked :-
2) Version :-	1.0v	8) # of Test Cases not Executed :-	100
3) # of Test Cases :-	150	9) of Defects Fixed
4) # of Test Cases Executed :-	50	10) # of Defects Closed :-
5) # of Test Cases Passed :-	30	11) # of Defects Found (Based on Priority) :-	P-1 = 10 P-3 = 5 P-4 = 5
6) # of Test Cases Failed :-	20	12) # of Defects Reopened :-

Version 1.1v => In Ver  1.1v, Developer fixes all priority based defects and send them to Test Team. We perform Retesting from which 3 Defects Reopened.  After Retesting we continue the remaining test cases. We Executed another 50 TCS from which 25 Passed, 20 Failed and 5 Blocked. Then you Reported Defects to the Developer. Developer separates Defects based on priority. He fixes major (P-1, P-2) one first.

1) Project Name :-	XYZ Inc.	7) # of Test Cases Blocked :-	5
2) Version :-	1.1v	8) # of Test Cases not Executed :-	50
3) # of Test Cases (Remaining) :-	100	9) # of Defects Fixed :-	10
4) # of Test Cases Executed :-	50	10) # of Defects Closed :-	7
5) # of Test Cases Passed :-	25	11) # of Defects Found (In 1.1v) :-	P-1 = 8 P-2 = 6 P-4 = 6
6) # of Test Cases Failed :-	20	12) # of Defects Reopened :-	3

Version 1.2v => In Ver 1.2v, Developer fixes all Priority based Defects (P-1 = 8, P-2 = 6 from 1.1v, P-3 = 5 from 1.0v and 3 reopened) and send them to Test Team. We perform Retesting (all Defects Closed). After Retesting we continue the execution of remaining 50 Test Cases (along with 5 Blocked which are now Fixed) from which 50 Passed and 5 Failed. Then you Reported Defects to the Developer.

1) Project Name :-	XYZ Inc.	7) # of Test Cases Blocked :-
2) Version :-	1.2v	8) # of Test Cases not Executed :-
3) # of Test Cases (Remaining) :-	50	9) # of Defects Fixed :-	22
4) # of Test Cases Executed + 5 blocked :-	55	10) # of Defects Closed :-	22
5) # of Test Cases Passed :-	50	11) # of Defects Found (In 1.2v) :-	P-2 = 5
6) # of Test Cases Failed :-	5	12) # of Defects Reopened :-

Version 2.0v => After developing the 2.0v, Developer send Release notes and SRS for Testing Team and Also previous fixed 16 Defects. After reading Requirements we created 100 Test Cases for 2.0v. But before execution of the 2.0v we have to perform Retesting on fixed Defects and also Perform Regression Testing on Old Functionality for checking whether its fully integrated with new functionality or not.

1) Project Name :-	XYZ Inc.	7) # of Test Cases for Regression Testing :-	150 (Old Functionality)
2) Version :-	2.0v	8) # of Test Cases Passed :-	130
3) # of Test Cases (of 2.0v) :-	100	9) # of Test Cases Failed :-	20
4) # of Test Cases Executed :-	100	10) # of Defects Fixed (of old Ver) :-	16
5) # of Test Cases Passed :-	70	11) # of Defects Found (In 2.0v) :-	50
6) # of Test Cases Failed :-	30	12) # of Defects Reopened :-	3

...And the process will continue until the project completed and Deliver to Customer.