Managing Shared Test Devices for Mobile QA Teams

Every mobile team has a device shelf. It starts as a drawer with four phones. Two years later it's thirty devices, three of which are missing, five of which are flat, and one of which is "the iPhone with the old iOS that we must never update" that someone updated last Tuesday.

Shared test devices are a coordination problem with a physical twist. Unlike a staging environment, a phone can leave the building, run out of battery, or quietly get an OS update. This guide covers how to run a device shelf that QA, developers and support can all rely on, and when it's worth moving some of the work to remote or cloud devices.

What goes wrong with a shared device shelf

The failure modes are consistent across teams:

• Nobody knows where a device is. It's on someone's desk, in a bag, or at home.
• The device you need is busy, but you can't tell. You walk over, find it gone, and start asking around.
• The OS version drifted. A device kept on an older version for compatibility testing got updated.
• It's flat. Devices in drawers discharge, and some older ones don't recover well from being left empty.
• It's not provisioned. The build won't install because the device isn't registered or the profile expired.

Most of these come down to two missing things: a reliable inventory, and a reliable record of who has each device right now.

Step 1: Build an inventory you'll actually keep

Start with a simple table. A spreadsheet is fine for inventory, because it changes rarely. What it's bad at is tracking who has a device right now, which changes several times a day (we get into why in why the environment booking spreadsheet fails).

Field	Example
Name	ios-iphone13-ios17
Platform and model	iPhone 13
OS version and policy	iOS 17, pinned (do not update)
Identifier	Serial number or UDID
Asset tag	QA-014
Location	Shelf B, slot 4
Provisioned for	Debug builds, TestFlight
Notes	Cracked corner, works fine

The two fields teams skip and later regret are OS policy and location.

Step 2: Name devices for what testers search by

Testers don't look for "the blue Pixel". They look for "an Android 13 device" or "the smallest iPhone screen we have". Put that in the name:

android-pixel7-a14
android-galaxya14-a13
ios-iphonese3-ios16
ios-iphone15pro-ios18
ios-ipad10-ipados17

Pattern: platform-model-os. Print the name on a label on the device and on its charging slot, so a device can always be returned to the right place.

Step 3: Decide an OS version policy

Every device should be in one of two states:

• Pinned: kept on a specific OS version for compatibility testing. Automatic updates off. Label it clearly.
• Current: updated to the latest release, for testing what most users have.

Decide how many pinned devices you need per platform based on the minimum OS versions your app supports. Put the policy in the device description so whoever picks it up knows not to accept an update prompt.

Step 4: Handle registration and provisioning up front

On iOS, devices used for development builds need registering in your Apple Developer account. Apple's documentation (2026) allows up to 100 devices per product family (iPhone, iPad, Apple Watch and so on) per membership year. Disabling a device during the year doesn't give the slot back; you can only remove devices and restore the count at the start of a new membership year.

For a shared device lab, that means:

• Register lab devices deliberately, not every phone anyone ever plugged in.
• Keep the UDID in your inventory so you know which registered devices are lab devices.
• Review the list at renewal and remove devices you've retired.

On Android, the equivalent housekeeping is keeping developer options and USB debugging enabled, and noting which devices are signed in to test accounts.

Step 5: Keep them charged and in one place

Unexciting, but it's what makes a device lab usable. A powered USB hub or charging station with a labelled slot per device means:

• Devices are charged when someone picks one up.
• An empty slot means "someone has it", which is visible from across the room.
• Returning a device has an obvious destination.

Step 6: Make checkout one action, from where people already are

The inventory tells you what exists. Checkout tells you who has it right now. That record needs to be:

• Quick to update, or people won't bother when grabbing a phone for five minutes.
• Visible remotely, so a developer working from home can see whether the Android 12 device is free before asking someone in the office to test.
• Time-boxed, so a device someone took home doesn't show as "in use" forever.
• Able to notify, so the next person knows when it's back.

This is the part teams usually run on a sheet of paper taped to the shelf, and it's the part that fails first.

Device checkout in chat with Lockit

Lockit is a chat bot for reserving shared resources, and test devices are a natural fit. Create one resource per device with @Lockit new, using the device name from step 2 and a description with OS policy and shelf location. Optionally pick a channel, such as #device-lab, for lock and release updates.

Picking up a device:

@Lockit lock android-pixel7-a14

Returning it:

@Lockit release android-pixel7-a14

@Lockit list shows every device with its current holder, so anyone can see what's free without walking over. When a device is taken, there's an "Alert when released" button that pings you when it's back, and an "Ask for takeover" button that sends the holder a request with Approve / Reject Request buttons, which is the polite way to ask "can I have the iPhone SE for ten minutes?".

Set a per-resource default duration that matches typical use, for example 4 hours, and lower the workspace default from its 48-hour fallback so nothing taken home silently stays "in use" for two days. People can choose a longer duration when they lock.

On Discord: /lockit lock resource:ios-iphonese3-ios16 duration:2 hours. On Teams: @Lockit lock ios-iphonese3-ios16 2 hours.

The free plan covers 2 resources, which is enough to try it with a couple of devices. A real device shelf needs Starter, which covers up to 100 resources. See pricing.

When remote or cloud devices make sense

A physical shelf has limits: it only helps people in the office, and every new model costs money. Two options are worth knowing about.

Self-hosted remote access

DeviceFarmer STF (Smartphone Test Farm) is an open-source web app for using devices remotely from a browser: live screen, touch and keyboard input, app installs, shell and logs. Its README (2026) lists Android support from 2.3.3 up to Android 15, with iOS support marked experimental. It also has a booking system for reserving a set of devices for a set of users for a limited time. The project describes development as active but largely volunteer-funded, so expect to maintain it yourself.

Cloud device farms

Cloud device farms rent you real devices by the minute or by slot. As one example, AWS Device Farm's pricing page (2026) lists $0.17 per device minute pay-as-you-go, a one-time free trial of 1,000 device minutes, and unmetered device slots from $250 per month each. Several other vendors offer similar services with their own pricing.

How to split the work

Work	Best fit
Automated test runs across many models	Cloud device farm
Exploratory testing on a specific device	Physical shelf or remote access
Reproducing a customer bug on their exact model	Whichever has the model
Testing hardware features (camera, NFC, Bluetooth pairing)	Physical device
Remote team members needing an occasional device	Remote access or cloud

Most teams end up with a smaller physical shelf for hands-on testing and a cloud or remote option for breadth.

A device lab policy you can copy

1. Every device has a name (platform-model-os), a label, and a charging slot.
2. Check a device out in chat before you take it; release it when it's back in its slot.
3. Default checkout is 4 hours. Taking a device home overnight? Lock it for longer so the record is accurate.
4. Pinned devices are never updated. If you see an update prompt on one, decline it.
5. Found a device in the wrong place or flat? Put it back, charge it, and mention it in #device-lab.
6. Device lost or broken? Tell the lab owner so it's removed from the inventory and, for iOS, considered at the next registration review.

For other shared hardware such as dev boards or test rigs, see hardware lab booking. For QA teams that also juggle shared environments, QA environment scheduling covers that side.

FAQ

How many test devices does a mobile QA team need?

Enough to cover your supported OS range and the screen sizes your users actually have. Start from your analytics: the most common models and OS versions, plus the oldest OS you support. Fill gaps with remote or cloud devices rather than buying every model.

How do we stop pinned devices from being updated?

Turn off automatic updates, label the device clearly, and put "pinned, do not update" in its checkout description so the person taking it sees it every time.

Should we use a cloud device farm instead of physical devices?

For automated runs across many models, a cloud farm is usually cheaper than buying the devices. For hands-on exploratory testing and hardware features, physical devices are still easier. Most teams use both.

What's the simplest way to know who has a device?

A checkout record that's quicker to update than not. A chat command that takes one line, with a duration that expires on its own, beats a paper sheet because it's visible to remote teammates and doesn't go stale.