HOME > Community > Projects > qa

VSS Profile Test Specification for Generic VCS Module Test Specification

Author: Peter Pis
Version: 1.0.0
Last update: 05.02.2005
Introduction: Microsoft's Visual SourceSafe tool is one the supported version control systems in the IDE. This document describes how VSS profile for Generic VCS module should be tested in order to know whether all of its commands work correctly. Legend: - this icon represents a test case that is part of validation suite and is used during Q-build testing. - this icon represents a test case that was automated and is run daily in test runtime.
Comment:

1. Global commands
2. Registering VSS directory
3. Repository creation
4. Regular development
5. Additional commands
6. Additional features

Test suite 1: Global commands

Purpose: This suite tests functionality of VSS global commands.
Setup: Be sure to have Microsoft Visual SourceSafe 6.0 or higher installed on your computer with an account created for you.

# Test case Description

VSS global command

1. Invoke Versioning | VSS | Global Get Latest Version from main menu.
2. Verify that Working Directory, "User Name", "VSS Command", "Project" and "VSS Database" textfields and "Get Latest Version", "Make the Local Copy Writable" checkboxes appeared in the dialog.
3. Setup "Working directory" to the directory you prepared e.g. D:\Tests\VSS\Work1.
4. Setup "VSS Database" to the directory as required and push "OK".

RESULT: "VSS D:\Tests\VSS\Work1" versioned directory must be mounted into "Versioning" tab of the explorer. Verify that this versioned directory is displayed in "Versioning Manager".

Teardown: Now invoke Versioning | Versioning manager from main menu. Select added "VSS" versioned directory and push "Remove" button.

Test suite 2: Registering VSS directory

Purpose: This suite tests whether it is possible to mount VSS filesystem according to settings specified in mounting wizard which are defined in chosen VSS profile.
Setup: Be sure to have Microsoft Visual SourceSafe 6.0 or higher installed on your computer with an account created for you. Create new "Standard - Java Application" project in working directory named "Test".

# Test case Description

VSS settings available

1. Invoke Versioning | Versioning Manager from main menu and push "Add..." button.
2. Choose proposed VSS profile from the list.
3. Verify that "User Name", "VSS Command", "Project" and "VSS Database" textfields and "Get Latest Version" appeared in the dialog.

RESULT: The "Profile" page of the wizard must contain all fields plus "Unix Shell" in case of Windows 95/98/ME. "VSS Command", "Project" and "VSS Database" must be preset with default values.

VSS connected

1. Setup "Working Directory" to the directory you prepared e.g. D:\Tests\VSS\Work1.
2. Setup your name to "User Name" textfield.
3. Make sure that "VSS Command" is set correctly with SS binary.
4. Make sure that "VSS Database" contains directory with srcsafe.ini file.
5. Eventually setup "Unix Shell" in case of Windows 95/98/ME system and uncheck "Get Latest Version" check box.
6. Give your password and push "Finish" button.

RESULT: "VSS D:\Tests\VSS\Work1" filesystem must be mounted into explorer and status line must contain "Command Refresh finished" message.

Teardown:

Test suite 3: Repository creation

Purpose: This suite tests whether it is possible to upload source code into VSS repository. It is essential to start version control over new files in order to work with them later on a daily basis.
Setup: The repository of VSS must be completely empty.

# Test case Description

Create projects

1. Switch to "Files" tab of explorer.
2. Invoke VSS | Create Project action on "Test" node.
3. Type "For testing purpose." as reason into "Create Project - Test" dialog and push "OK" button.
4. Confirm the information message.

RESULT: Project must be created successfully and appropriate node must have [Current] status.

Multiple project creation

1. Select folders "src" and "src\test" as one multiselection using CRTL key.
2. Invoke VSS | Create Project action on this multiselection.
3. Type "For testing purpose." as reason into "Create Project - src ..." dialog and push "OK" button.
4. Confirm the information message.

RESULT: All projects must be created successfully and appropriate nodes must have [Current] status.

Single file addition

1. Invoke VSS | Add action on "A_File [Local]" node.
2. Type "Generated A_File class." as reason into "Add - A_File.java" dialog and push "OK" button.
3. Confirm the information message about successful addition.

RESULT: The status of "A_File" node must change to [Current].

Multiple file addition

1. Select remaining [Local] files as one multiselection using CTRL key.
2. Invoke VSS | Add action on them.
3. Type "Auto-generated class file." as reason into "Add - D_File.java..." dialog and push "OK" button.
4. Confirm all the information dialogs about successful addition.

RESULT: The status of all remaining nodes must change to [Current].

Teardown:

Test suite 4: Regular development

Purpose: This suite tests the most often used commands of typical VSS user.
Setup: No preparation required.

# Test case Description

Checkout a file

1. Switch to "Versioning" tab of explorer.
2. Double click "A_File [Current]" node. It will be opened into editor.
3. Right click "A_File [Current]" node in explorer.
4. Select VSS | Check Out from the popup menu.

RESULT: After a while the status of file must change to "A_File [Current] (...)" where "..." means your user name. Its editor tab must not indicate the file as (read-only).

Modify the file

1. Insert brand-new line somewhere into the file.
2. Delete some other line but not directly next to the new line.
3. Modify another line but not directly next to the lines mentioned above and Save the file.

RESULT: The file must change to "A_File [Locally Modified] (...)".

View differences

1. Switch to "Files" tab of explorer.
2. Invoke VSS | Diff on "A_File [Locally Modified] (...)" node.

RESULT: All three differences must be highlighted in a special window with both versions of the file. New line is green, removed line is red and modified one is blue.

Checkin the file

1. Invoke VSS | Check In on "A_File [Locally Modified] (...)" node.
2. Setup "Three lines have changed." as "Change Description" and push "OK" button.

RESULT: The file must become read-only and "A_File [Current]" again.

Inspect the file

1. Invoke VSS | History on "A_File [Current]" node.
2. Check that correct comment messages of both versions are printed in "Standard Output" tab.
3. Invoke VSS | Properties on "A_File [Current]" node.

RESULT: Output window must contain brief information about the file. Make sure that given information is correct.

Get a missing file

1. Switch to "Versioning" tab of explorer.
2. Invoke VSS | Get Latest Version on "A_File [Current]" node.
3. Check "Make the Local Copy Writable" checkbox and push "OK" button.
4. Delete the "A_File [Current]" node.
5. Repeat step 2 on "A_File.java [Missing]" node once it occurs and just push "OK"

RESULT: Make sure the file was checked out and recognized. It must have "A_File [Current]" status and become read-only again.

Give up a lock on file

1. Invoke VSS | Check Out on "A_File [Current]" node.
2. Invoke VSS | Undo Check Out on "A_File [Current] (...)" node.

RESULT: Make sure the file has "A_File [Current]" status and became read-only again.

Teardown:

Test suite 5: Additional commands

Purpose: This suite tests less often used commands and less typical workflows of VSS user.
Setup: No preparation required.

# Test case Description

Remove a file from repository

1. Invoke VSS | Remove on "D_File [Current]" node.
2. Confirm the dialog informing user about successful removal of the file.

RESULT: The file must change to "D_File [Local]".

Put back a file to repository

1. Invoke VSS | Recover on "D_File [Local]" node.
2. Confirm the dialog informing user about successful recovery of the file.

RESULT: The file must change to "D_File [Current]".

Local refreshing

1. Externally delete D_File.java file.
2. Within 15 seconds invoke VSS | Refresh on "D_File [Current]" node.
3. The file must immediately change to "D_File.java [Missing]".
4. Invoke VSS | Get Latest Version on "D_File.java [Missing]" node.
5. Push "OK" button and repeat step 1.
6. Within 15 seconds invoke VSS | Refresh on "test [Current]" node.

RESULT: The file must immediately change to "D_File.java [Missing]"

Recursive checkout

1. Invoke VSS | Check Out on src [Current] node.
2. Uncheck "Check Out Recursively" and push "OK" button.
3. Close the "Retrieving" dialog and output window once it's done.
4. The "D_File.java" node must stay [Missing].
5. Repeat step 1 and push "OK" button directly.

RESULT: Once "Retrieving..." dialog has finished its work, the node must immediately change to "D_File [Current] (...)". Also B_File and Formular nodes must be [Current] (...).

Recursive refreshing

1. Externally delete D_File.java file.
2. Within 15 seconds invoke VSS | Refresh Recursively on "src [Current]" node.

RESULT: Once "Retrieving..." dialog has finished its work, the file must immediately change to "D_File.java [Missing] (...)".

Recursive get latest version

1. Switch to "Files" tab of explorer.
2. Invoke VSS | Get Latest Version on Test node.
3. Uncheck "Get Latest Version Recursively" and push "OK" button.
4. Close the "Retrieving" dialog and output window once it's done.
5. The "D_File.java" node must stay [Missing] (...).
6. Repeat step 1 and push "OK" button directly.

RESULT: Once "Retrieving..." dialog has finished its work, the node must immediately change to "D_File [Current] (...)" and become read-only.

Recursive undo checkout

1. Invoke VSS | Undo Check Out on Test node.
2. Push "OK" and close the "Retrieving" dialog and output window once it's done.
3. The "D_File.java" node must stay [Current] (...).
4. Repeat step 1, check "Undo checkout recursively" and push "OK" button.

RESULT: Once "Retrieving..." dialog has finished its work, all nodes must have only [Current] status.

Recursive checkin

1. Invoke VSS | Check Out on Test node and push "OK".
2. Invoke VSS | Check In on Test node.
3. Uncheck "Check In Recursively" and push "OK" button.
4. Close the "Retrieving" dialog and output window once it's done.
5. The "D_File.java" node must stay [Current] (...).
6. Repeat step 2 and push "OK" button directly.

RESULT: Once "Retrieving..." dialog has finished its work, all nodes must have only [Current] status.

Recursive inspection

1. Invoke VSS | History on test [Current] node.
2. Verify that output window contains history of all actions done in that folder like removal or recovery of D_File.java.
3. Invoke VSS | Properties on another [Current] node.
4. Test all commands that can invoked on package in Projects view on new created package.

RESULT: Verify that "Standard Output" tab contains information concerning another directory like number of files and its subprojects.

Set password

1. Create new command "Test" with execution string cmd /x /c "echo ${PASSWORD}" and turn on its "Display Output" property.
2. Invoke VSS | Set Password For $/ command on the filesystem.
3. Type in "abcd" and push "OK" button.
4. Invoke Test command on the filesystem.

RESULT: Verify that there is "abcd" printed in the "Standard Output" tab of output window.

Teardown:

Test suite 6: Additional features

Purpose: This suite tests other features like versioning explorer and VCS groups support.
Setup: No preparation required.

# Test case Description

View old revision

1. Invoke Show Versions on "A_File [Current]" node.
2. "A_File.java [Current]" node must be expanded in special window and contain two revisions with proper comments.
3. Invoke View on "1.0 Generated A_File class." node.

RESULT: The initial revision of A_File must get opened into editor.

Compare two revisions

1. Invoke Diff on "1.0 Generated A_File class." node.
2. Exactly the same window as in "4.3 View Differences" test case must get opened into editor.
3. Multiselect both revisions and invoke Diff on them again.

RESULT: The same window with highlighted differences must open again.

Add file to VCS group

1. Invoke Include in VCS Group | <Default Group> on "A_File.java [Current]" node.
2. Invoke Window | Versioning | VCS Groups from main menu.
3. Special window will show up. Expand "<Default Group>" node.

RESULT: There must be "A_File [Current]" node under that group.

Checkin from VCS group

1. Invoke VSS | Check Out on "A_File.java [Current]" node in "Versioning" window.
2. Switch to "Files" tab of explorer, open that file, modify it and Save it.
3. Setup "Description" property of "<Default Group>" node to "Checked in from VCS group.".
4. Invoke VSS | Check In on "<Default Group>" node.
5. Make sure that "Check In - A_File.java" dialog contains "Checked in from VCS group." comment and push "OK".

RESULT: A_File node must change to [Current] state and there must be "3.0 Checked in from VCS group." node under "A_File.java [Current]" node in "Versioning" window.

Verify VCS group

1. Invoke Verify on "<Default Group>" node.
2. Check "Remove Files From Group" on "Not Changed" tab and push "Correct Group" button.

RESULT: The "A_File [Current]" node must disappear from "<Default Group>" group.

Teardown:

Generated: 2005 02 07 10:49