Difference between revisions of "Test Script Template"

From Second Life Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Goals to strive for when writing a test script==
{{OSWikiLearnBox}}
[[Category:Test Scripts]]
 
==Goals to strive for when writing a test plan==
* Easy to understand and follow.
* Easy to understand and follow.
* Short enough to be run in 30 minutes or less. If it's too long, break it down into smaller tests.
* Short enough to be run in 30 minutes or less. If it's too long, break it down into smaller tests.
Line 6: Line 9:
----
----


==Test script contents==
== Scope ==
* Describe the purpose of this test
* Link to a user story and / or an optional changeset url
* List any dependencies the new code may have -- what other systems may be affected?
* List any security implications -- does this feature give access to something it should not?
* Estimated running time


* Requirements (ie. # of users, a god account, land, objects needed for the test)
== Set-up ==
=== Environment ===
* If special set-up is needed, list test environment requirements such as viewer or server versions, operating systems, specific graphics cards and driver versions, etc.


* Est. Running time
=== Other ===
* List other requirements needed to execute the test plan here. e.g...
* Basic tester account to use as "User B" where specified
* Sandbox, or other area where building is allowed
* Describe/include tests to compare performance, if applicable:
** Requirements for gathering data on existing feature being modified.
** Follow this with requirements for gathering data on new feature in new format, etc.
** Explain how to compare data to ensure new feature is not worse (i.e. lower framerate, higher bandwidth, more db queries, etc.)


* Variables to test (ie. different types of things that generate test permutations)
== Test Steps ==
=== Functional Tests ===
# '''Test case 1''' (you can briefly outline the goal of the test case here)
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 2'''
## step 1
## step 2
## '''Verify''' against expected behavior
# '''Test case 3'''
## step 1
## step 2
## '''Verify''' against expected behavior


* Describe the expected behavior and purpose of the new code. (or link to the Design Document)
----
* List any dependencies the new code may have -- what other systems may be affected?
=== Regression Tests ===
* List any security implications -- does this feature give access to something it should not?
(Optional) - as new failures are observed, new test cases can be added here to supplement the functional tests in the section above.
* Detailed plan(s) for testing new functionality, including success and failure cases if possible.
# '''Test for bug VWR-xxxx'''
## step 1
## step 2
## '''Verify''' against expected behavior


* Test Setup


* Feature Rule to check
----
*# Step
*# Step


* Corner case to rule
== Pass/Fail Criteria ==
*# Step
# Passes if
*# Step
## e.g. No unexpected behaviors are observed
# Fails if
## e.g. Expected behaviors are broken
## e.g. A bug is detected that was not accounted for by this test plan


* Detailed plan(s) for testing dependent code, including success and failure cases if possible.
== Tear Down ==
 
* List what must be done to revert the tester's environment to a neutral state
* Compare Performance, if applicable
** Requirements for gathering data on existing feature being modified.
** Follow this with requirements for gathering data on new feature in new format, etc.
** Explain how to compare data to ensure new feature is not worse (i.e. lower framerate, higher bandwidth, more db queries, etc.)

Latest revision as of 10:27, 25 August 2010

Goals to strive for when writing a test plan

  • Easy to understand and follow.
  • Short enough to be run in 30 minutes or less. If it's too long, break it down into smaller tests.
  • Clear description of requirements needed to run the test. Number of users, parcels, etc.

Scope

  • Describe the purpose of this test
  • Link to a user story and / or an optional changeset url
  • List any dependencies the new code may have -- what other systems may be affected?
  • List any security implications -- does this feature give access to something it should not?
  • Estimated running time

Set-up

Environment

  • If special set-up is needed, list test environment requirements such as viewer or server versions, operating systems, specific graphics cards and driver versions, etc.

Other

  • List other requirements needed to execute the test plan here. e.g...
  • Basic tester account to use as "User B" where specified
  • Sandbox, or other area where building is allowed
  • Describe/include tests to compare performance, if applicable:
    • Requirements for gathering data on existing feature being modified.
    • Follow this with requirements for gathering data on new feature in new format, etc.
    • Explain how to compare data to ensure new feature is not worse (i.e. lower framerate, higher bandwidth, more db queries, etc.)

Test Steps

Functional Tests

  1. Test case 1 (you can briefly outline the goal of the test case here)
    1. step 1
    2. step 2
    3. Verify against expected behavior
  2. Test case 2
    1. step 1
    2. step 2
    3. Verify against expected behavior
  3. Test case 3
    1. step 1
    2. step 2
    3. Verify against expected behavior

Regression Tests

(Optional) - as new failures are observed, new test cases can be added here to supplement the functional tests in the section above.

  1. Test for bug VWR-xxxx
    1. step 1
    2. step 2
    3. Verify against expected behavior



Pass/Fail Criteria

  1. Passes if
    1. e.g. No unexpected behaviors are observed
  2. Fails if
    1. e.g. Expected behaviors are broken
    2. e.g. A bug is detected that was not accounted for by this test plan

Tear Down

  • List what must be done to revert the tester's environment to a neutral state