Difference between revisions of "Test Script Template"
Jump to navigation
Jump to search
Dan Linden (talk | contribs) |
Dan Linden (talk | contribs) |
||
Line 1: | Line 1: | ||
Goals to strive for when writing a test script | |||
* 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. | |||
---- | |||
* Requirements (ie. # of users, a god account, land, objects needed for the test) | * Requirements (ie. # of users, a god account, land, objects needed for the test) | ||
Revision as of 13:42, 26 January 2007
Goals to strive for when writing a test script
- 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.
- Requirements (ie. # of users, a god account, land, objects needed for the test)
- Est. Running time
- Variables to test (ie. different types of things that generate test permutations)
- 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?
- List any security implications -- does this feature give access to something it should not?
- Detailed plan(s) for testing new functionality, including success and failure cases if possible.
- Test Setup
- Feature Rule to check
- Step
- Step
- Corner case to rule
- Step
- Step
- Detailed plan(s) for testing dependent code, including success and failure cases if possible.
- 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.)