The setup utility will build a program group
off of your Start button called 'Test Case Manager'. Within this group there
will be a shortcut to start Test Case Manager and another shortcut to this
help file. Setup will also build an uninstall applet accessible through the
Control Panel’s Add/Remove Programs applet.
RUNNING APPLICATION
To run the application, use
the short cut created by the setup utility. This shortcut points to the "TCM_Loader.mdb"
file. This loader application will automatically repair and compact the "TCM_App.mdb"
file every time before loading it. You should run the loader otherwise over
time your "TCM_App.mdb" file will slowly grow larger and larger.
GETTING STARTED
INITIAL RUN SETUP
When you first run TCM, a message
box will pop-up indicating that "The default TCM database server and/or
path does not exist." The following dialog box will pop-up prompting
you to either create a new project database, open an existing project database,
or quit. If it is the first time you have run TCM, go ahead and click 'New
Project' to build a new Project database. If your project lead has already
created the project database, then click the 'Open Existing Project' button
and browse to the path they have provided to you. It is always best to use
a URL to the data source rather than a mapped drive.
Figure 1 – Initial
Run of TCM
Next, a Wizard will popup prompting you to
enter new project information. Step 1 prompts for the name of the new project.
Step 2 prompts for the location (path) of the new project. Using this information,
the wizard will create a new TCM project database when you click Finish.
See the TCM Administration section below
for a further discussion of creating additional new projects.
The wizard looks like this:
Figure 2 – New
Project Wizard
LOGGING
ON
Every time that TCM is run, it will prompt the user
to enter a logon and password. Initially your password is set to an empty
string. See the TCM Administration
section below for further details on how to change this password, add users,
and add new logon passwords.
The logon dialog looks like this:
Figure 3 – Logon
Form
NAVIGATING
THE MAIN FORM
If the logon is successful, the main form will be displayed:
Figure
4 – Main Test Case Explorer Form
Notice that there is a menu bar, a toolbar,
and two sub-windows titled "TEST AREA EXPLORER" and "TEST CASES."
The menu items all correspond to the toolbar
buttons whose functions are listed below.
Note that there is also a 'Filters' tab behind the 'Spec Areas' tab (tree).
The filters tab gives you lots of flexibility for defining the set of test
case records you want to see in the right-hand pane. You can click to depress
the All Records button to force every test case to be displayed. You can filter
by specific Level, Person Assigned, or Execution Status by picking a single
option from the corresponding drop down box. Finally, you can pick a User-Defined
Filter of that you create. These are the very same filters used for reporting.
They are extremely flexible, and allow you to make complex filters.
Figure
5 – Main Test Case Explorer Form
ENTERING TEST CASES
TEST CASE EXPLORER FORM
Notice that there is one toolbar
at the top of the screen. Below that there are two sub-window panes. The pane
on the left contains two tabs, one a tree of test areas, the other a set of
various filters by which to constrain the test cases in the right pane. The
pane on the right contains individual test case details in a table view. Highlighting
different tree branches on the left or choosing different filters will automatically
load in the corresponding test cases on the right pane (just like Windows
Explorer).
The toolbar buttons have the following functionality (left to right):
• New Project: This button will popup
the New Project Wizard so that you can provide a name and a network location
(shared to all testers) on which you will save the empty TCM project database.
• Open Project: This button will popup
the Open Project dialog box, allowing you to pick a new TCM_Data.mdb (project
database) to view/edit.
• Add Area: This button will popup
a dialog box prompting you to enter a new Test Spec Area (tree item) and corresponding
index number (e.g.: 01.02).
• Add Test Case: This button will
popup a dialog box prompting you to enter a new test case depending on which
sub-window currently has the focus.
• Edit: This button will popup a dialog
box enabling you to edit the Test Spec Area name and index number or
the test case depending on which sub-window currently has the focus. Note
that changing the index number will automatically change the "TC_Area_Number"
for every tree branch linked below the current branch, as well as the link
in every test case below.
• Delete: This button will delete
the highlighted tree branch, and all of its sub-branches, and
all of the test cases assigned to any branch therein. However, if the right
pane (test cases) has the focus box around it, then the currently selected
test case(s) are deleted. Use this command carefully!
• Copy: This button will copy either
a Test Spec Area, or test case(s) depending on which sub-window last had the
focus. If the left pane, then you will be prompted to enter a new Test Spec
Area into which to copy the currently highlighted tree branch. A new branch
will be created, and all sub-branches and test cases from the originally highlighted
branch will be copied over.
• Move: This button will move either
a Test Spec Area, or selected test case(s) depending on which sub-window last
had the focus. If the left pane, then you will be prompted to enter a new
Test Spec Area name or number to move the currently highlighted tree branch.
All sub-branches and test cases from the originally highlighted branch will
be moved over.
• Assign Test Cases: This button will
display a dialog requesting the name of a tester to assign all test cases
for the area selected in the TEST AREA EXPLORER pane. You may optionally choose
to propagate the assignment to all sub area below the selected testing area.
• Pass Test Cases: This button will
display a dialog requesting test result information and update the following
fields (Pass/Fail, Tested Date, Tester, Version, Build Number, Comments &
Environments Tested) on the highlighted test cases (right sub-window). Every
test case has a test execution status that is one of three states: a) Untested(Null),
b) Pass(-1), or c) Fail(0).
• Fail Test Cases: This button is
similar to the Pass button above, except that it marks all highlighted test
cases as Failed.
• Archive Records Wizard: This button
invokes a wizard dialog used to archive off all test results. You can
use this from build to build, or after every major milestone (alpha release,
beta release, etc.).
The test case results are saved into a table named ‘TC_LogExecution_Archive’.
Then the results are cleared away from the ‘TC_TestCase’ table.
• Archive Test Case Results: This
button first saves off only the selected test case results to a table named
‘TC_LogExecution_Archive’. Then the results are cleared away from the ‘TC_TestCase’
table. This button is used when you want to clear out the test results for
a specific test cases. The only test cases archived are those that are selected
in the 'Test Cases' table. You may apply a filter to display all test cases
within certain branches of the 'Test Area Explorer'. Archiving is usually
done before a new round of testing on a new build/version or milestone of
the application under test.
• Report Wizard: This button invokes
a wizard dialog used to print many powerful reports from TCM lists to project
status reports.
• Close Form: This button will close
the Test Case Explorer form.
Note that the following menu items do
not have a corresponding toolbar button:
• Exit: The File menu contains this
option which will exit the application.
• Usage Log: This displays a usage
report detailing the frequency of use of TCM by its users.
• Contents: This Help menu item will
popup the very help file you are reading.
• About TCM: This Help menu item will
popup the about screen indicating author’s website, email, licensing agreement,
etc.
TEST
CASE DETAIL FORM
Clicking the Add or Edit Test Case buttons from the
Test Case Explorer form will display the Test Case Detail form with the specified
test case loaded as shown below:
Figure 10 – Test Case Detail Form View
The toolbar at the top of the form contains several buttons with the following
functionality (from left to right):
• Attach File: This button will popup
a dialog allowing you to upload, download, view or delete file attachments
to the test case. Examples of attachments include XL spreadsheets (test matrices),
Word Documents, HTML output (e.g.: expected results for web application),
etc. You can attach as many files as you want, provided you have sufficient
hard drive space.
• Print Test Case: This button will
print out the current test case using the ‘Test Case Details - Two Column'
report.
• Send to Notepad: Several users requested
a way to copy the test case information into their respective bug tracking
systems. This button was deemed the easiest way, rather than trying to create
exports to every know bug tracking system. Also note, TCM is written in Access;
and you can easily build your own queries to move the data from TCM to the
bug tracking system for bulk operations. This button is for copying out single
test cases.
• Pass Test Case: This button will
display a dialog requesting test result information and update the following
fields (Pass/Fail, Tested Date, Tester, Version, Build Number, Comments &
Environments Tested) on the current test case. Every test case has a test
execution status that is one of three states: a) untested(Null), b) pass(-1),
or c) fail(0).
• Fail Test Case: This button is similar
to the Pass Test Case button above except that it marks the test case as failed.
• Helpful Hints: This button will
popup a message box indicating how you can use several built-in MS-Access
commands via right click popup menu on a given cell. Functionality available
includes sorting ascending or descending, filter by value, etc.
• Undo Changes: This button allows
you to cancel all the changes that you have made to the Current Test Case
and return you to the Test Case Explorer form.
• Close Form: This button will close
the Test Case Detail form, saving any changes that were made to the test case
and return you to the Test Case Explorer form.
Below the toolbar buttons, all of the
TCM/Issue fields and buttons are displayed:
• TC_ID: This identification number
is automatically generated to uniquely identify individual test cases. The
ID is sequentially incremented. If a test case is added then deleted, that
TC_ID is forever gone; thus, gaps can occur in the numbering sequence (note
that you can immediately compact the TCM_Data.mdb after deleting a new test
case to reclaim the sequencing).
• TC Area: This is an important field
that identifies to which area of the tree a test case belongs. The value is
defaulted to the current location at the time the user clicked the "Add
Test Case" button from the "Test Case Manager" form. Even though
this field is grayed out, you can alter its contents to move a test case from
one area to another within the TCM Breakdown Tree.
• Bug_ID: This is a field for you
to cross-link your bug tracking system with TCM. As a general testing rule,
every bug should have a test case built around it; preferably the test case
is created and leads to discovering the bug; however sometimes it works in
reverse.
• Last Test Result: This non-editable
field should indicate the latest pass/fail/untested status for the current
test case.
• Attachments: This non-editable drop
down list displays any attachments that have been assigned to the current
test case.
• Name: The field should be a brief
description of the test case’s purpose. Be sure that this title is descriptive
enough to stand on its own in summary windows; but not too verbose (6-10 words).
• Test Case Details: This is the heart
and soul of a test case. It is very important that the standard be followed
when writing up this section of a test case (because it will be copy and pasted
into the bug tracking system). Below is a listing of the standard test case
details format:
• Level: This field indicates the
type of test case: High Level Acceptance, Regression, Automated, New Feature.
• Priority: This field indicates the
priority of the test case: High(1), Medium(2), Low(3).
• Status: This field indicates whether
the test case is still active, is inactive, or replaced by a newer test case.
• Date Created: This field indicates
the date and time on which the test case was first created.
• Estimated Test Time: This field
records the estimated amount of time it takes a tester to perform the test
case.
• Last Revision: This field is a non-editable
field that records the date of the last revision to the current test case.
• Est. Test Time:
This field indicates the approximate amount of time it will take to perform
this test case. It is important to have this field filled in if you plan to
obtain useful metrics on how much time a test cycle will take or how much
time is left to finish testing, etc. This field may be revised when the time
estimate becomes more accurate.
• Assigned To: This
field indicates the user to whom is assigned the task of performing the test
case.
• Pass/Fail: This
field indicates whether the last test
case execution was a Pass or a Fail.
• Recommend for Automation:
This check box is provided to flag a test case as a viable candidate for test
automation. The 'Project Summary by Counts' report will indicate how many
test cases in each area have been checked. The 'Project Summary by Automate
Recommendation' report may then be run to view specifically
which test cases were recommended for test automation.
• Tested Date: This field indicates
the date and time on which the test case execution occurred and the results
were last logged.
• Tester: This field indicates the
tester who last executed and logged results for the test case.
• Version: This field indicates the
version of the application under test for which the test case results were
last logged.
• Build Number: This
field indicates the build number of the application under test for which the
test case results were last logged.
• Comments: This field indicates any
comments regarding the test case execution that the tester wants to note.
• Environments Tested:
This field indicates under which environments the test has been tested so
far.
Within the body of this form, the sharp reader
would have noticed several buttons. The buttons perform the following functions:
This button will popup a dialog box containing all possible values for the
drop down box to the left. By clicking this button, you can easily change
the options available in each drop down box.
This button will display a calendar control that allows you to select a Tested
Date automatically in the correct format.
Data Preservation
DATA BACKUP
A regular backup of the database and attachment files
is required to preserve data and be able to recover from a catastrophic failure
that corrupts or deletes the database. If someone accidentally deletes part
or all of the data, the backup will be needed to recover to the last saved
state. TCM does not have a backup system built into it, but there are many
ways of accomplishing the backup task, it is only important that a good method
is chosen and performed diligently. Esker has chosen to use TaskZip, a freeware
product by Pierce Business Systems. A full backup of the database will be
done weekly while incremental backups will be done every hour during regular
working hours.
RECORD LOCKING
Since Test Case Manager is a multi-user system, it is important
to implement a strategy of record locking that prevents two or more users
from editing the same data at the same time. We have chosen to use pessimistic
record locking which locks all records on a form as soon as the user opens
the Test Case Details form. Other system users will still be able to view
the test case details for that record, but will not be able to edit that record.
As a visual cue that someone else has a record open and locked a circle with
a line across it will be displayed on the record selector button when it is
selected on the 'TEST CASES' view of the Test Case Explorer form.
MANAGING
TEST CASES
ORGANIZING
TEST CASES
One of the most important parts
of developing a TCM database is to plan the layout (breakdown) of the various
areas. The primary goal of the layout is to provide a structure that will
be immediately obvious to a tester familiar with the product. It is suggested
that you use the Test Specification you built on paper (as Word or XL document,
etc.) to define your TCM Area Breakdown (hence the name Test Specification
Areas).
For a more detailed description of suggested
test cases for each of the default areas, please click this link to the Generic Test Spec.
TEST CASE WRITING GUIDELINES:
Do’s When Writing Test Cases:
• DO Have one "Verify"
statement per test case (at the objective line).
• DO Write each case to be executed standalone.
It shouldn't’t depend on other test cases.
• DO Break down the app and write steps to
the functionality. This eliminates constant rework of the test cases when
code changes.
• DO think reusable scripts when writing
your test cases.
Do Not’s When
Writing Test Cases:
• DO NOT use the words "correctly",
"as it should", "properly" or other value statements.
Define the expected behavior.
• DO NOT use test files or other attachments
unless clearly helpful. If so, try to have the creation of the test file be
part of the test case. Also, TCM gives you the option to save the file as
an Attachment to the test case—use it with care so as not to bloat the file
server (test data, etc. are valid uses).
• DO NOT give setup or Testing Steps unless
they are necessary. If the test case should start off at a well known form,
then just list that one step in the setup steps (start at form X). You do
not need to list all the steps to get to that form too, unless it is an obscure
dialog and it would help new testers.
ASSIGNING
TEST CASES
It is possible to assign individual
test cases or entire areas of test cases to testers. To assign an individual
test case, open up the test case for editing. There is an 'Assigned To' field
with a drop down list of persons that you may assign the responsibility of
testing. Optionally, you may select an entire area from the TEST AREA EXPLORER
section and click the 'Assign Test Cases' button. A dialog will display, giving
a check box option to propagate the assignment to all sub areas below the
selected area. After assignments have been made, it is possible to filter
on only those test cases that are assigned to a specific user.
SETTING TEST CASE LEVEL
When the tester first fills out a test case, it is crucial
to assign the appropriate Level. Test case Level is a breakdown for priority
of execution of the test cases. It is very important to properly breakdown
the test cases so that you can organize your testing approach. If you are
approaching the alpha milestone, a test manager can set a target of testing
all smoke tests, critical path tests. Any failure in those two levels of test
case can result in a rejection of the alpha build. Final release builds can
apply the same criteria but also include the acceptance criteria test cases
too. Having the test cases broken down this way will give you more meaningful
summary reports too.
1. High Level Acceptance
2. Regression
3. Automated
4. New Feature
TEST CASE
EXECUTION APPROACHES
Once you have built your test
case Area Breakdown, then begun populating test cases, you will inevitably
begin executing those test cases. When you execute test cases, you assign
them with a Pass or Fail, date and time when execution occurred, version and
build number, and any comments you may want to make. These test execution
results enable you to assess what amount of the application has been tested,
remains yet to be tested, passed or failed, etc.
There are many different approaches that
different testing organizations can take. Below, are a few of the major strategies.
Test-After-You-Build Approach
Where there are sufficient
planning documents, specs, lists, prototypes, etc., testers can do a detailed
write-up of most of the test cases before ever executing any of them. This
approach is a great way to determine plan test execution by understanding
resource usage, organize who tests what, coordinating coverage to eliminate
redundancy and cover all equivalence classes, etc. A department’s more experienced
tester(s) can build test cases for a project, then hand portions or all of
them off to more junior testers for execution. This is the ideal approach
when proper resources are available, enough time is allotted, etc.
Test-As-You-Build Approach
Often in today’s software development world, the ideal conditions
above do not exist (unless you are fortunate enough to work in a larger, more
formal development shop). Under these conditions, often the best you can do
is write test cases as you execute them. Weaknesses of this method include
missing coverage of certain areas, overlap with other testers, etc. You can
partially mitigate these weaknesses by at least doing a thorough job of building
your Test Spec Tree (Areas), and then assigning resources to different branches
of the tree. This method is still far better than the two methods below because
you will have test cases to reuse in the future, and you can still use results
as you go to organize and track your testing efforts. Just be sure to come
back and continue to clean the test cases and tree as your understanding of
the application under test grows.
Test-Before-You-Build Approach
You should avoid this when possible, but sometimes you are given a
new build of a small applet with minor changes and expected to have just those
changes tested. It could be argued that if the changes are that small than
it should be easy to do the Test-As-You-Build approach above…but maybe there
are compelling arguments why you "need" to test before writing or
planning test cases. Fine, do it if you really need to…but BE SURE to return
and write up those test cases for future re-testing. Don’t neglect to make
time to come back after test execution and write up the test cases you did.
Adhoc Approach
Always avoid this approach, it is unprofessional and the mark of a novice
tester. If you really have good reasons for not organizing and writing test
cases (new and not enough time for learning TCM, etc.) then at least write-up
minimal acceptance criteria, or test outlines, or use test matrices for coverage
coordination, or test scripts that walk through the critical pathways of an
application. But whatever course of action you choose, please do NOT just
adhoc test without writing anything down. A tester without testware (planning
and tracking documentation such as test cases) is a chicken running around
with its head cutoff. Resist the temptation. Adhoc testing can be a wonderful
form of testing that often yields some of the best bugs…but it should be done
AFTER the basics are covered with an organized test approach.
CONSTRUCTION
& EXECUTION TIPS
• If you do not have time to fully build all test case
details, you can get by with using all the defaults and filling out a full
title. You can then execute test cases rapidly from Test Case Explorer form
(tree form using titles). Where details are required, then drop in and fill
out the reproduction steps and other details. Use this as a way to get started
if you are in a hurry but want to catch up later with finalizing test case
entry.
• Avoid assigning test cases to parent tree
branches in the Test Specification Areas. Instead, breakdown the parent branch
into sub-branches and assign test cases to the lowest level tree branches
only.
• As a general rule, try to assign no more
than 30 test cases per branch of the tree. If you get more than 30, attempt
to rethink better ways of breaking down your tree. Also note that you cannot
add more than 99 test cases per tree branch.
• Be sure to always fill out the Test Specification
Areas in as much detail as possible from the start. This will benefit you
by: saving time later, omitting building test cases for certain areas if need
be, easily distribute test cases among testers, etc.
• Test case titles should be started out
with the word ‘Verify’, such as ‘Verify tab order on form X’.
• Test case titles should be detailed enough
to stand on their own (given the context of the Test Specification Area in
which they are located), but not overly detailed. A good rule of thumb is
4-10 words in length.
• Do not be afraid to move test cases and
rearrange the Test Specification as your knowledge of the project grows. It
is inevitable that you see better ways to organize your test breakdown as
you test the system.
• You can speed up testing by printing out
a summary sheet (test case titles only), then test from the printout, writing
the results on the report. Once testing a section is completed, go to the
Test Case Explorer form and highlight ranges of test cases, marking them as
Pass, Fail, or Untested accordingly. If you require more detail, print out
a Test Case Details Report. If you have two computers, you can walk through
test cases in TCM on one, and test the app on the other.
• You can handle multiple operating systems
in many different ways:
(1) Make an entire tree branch in the test spec tree, then copy all of those
sub-branches and test cases to a new branch for a new operating system.
(2) Populate the User-Defined drop-down boxes with all the operating systems
you wish to test. Then build and copy test cases, assigning the appropriate
operating systems.
(3) Add the Operating System name to the title of test cases.
(4) Use the Environment Tested
field
CHANGING TCM PROJECT DATABASE
There are two approaches for handling multiple
projects in a TCM tracking system. One method is to add a project name column
so that every test case belongs to a specific project. The second method is
to have multiple TCM databases, one for each project. TCM employs the second
method for the following reasons:
• Separate TCM databases translate to fewer
users per database which in turn reduces database contention where multiple
users lock records, prevent writes, and generally stomp over one another.
• Separate TCM databases allow for more flexibility
in how each project database is implemented (what values to populate combo
boxes with, what user-defined fields to use, etc.).
• Separate TCM databases result in fewer
records which translate to faster queries, reports, and overall performance.
Changing a TCM project database is very easy.
Click the "Change Project" button on the main screen toolbar to
popup the dialog box below. Fill in a new database path, or use the "…"
browse button to popup an open file dialog box. When you have entered or selected
a new database path, click the "Ok" button to re-point the tables
in the TCM_App.mdb to the new project TCM_Data.mdb.
Figure 11 – Change
Project Database
TCM
REPORTING
Reporting is an important features of TCM.
Receiving instant feedback at the click of a button for project summaries,
summary test case lists, etc. will enable a project team to better gauge the
status of a project under test.
REPORT TYPES
There are several report types to choose
from. Below are several of the most popular report types:
Figure 12 – TCM Project
Summary By Count Report
Figure 13 – Test Case Detailed Report
Figure 14 – Test Case
Summary Report
There are currently nine report types to
choose from. The report types are:
(1) Project Summary by Counts Sheet:
is a very useful report for summarizing the status of a project. It breaks
down test cases by Pass, Fail, and Untested counts. This breakdown is rolled
up as an overview, then further broken down by Level and by Primary Test Specification
Areas. This summary report also indicates the number of test cases flagged
for test automation.
(2) Project Summary By All Areas:
is used to print out a highly compact list of test case titles without the
details. Use this to handout lists of failed/untested test cases at meetings,
as milestone summary sheets (through Acceptance Criteria level for example).
(3) Project Summary By Areas In Use:
is identical to the report above, except that only areas with test cases assigned
are displayed.
(4) Project Summary by Automate Recommendation:
is a useful report for eyeballing which test cases have been identified by
the testers for test automation.
(5)
Test Case List, Detailed By Area: is used to print out detailed test
case lists with several details and descriptions. Use these lists to review
test cases in a meeting, or to fix test cases and mark them as resolved, etc.
(6) Test Case Details - One Column:
is a print out with enough details for testers to execute test cases from
the paper copies, and enough room to log the results.
(7) Test Case Details - Two Column:
is a print out with enough details for testers to execute test cases from
the paper copies, and enough room to log the results.
(8) Complete Test Results: provides
a summary of all test results with a pass/fail result in either the Active
testing table or the Archive table. Use the filtering capabilities to
narrow the results based on version or build number, etc.
(9) Most Recent Test Results by Date:
provides a summary of only the most recent test results with a pass/fail result
in either the Active testing table or the Archive table.
REPORT
WIZARD
Clicking the Report Wizard
button on the main form will popup the Report Wizard. This wizard consists
of three steps: 1) choosing a report type, 2) selecting (or building) a filter,
and 3) selecting an output type.
Step 1: requires you to simply select a report type from the list-box. You can
double-click the item, or highlight it and click the next button.
Step 2: (pictured below) requires you to select a filter (or none) by which to
constrain your data. Filters limit the data in a report to just those records
that match your criteria. For example, you can build a filter to list only
the untested test cases for a particular version (those still requiring action).
Filters give you tremendous flexibility in your reporting.
Step 3: requires you to select an output type. You can send the output directly
to a printer, print preview it on screen, or email the report.
Figure 15 – Report
Wizard, Step 2 of 3
FILTER DIALOG
Currently filters are saved locally, so you are the only one
that has access to them. Several sample filters have been created for you
to use either in their present state, or you may modify them for your specific
needs.
When building a report to run via the Report Wizard (see previous section), Step 2 has a build filter button that will trigger
the Filter Dialog show below. Click the "Add" button to add a new
filter. Click the "Del" button to delete an existing filter. Click
the "Test SQL" button to test whether the entries you made will
generate a valid SQL filter. If you are interested in seeing the underlying
SQL statement used for the filter, click the "View SQL" button.
The first step in creating a new filter is
to click the Add button. The next step is to enter a unique filter name that
identifies the filter you are going to create. This filter name will be displayed
in the drop-down list-box of Step 2 in the Report Wizard. Finally, you can
build the filter criteria (rows) in the grid at the lower half of the Filter
Dialog window as follows:
1)
Pick a test case field name from the drop down box
2) Pick an operator (equal to, less than,
etc.) for the field
3) Pick a value for the field (only currently
existing values are included in the drop down list, type in any value you
want that is not already displayed)
4) If there are going to be additional criteria
rows, select a boolean operator (And or Or) to concatenate the next row to
the current row (see screen shot below for a sample).
5) If you need to create more complex criteria,
you can use the various parenthesis fields () to enter one or more parenthesis
to set the order in which the various clauses (rows) are interpreted.
6) Be sure to click the Test SQL button as
you build your filter to ensure it works properly…if you wait until you click
Ok or move to another record, the button will be clicked automatically for
you, and it is harder to determine where an error occurs if you save the test
for one last big bang at the end when forced to run it.
Figure 16 – Filter
Dialog
TCM ADMINISTRATION
If you have administrative logon permissions,
the Edit menu, the New Project button, the Assign To button, and the
Archive Wizard button will be enabled so that you can perform administrative
tasks for your project database
EDIT
PERSON LIST
This feature enables an admin user to add new users, to add or edit passwords,
to change email addresses, and to set other users up as administrative users
too.
When you click the "Edit Person List" button, here is the dialog
box that appears in which you make entries:
Figure 17 – Edit
Person List
EDIT
VERSION LIST
This feature enables an admin user to add new versions to the contents of
the TCM Detail form’s Version drop down box.
When you click on the "Edit Version"
button, here is the dialog box that pops up:
Figure 18 – Edit
Version List
NEW PROJECT
WIZARD
This wizard enables an admin user to quickly setup a new TCM project database.
TCM handles projects not as a field or area inside of a single database, but
rather as separate databases for every project. Thus, if your company has
three major products, then you would setup three separate TCM project databases,
one for each product. Likewise, if one of your products has multiple versions,
you can either use the Archive Records Wizard below to keep all test cases
consolidated into a single TCM database, or you could create new and separate
TCM project databases for each version—the choice is yours.
You previously saw a screenshot of this wizard in the Getting Started, Initial
Run Setup section above. There
are two steps to carry out as described in that section.
ARCHIVE
RECORDS WIZARD
This wizard enables an admin user to easily archive test case execution results
in preparation for subsequent rounds of testing. For example, at the end of
a major milestones (alpha test complete, beta test complete) it is a good
idea to archive off all of your test cases. By following this simple process,
you have setup your TCM database for the next project cycle that is beginning.
Now all test cases are marked untested, and you can begin re-testing and marking
pass or fails.
Here is what the Archive Records Wizard looks
like:
Figure 19 – Archive
Records Wizard, Select Archive Task
VIEW USAGE
LOG
Select Usage Log Report from the View menu
to display usage statistics. This nifty features shows the admin user the
frequency with which all other users are logging onto and using the current
TCM project database. Here is what the report looks like:
Figure 20 – Usage Roll
Log
PROGRAMMER NOTES
TCM_PROJECT
DATABASES
• Location: The TCM_Data.mdb
project files can exist on any machine (NT, UNIX, with or without Access 97,
etc. – just be sure that every project has its own directory—or let the wizard
setup everything for you.
• Default: There is a default TCM_Data.mdb
file that is read-only and is always located with the TCM_App.mdb and TCM_Loader.mdb.
This file is used as a master copy from which duplicate TCM project databases
are made. It is left read-only so that users never use the "Change Project
Database" feature to switch to and use this database.
TABLES
• LIB_DefaultText: This table contains two templates that are used
to default text fields in the database: The table also is used as a working
area (sort of like global variables) to record the report filter name, and
filter criteria.
• LIB_EventLog: This table records
all unhandled errors that drop through to the error handlers in every function.
The Event log is available from the Help > About TCM dialog.
• LIB_Filter & LIB_Filter_Detail:
These are the parent and children tables that define a filter and its criteria
(fields, etc.).
• LIB_Filter_Field_List: This table
contains a list of all fields in the TCM table that can be used in the creation
of filters (used to populate Filter Dialog field drop-down). The table also
contains information on the field types. Note that the field Complex is not
used by TCM (used by my other apps with joins and tablename prefixes).
• LIB_Usage_Log: This table is a log
that records every time a user logs onto a TCM project database.
• REF_xxxx: Tables having a REF prefix
are reference tables. They all exist in the TCM project database and are used
to populate combo boxes on various forms, especially the TCM entry forms.
Changing the data in these tables will enable you to easily reconfigure the
options your company uses for various TCM definition fields.
• REF_Properties: This table is where
all of the project specific properties are stored. The Properties Wizard stores
all of its information in this table.
• REF_Properties_Local: This table
stays with the application and stores all of the current user’s preferences
such as what TCM project database to point at, Internet Explore (or Netscape
path)
• REF_Reports: This table contains
the name and description of every report type TCM offers. This table is the
basis of the Report Wizard Step 1 report listbox.
• TC_Area: This table contains the
Test Specification Areas that become the tree branches in the Test Case Explorer
window. This table also contains 20 small integer fields that are assigned
to each TCM user uniquely. These fields act like a stack to push and pop visibility
depending on whether user has collapsed or expanded the branches and their
parents.
• TC_Attachment: This table contains
names of all attachments stored for individual test cases. Testers occasionally
attach screen shots, XL files, Word documents, etc. to test cases and the
data for the file is stored here.
• TC_LogExecutionArchive: This table
contains old historical test case execution records. They are basically the
20% of each test case record that deals with execution results. Those fields
are stripped off and archived in this table where they accumulate.
• TC_TestCase: This table is the most
important table and houses all of the test case data.
Queries
• mqry_TCMList: This querydef is rebuilt
every time a report is run. Its contents vary with every report run and depends
on the report type.
• mqry_AutomateCount: This query definition
is used for the report, Current-Project Summary by Automate Recommendation.
• mqry_MostRecentArchiveResults: query
definition is used to retrieve only the most recent results by date from the
union of the archive and current tables.
• mqry_Union: This query definition
is used for the reports designed to retrieve data from the union of the archive
table or the current table.
LICENSE
TCM END USER LICENSE AGREEMENT
Use of TCM (hereinafter 'SOFTWARE') is contingent
on your agreement to the following terms:
1. GRANT
OF LICENSE
Pierce Business Systems (hereinafter
PBSys) grants you a license to use the SOFTWARE free of charge
If you are using the SOFTWARE free of charge
under the terms of this Agreement, you are not entitled to any support whatsoever;
however, you can try and email us. If we’re not too busy, we are always happy
to respond.
2.
DISCLAIMER OF WARRANTY
THE SOFTWARE IS PROVIDED AS
IS WITHOUT WARRANTY OF ANY KIND. TO THE MAXIMUM EXTENT PERMITTED
BY APPLICABLE LAW, PBSYS FURTHER DISCLAIMS ALL WARRANTIES, INCLUDING WITHOUT
LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE
OF THE PRODUCT AND DOCUMENTATION REMAINS WITH RECIPIENT. TO THE MAXIMUM EXTENT
PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL PBSYS BE LIABLE FOR ANY CONSEQUENTIAL,
INCIDENTAL, DIRECT, INDIRECT, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHATSOEVER
(INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS
INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING
OUT OF THIS AGREEMENT OR THE USE OF OR INABILITY TO USE THE PRODUCT, EVEN
IF PBSYS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
3.
SCOPE OF GRANT
For that software which includes
the source code, this paragraph applies: you may modify the source code for
yourself, your organization, or others. However, you are not permitted to
sell the modified software without express written consent. The intent of
this clause is to permit you to make any modifications you or others need
to use the software; but to also preclude unethical people from slightly altering
the code and then re-distributing the application as their own. If you want
to pick up the code base, add to it, and post it…go ahead so long as you leave
reference to the original development by PBSys; and a link to the PBSys website.
4.
COPYRIGHT
This SOFTWARE is protected
by copyright laws and international copyright treaties, as well as other intellectual
property laws and treaties.
5.
MAINTENANCE
PBSys is not obligated to provide
maintenance or updates for the SOFTWARE. However, any maintenance or updates
provided by PBSys shall be covered by this Agreement.
6.
DISTRIBUTION
The SOFTWARE may be freely
distributed provided that reference to PBSys and its website remain as is,
and provided that no fee is charged (except for any reasonable fees necessary
to cover costs of distribution media).
DISCLAIMER OF WARRANTY
THIS SOFTWARE AND THE ACCOMPANYING FILES ARE PROVIDED "AS IS" AND
WITHOUT WARRANTIES OF ANY KIND WHETHER EXPRESSED OR IMPLIED.
In no event shall the author be held liable
for any damages whatsoever, including without limitation, damages for loss
of business profits, business interruption, loss of business information,
or any other loss arising from the use or inability to use the software.
