QA Testing for Haptic Feedback

Haptic feedback is the quiet polish layer that makes hits land and menus feel responsive, and it is also one of the least tested systems in most games. The hardware ranges from a crude rotational motor in a budget phone to the precise linear actuator in a flagship or controller, and the same vibration call produces wildly different sensations on each. Worse, haptics have a uniquely bad failure mode: a motor that gets stuck buzzing forever because a stop call was missed. This post covers how to QA haptics deliberately, from pattern design across device variance to the accessibility setting that lets players turn it off, to catching stuck rumble before it ships.

Understand why haptics differ by device

A vibration request is not a precise instruction the way a sound sample is. Older phones and basic controllers use an eccentric rotating mass motor that spins up and down slowly, so short, sharp patterns blur into a single mushy buzz. Newer devices use linear resonant actuators that can produce crisp taps and varied intensities. A pattern of three quick pulses that reads as a satisfying triple-tap on a flagship may register as one long indistinct rumble on cheaper hardware, which means your carefully designed feedback communicates nothing.

Because of this, you cannot tune haptics on one device and assume they translate. Test every pattern on a spread of hardware: a budget phone, a flagship, and any controllers you support. Note where a pattern loses its meaning or becomes unpleasant, and design patterns that survive the lowest common denominator rather than relying on actuator precision only premium devices have. The goal is feedback that reads correctly across the range, not a showcase that only works on the developer's own phone.

Test intensity, timing, and overlap

Haptic events have intensity and duration, and getting either wrong turns helpful feedback into annoyance. Test that a light tap for a menu selection is clearly distinct from a heavy thud for taking damage, on each device, since the motors compress that range differently. Patterns that overlap in time are a frequent source of bugs: if a player takes damage while a previous rumble is still playing, the events may stack into an unpleasant continuous buzz or cancel each other unpredictably depending on how your queue is built.

Rapid-fire events expose the worst behavior. In a busy combat scene, dozens of haptic triggers can fire per second, and a naive implementation either floods the motor into a constant drone or drops events inconsistently. Test the most chaotic moments your game produces and confirm the haptics still communicate rather than melting into noise. Decide deliberately how overlapping events combine, whether the newest wins, intensities sum, or there is a minimum gap, and verify that policy holds under load instead of leaving it to chance.

Hunt for stuck rumble

The defining haptic bug is vibration that never stops. It happens when a continuous rumble is started but the stop call is missed because the player paused, backgrounded the app, died, or hit a code path that skipped cleanup. The result is a phone that buzzes forever until the player force-quits, which is the kind of experience that earns a one-star review instantly. Test every interruption during an active rumble: pause the game, take a call, background the app, trigger a scene transition, and confirm the motor goes silent.

Defensive design beats hoping you covered every path. A good pattern is to cap continuous haptics with a maximum duration so even a missed stop call self-terminates, and to explicitly silence all haptics on pause, focus loss, and scene unload. Test these guards by deliberately killing the stop path and confirming the safety timeout still cuts the buzz. Treat any report of a phone vibrating after the game lost focus as a high-severity bug, because it affects the device beyond your game and players will not forgive it.

Respect the player's choice to turn it off

Haptics are not universally wanted. Some players find them distracting, some have devices where vibration drains battery noticeably, and some need them off for accessibility or simply for playing quietly. A vibration toggle in settings is mandatory, and the bug to test for is the setting that does not fully take effect. Verify that with haptics disabled, not a single event fires anywhere in the game, including the menus, loading screens, and edge-case events that are easy to forget when you wire up the global flag.

Test the toggle while haptics are actively playing, because a player may reach for the setting precisely because the buzzing is bothering them. Disabling it should cut the current rumble immediately, not wait for the next event. Consider intensity levels rather than a single on or off switch, and if you offer them, test each level on multiple devices since the perceived difference between levels varies by motor. A respected setting is part of basic polish, and a setting that leaks events is a trust problem.

Setting it up with Bugnet

Stuck-rumble and weak-haptic reports are almost useless without device context, because the same code produces different feel on every motor. Bugnet's in-game report button captures the device model and game state when a player flags a haptic problem, so a complaint about endless buzzing arrives tagged with the exact phone and build rather than a frustrated note. You can add a custom field recording the last haptic event that fired, which often points straight at the code path that forgot to stop the motor.

Because a stuck-rumble bug tends to hit many players on the same device or in the same game moment, Bugnet's occurrence grouping folds those reports into one issue with a count. A spike in that count right after a release is a clear signal you regressed the haptic cleanup path. Filtering by device model lets you confirm whether weak feedback is a tuning issue on cheap motors or a real bug, so you spend your time on the reports that represent a genuine defect rather than expected hardware variance.

Bake haptics into your test routine

Haptics get skipped in QA because they are invisible in screenshots and silent in automated tests, so they need a deliberate manual pass. Build a checklist covering each pattern on each device class, the overlap behavior under load, the interruption tests for stuck rumble, and the settings toggle. Hand it to a tester with the actual hardware in their hands, because there is no substitute for feeling the feedback; a log line saying vibrate was called tells you nothing about whether it felt right.

Re-run the haptic pass whenever you add patterns, change the queueing logic, or support new hardware, and add real player reports as new test cases, especially stuck-rumble reports from devices you do not own. Good haptics are a small thing that players rarely praise but instantly notice when broken. Treating them as a tested system rather than a fire-and-forget effect is what separates a polished game from one that occasionally buzzes a player's pocket into the next room.

Haptics differ on every motor and can buzz forever if a stop call is missed. Test across devices, guard the stop path, and honor the off switch.