Patch Test Group

What are my fellow ninjas doing to make sure they have good testing for patches. It makes sense to use a sampling of production machines. How do you go about choosing which machines and how many to add to your testing group.

4 Comments   [ + ] Show comments
  • My philosophy is to start small and work my way up...meaning, I'll start with 1 test machine and once I feel that is good, then I test with 3-5 production machines. The size of your environment should correlate how big of a test group you get to.

    With this sort of testing, I use a manual label and apply it to the specific machines I am using. - jfrank 7 years ago
  • Right now I have about 8 machines, covering all my models, with users that are higher-level than most and more likely to use the products being patched. - rockhead44 7 years ago
  • Use a small group (10 systems). make sure you have 2 tasks. One to detect and one to deploy. Run them a few hours apart. Make sure you are allowing for reboots as well. If a system needs to reboot it may not show a successful patch as deployed till it does. - Ty 7 years ago
  • When learning to use the K1, I had about 65 virtual servers in remote locations I wanted to start patching. After creating a patch policy with the updates I needed, I tested on a server in my office with a like configuration. Once working okay on the test rig I gave it a go on a few live servers over the course of a week. Once comfortable I setup a patching schedule that does around 10-15 servers per night Sun-Thurs (so support will be available the next morning if something fails). - k1000-chan 7 years ago

Answers (2)

Posted by: SMal.tmcc 7 years ago
Red Belt
if you have multiple orgs enabled you can create one for testing
Posted by: MacDude 7 years ago
Fifth Degree Brown Belt
With regard to picking out the individual machines used for testing, it is going to be one or more manual labels. 

You want a cross section of your environment and you want to use users who will give you feedback. 

Cross section: 
  • Representing different Operating Systems (OS X 10.8, OS X 10.9, Win 7, Win 7x64, etc.)
  • Representing different Job Functions (Engineering, Finance, Shipping, Instructors, Labs, etc.)
  • IT folks are not very good test subjects; they tend to fix problems rather than reporting them and they don't use the same tools as some of your end users. 
  • Instead find your 'whiney' users; the ones who call you anytime something isn't right with their world. 
Communication is key. Give the users a path to report when something isn't right. Let them know when you will be patching and let them know that they are in the 'advance' group who get 'upgrades' early. 

It is possible to have several Labels (e.g. Server Patch Testing, Instructor Patch Testing, etc.)

Test them against a few machine before you roll the patch to a lot of machines. It's much easier to clean up the mess that way. 

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ