Development How To Test A Patch - Revision history

152.131.9.69 at 19:29, 7 March 2005

2005-03-07T19:29:10Z

← Older revision		Revision as of 19:29, 7 March 2005
Line 11:		Line 11:
	### It helps to reference any [[NOIS]] tickets filed.		### It helps to reference any [[NOIS]] tickets filed.
	### If a NOIS ticket hasn't been filed, remember to outline the gist of the problems to help the next patch installer.		### If a NOIS ticket hasn't been filed, remember to outline the gist of the problems to help the next patch installer.
			## Do you have any suggestions to increase the ease of installing the patch?
			## If the patch introduces new functionality, does the documentation adequately describe how to use the new functionality?

	You must have a way of determining if the Patch worked. One criteria is that the patch can be considered successfully tested when the site has verified that the problem detailed in the patch description has been corrected and that no other functionality has been affected.		You must have a way of determining if the Patch worked. One criteria is that the patch can be considered successfully tested when the site has verified that the problem detailed in the patch description has been corrected and that no other functionality has been affected.

152.131.9.69 at 19:24, 7 March 2005

2005-03-07T19:24:30Z

← Older revision		Revision as of 19:24, 7 March 2005
Line 4:		Line 4:

	# Decide to first Test in a [[Safe Environment]], and only then to test in a [[Production Environment]].		# Decide to first Test in a [[Safe Environment]], and only then to test in a [[Production Environment]].

	# Take notes about what occurs as you install the patch, and then the impact the patch has on the system and existing processes, including workflow.		# Take notes about what occurs as you install the patch, and then the impact the patch has on the system and existing processes, including workflow.

	# Give feedback to the patch developers, after you have finished testing the patch. Answers to the following suggested questions have helped developers in the past:		# Give feedback to the patch developers, after you have finished testing the patch. Answers to the following suggested questions have helped developers in the past:
	## Did you have problems following the installation instructions?		## Did you have problems following the installation instructions?
Line 13:		Line 11:
	### It helps to reference any [[NOIS]] tickets filed.		### It helps to reference any [[NOIS]] tickets filed.
	### If a NOIS ticket hasn't been filed, remember to outline the gist of the problems to help the next patch installer.		### If a NOIS ticket hasn't been filed, remember to outline the gist of the problems to help the next patch installer.

			You must have a way of determining if the Patch worked. One criteria is that the patch can be considered successfully tested when the site has verified that the problem detailed in the patch description has been corrected and that no other functionality has been affected.

152.131.9.69 at 18:59, 7 March 2005

2005-03-07T18:59:10Z

New page

== Guidelines on How to Test A Patch ==

If you choose to test a patch, there are some simple guidelines that will increase the impact of your testing.

# Decide to first Test in a [[Safe Environment]], and only then to test in a [[Production Environment]].

# Take notes about what occurs as you install the patch, and then the impact the patch has on the system and existing processes, including workflow.

# Give feedback to the patch developers, after you have finished testing the patch. Answers to the following suggested questions have helped developers in the past:
## Did you have problems following the installation instructions?
## Do you have any reservation regarding approving this patch for release?
## Have you experienced any adverse affects because of this patch?
### It helps to reference any [[NOIS]] tickets filed.
### If a NOIS ticket hasn't been filed, remember to outline the gist of the problems to help the next patch installer.