Skip to content

OIT Device Engineering needs Testers!

By: John Straffin

Early Adopters Test Group

With OIT Device Engineering expanding our efforts to provide uniform solutions to the university IT community, we need to expand out testing capabilities beyond our own computers and virtual machines. As we create and manage application installers, feature updates, settings changes, and OSD task sequences, we can only test them so far. Our internal testing environment cannot fully reflect the variety of Duke’s computing environment and our access and experience cannot reflect the access and experience of Duke’s users.

What we need is for individuals throughout Duke University to make their computers and their time available as part of the Early Adopters Test Group. These users will assist in testing the solutions offered by OIT DE to the Duke IT community for managing user endpoint devices to ensure that these solutions are effective and efficient. Individuals that are invited to participate should be both comfortable with technology and forgiving of the occasional tech hiccup, ideally having a good rapport with their IT Support Group. While solutions sent to computers used by these individuals will have already gone through at least two levels of prior testing, it would be foolish to assume that issues will never arise. We are looking for the users that can recognize those issues and report them, being willing to possibly participate in the issue’s resolution.

Again, these users will ideally represent a wide variety of computing needs and areas of responsibility; one or two people from each department, doing different tasks with different software and (if possible) different hardware. While we’ll be testing widespread solutions like Microsoft Office installs and upgrades or CrowdStrike Protection Policy changes, we’ll also occasionally need to make sure that a Perceptive Content upgrade works properly or that a Group Policy targeting an obscure setting operates as expected. With a large and diverse group, we hope that at least a portion of that group would receive and use the solution to be tested.

IT Alpha Test Group

In addition, all Duke University IT staff are encouraged to enroll at least one device as a participant in an IT Alpha Test Group. This group of computers will receive solutions to be tested before the Early Adopters Test Group, but after those solutions have gone through individual and departmental OIT DE testing. There are also solutions that will never make it to the Early Adopters Test Group as those solutions are intended for IT use only…OSD Task Sequences, for example. We need the help of every Duke IT staff person, if possible, to help us find as many issues with our solutions as possible before exposing them to Duke users.


Computers will be added to the test groups by putting a CrowdStrike Falcon Sensor Tag of either “CANARY” or “ALPHA” in place on their computer. This was chosen as the method as CrowdStrike is installed everywhere and the Sensor Tags are visible by other Endpoint Management systems to populate their own testing groups. One setting for all systems

More information on joining a device can be found at the Endpoints Wiki.


Participation in these groups should come as a surprise to nobody. Users should be actively invited to participate, with the risks explained beforehand.

Participants of both the Early Adopters and IT Alpha Test Groups will be expected to join and participate in the “Early Adopters Test Group” in Microsoft Teams. All announcements of upcoming tests will be made there, and all feedback and assistance will be expected there.

Also, in the Files section of the Team, there are sample messages that departments can use to invite and inform users of what they’d need to do as a group participant.

Test Plans

Unlike typical IT QA testing efforts, there will be no “test plans” for anyone to follow. Participants will simply use the solutions and/or affected software as they would in the ordinary day-to-day activities of their job.

Any issues that may arise during testing, if they cannot be quickly remediated in place, will result in the rolling back of the solution, to include the possible uninstallation and reinstallation of the affected software.


There are regular times of month and year that updates occur (“Patch Tuesday”, Windows and macOS updates in October/November each year) and any updates during those times will be announced in the Team well in advance. There are also, however, regular times of month and year that critical university tasks occur (end of budget year, end of semester grading) and, with appropriate forewarning, we will not push any changes to be tested during those times.


Q: What exactly are we testing?
A: Everything! If OIT DE develops and supports it, it should be tested before pushing it to production: monthly patches, application installs/upgrades, settings changes, etc.

Q: Is there a minimum level of hardware or software to participate?
A: No! If the configuration exists in Duke’s computing environment, it should participate in testing.

Q: Is there a maximum level of Duke administration that should participate?
A: Maybe! While all users are welcome, it may make sense to avoid higher-level faculty and staff to avoid more significant impacts of issues that may arise.

Q: Do we need to let OIT DE know that we’ve added a user?
A: No. Simply add the appropriate Sensor Tag to the computer and have the user join the Team.

Q: How many participants do you need?
A: Anyone we can get to participate will be helpful. That said, there should be no more than one or two from any department so that any serious issues do not bring down an entire group.