Test Case Form
Test Case Summary
Prob # & Name of Test
#
Test Environment URL
Developer Testing:
Unit Testing:
System Testing:
Release Testing:
Objective of Test
Configuration and/or
Setup
Required Permissions
Comments
Create Test Case
Step
#
Run Test Case
Action
Expected Results
Actual Results
(must include validation proof)
Pass/
Fail
Comments/Explanation
Important: Please use one form per problem. Insert more test step rows or add a complete new Test Case Summary/Test Steps
section if needed.
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
7/28/2017 | Page 2 of 7
Test Case Summary Instructions
General
1. This form, or the online equivalent (when completed), is required for all problems.
2. Use one form per problem. More test step rows, or a complete new Test Case Summary/Test Steps section, can be added if
needed.
3. Prior to beginning testing, each tester must confirm the previous tester’s actual results document that successful testing has
occurred.
4. For all problems, successful testing requires completing “validation steps” where “Actual Results” equal “Expected Results”.
5. If successful testing by the previous tester cannot be confirmed then the problem must be immediately assigned to the previous
tester (or developer) and set to the associated status.
6. Add additional steps or comments to clarify existing steps but do not change any steps or results entered by earlier testers.
7. Screen shots may need to be expanded to be viewed as the default paste option is to fit them within the table cell.
Prob # & Name of Test
Enter the problem number the form will be attached to and the name of the test. The name should be similar to the name of the
problem being tested and be understood when rolled into the overall test plan by the Test Plan Generator.
Objective of Test
This should be as detailed as possible so the scope of the code change and related test steps can be understood in relation to the
objective. This field will also be rolled into the overall test plan by the Test Plan Generator.
Test Environment URL
This should include the complete URL (including the file name) for each testing environment. Please add a new entry for each
different environment the test is run.
Configuration and/or
Setup
Any configurations (system, company, user, etc.) needed prior to or during the running of the test are described here. It is very
important to set tests up correctly so time is not wasted re-running them.
Required Permissions
Any permissions needed prior to or during the running of the test are described here. It is very important to set tests up correctly so
time is not wasted re-running them.
Comments
Information needed to ensure successful running of the test, including global assumptions, etc. are listed here.
Create/Run Test Case Instructions
Screen shots or attachments which are referenced in the test (i.e., help explain a series of test steps or confirm actual results).
Step #
To ease test creation, these can be entered in any order but should be sorted before the test is run.
Action
Enter the action that the tester takes to perform this test step. An action test step does not require validation when you run this
step. Only fail these steps if you are unable to perform the action. The amount of detail in each action should reflect the expected
experience of the testers running the tests.
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
7/28/2017 | Page 3 of 7
Create/Run Test Case Instructions
Actual Results
(must include validation
proof)
Pass/Fail
Comments/
Explanation
Validation Test Step
Expected Results
(Optional)
Enter the result the user should expect after the action has been performed.
IMPORTANT: If you add expected results to a test step, it automatically becomes a validation test step and will require proof
that actual results match expected results. When you run the test case, you must individually mark a validation test step as
either passed or failed.
(Required when “Expected Results” are present)
IMPORTANT: If expected results are present, this becomes a validation test step and requires proof that actual results match
expected results. Proof can be in the form of a screen shot, an actual E-Tag, TSR, Deal Ref., Schedule ID, ATC value, or
other similar data which shows the test was run.
(Required when “Expected Results” are present)
Values are:


Pass: Actual results confirm expected results.
Pass Conditional: Actual results confirm expected results with certain changes to the test step. Use the
“Comments/Explanation” field to clarify why the status was set to “Pass Conditional.”
 Fail: Actual results do not confirm expected results.
 Fail Conditional: Actual results do not confirm expected results but the test can continue. Use the
“Comments/Explanation” field to clarify why the status was set to “Pass Conditional.”
IMPORTANT: If you do not set a value on a validation test step the test will automatically be assigned a status of “Fail.”
(Optional)
Comments, questions, or concerns while creating or running a test step. Any conditional pass or fail should be explained here.
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
7/28/2017 | Page 4 of 7
EXAMPLE Test Case Summary
Prob # & Name of Test
130594
The password is not changed when entering an incorrect current password.
Test Environment URL
Developer Testing:
PatrickT-d/tes_beta/web40/misc/misc-changepassword.wml
Unit Testing:
PatrickT-d/tes_beta/web40/misc/misc-changepassword.wml
System Testing:
Release Testing:
Objective of Test
Verify the Change Password display works correctly when entering an incorrect current password.
Configuration and/or
Setup
1.
Required Permissions
1. Valid username and password
Comments
misc-changepassword.wml was modified to enforce OATI Password Standards and needs to be tested.
EXAMPLE Create Test Case
Step
#
Run Test Case
Action
1
Log into test system with valid
username and password.
2
Go to the Change Password
display.
3
Enter the incorrect password in
the Enter webTrans password
field.
4
Enter a new password in the Enter
New Password and Retype New
Password fields that meets the
configured password
requirements.
5
Click Enter.
Expected Results
Message “Old password is
incorrect” will be
displayed.
Actual Results
(must include validation proof)
Confirmed message is displayed.
Pass/
Fail
Pass
Comments/Explanation
See screenshot
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
6
Click OK and log out of the
system.
7
Log out and log back in to verify
the password was not changed.
7/28/2017 | Page 5 of 7
Should be able to login with
same username and
password used in step #1.
Confirmed valid password used in
step #1 still works.
Pass
Recommended Minimum Test Steps and Instructions
Boundary Check
Input Validation
Make sure all the fields that collect information from the user can gracefully handle any value that is entered. This includes no value
(null), space, max value, etc.
(If applicable) Make sure all fields that collect information from the user are validated. Client side validations can be bypassed so
“critical” validations should be done on the server.
Example:
Use #Try to make sure the required parameters exist.
Use RegexTest function to avoid special characters.
# RegexTest (InterfaceName, "^ [A-Za-z0-9] +$ ") #
Here the variable InterfaceName is of alphanumeric type.
#RegexTest(SSN,"/^\d{3}-\d{2}-\d{4}$/")#
Here the variable SSN is in the standard U.S. Social Security number format of: 078-05-1120.
#!RegexTest(Address,"/^(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|25[0-5])\.(\d|[01]?\d\d|2[0-4]\d|25[05])\.(\d|[01]?\d\d|2[0-4]\d|25[0-5])$/")#
Here the variable Address is an IP address in the format of 192.168.1.1.
Use IsNumeric to validate integers, decimals, and real numbers.
Syntax - #IsNumeric(expression)#
Where “expression” can be any number
Use IsDate to validate the Date field entry
Syntax - # IsDate (expression) #
Where “expression” can be any date
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
7/28/2017 | Page 6 of 7
Recommended Minimum Test Steps and Instructions
Variable Encoding
Variables must be encoded properly.
For example:
#URLEncodedFormat(x)# – put this over variables in a URL.
Example: src="abc.wml&id=#URLEncodedFormat(id)#"
#HTMLEditFormat(x)# – put this over variables displayed/printed out on the page.
Example: <table><tr><Td>Deal:#HTMLEditFormat(DealNumber)#</td></tr></table>
#HTMLJsEditFormat(x)# – put this over variables in Javascript functions inside html input tags.
Example: <input type="button" onclick="alert('#HTMLJsEditFormat(DealNumber)#');">
#JsEditFormat(x)# – put this over variables transferred to Javascript
Example: <script type="text/javascript" language="javascript">
var test = '#JsEditFormat(test)#';
Note: JsEditFormat is only used when a webPlus expression is being used. The JsEditFormat example above is only applicable when
outputting webPlus expressions as Javascript variables. In a Javascript (.JS) file, you cannot use any webPlus functionality at all, so
you shouldn’t use webPlus variables or JsEditFormat.
XMLEditFormat(x) – put this over variables inside of tags which produce xml output.
Example: <data>
<series>
#XMLEditFormat(seriesName)#
</series>
Note: ODG3 escapes most webPlus expressions appropriately so only use XMLEditFormat if you are explicitly providing an XML
fragment. Use HTMLEditFormat if you are providing HTML, etc.
Also, XSLT doesn’t have a function for escaping URL variables so in an XSLT template it needs to be done using the Javascript
“encodeURIComponent” function inside the “onclick” attribute.
Example:
<span class="link"
onclick="parent.openNewWindowObj({{url:'/&lt;webPrint&gt;#TES_SystemPath_web40#&lt;/webPrint&gt;/validation/tag/valid-tagdetail.wml&amp;amp;TagIndex={$tagindex}&amp;amp;ReqIndex={$reqindex}&amp;amp;TagID=' + encodeURIComponent(this.tagId),
winName: 'Discretion Update' ,forceNewWindow: true, foreign: false, noTitleBar: true}});">
<xsl:attribute name="tagId">
<xsl:value-of select="$tagid" />
</xsl:attribute>
<xsl:value-of select="$text"/>
</span>
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.
Open Access Technology International, Inc.
Test Case Form
7/28/2017 | Page 7 of 7
Recommended Minimum Test Steps and Instructions
Valid ASCII Character
Codes Only
Non-ASCII character codes (above 128) are not allowed in URL’s.
Examples of character codes not allowed:
Character Code
Symbol
161
¡ (Inverted exclamation)
162
¢ (Cent sign)
163
£ (Pound sterling)
164
¤ (General currency sign)
165
¥ (Yen sign)
166
¦ (Broken vertical bar)
167
§ (Section sign)
169
© (Copyright)
170
ª (Feminine ordinal)
Do Not Output Code
Comments to the
Browser
webPlus comments <!--- ---> must be used instead of HTML comments <!-- --> and/or JavaScript comments // and /* */so
comments are not output to the web page.
Example:
<script> <!---script comment--- >
<webif> <!--- if comment --- >
Performance Test
How long does the changed code take to run compared to the original code? Is the change in time acceptable? Will it be acceptable
in the production environment with production data and volume rates?
This document contains proprietary and confidential information of OATI, Inc. Do not copy or distribute without explicit permission of OATI, Inc.