Difference between revisions of "Development How To Test A Patch"
From VistApedia
| 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. | ||
Revision as of 19:24, 7 March 2005
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.
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.
