Test Script Template - Revision history

Bambers Linden: /* Goals to strive for when writing a test script */

2010-08-25T17:27:25Z

Goals to strive for when writing a test script

← Older revision		Revision as of 10:27, 25 August 2010
Line 2:		Line 2:
	[[Category:Test Scripts]]		[[Category:Test Scripts]]

	==Goals to strive for when writing a test ~~script~~==		==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 8:		Line 8:

	----		----


	== Scope ==		== Scope ==

Bambers Linden at 16:34, 25 August 2010

2010-08-25T16:34:49Z

← Older revision		Revision as of 09:34, 25 August 2010
Line 9:		Line 9:
	----		----

	~~==Test script contents==~~

	* ~~Requirements (ie. #~~ of ~~users,~~ a ~~god account, land, objects needed for~~ the ~~test)~~		== 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

	* ~~Est~~. ~~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.

	* ~~Variables~~ to test (ie. ~~different types of things that generate test permutations~~)		=== 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.)

	* Describe the ~~expected behavior and purpose~~ of the ~~new code. (or link to the Design Document~~)		== Test Steps ==
	* List any dependencies the new code may have -- what other systems may be affected?		=== Functional Tests ===
	* List any security implications -- does this feature give access to something it should not?		# '''Test case 1''' (you can briefly outline the goal of the test case here)
	* Detailed plan(s) for testing new functionality, including success and failure cases if possible.		## 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

	* Test ~~Setup~~		----
			=== Regression Tests ===
			(Optional) - as new failures are observed, new test cases can be added here to supplement the functional tests in the section above.
			# '''Test for bug VWR-xxxx'''
			## step 1
			## step 2
			## '''Verify''' against expected behavior

	* 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~~.		== Pass/Fail Criteria ==
			# Passes if
			## 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

	* Compare Performance, if applicable		== Tear Down ==
	** Requirements for gathering data on existing feature being modified.		* List what must be done to revert the tester's environment to a neutral state
	** 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.)~~

Dan Linden at 21:47, 26 January 2007

2007-01-26T21:47:19Z

← Older revision		Revision as of 14:47, 26 January 2007
Line 1:		Line 1:
			{{OSWikiLearnBox}}
			[[Category:Test Scripts]]

	==Goals to strive for when writing a test script==		==Goals to strive for when writing a test script==
	* Easy to understand and follow.		* Easy to understand and follow.

Dan Linden at 21:42, 26 January 2007

2007-01-26T21:42:49Z

← Older revision		Revision as of 14:42, 26 January 2007
Line 1:		Line 1:
	Goals to strive for when writing a test script		==Goals to strive for when writing a test script==
	* 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 6:
	----		----

			==Test script contents==

	* 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)

Dan Linden at 21:42, 26 January 2007

2007-01-26T21:42:09Z

← Older revision		Revision as of 14:42, 26 January 2007
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)

Dan Linden at 21:39, 26 January 2007

2007-01-26T21:39:06Z

New page

* 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.)