A team of four, shipping a paid app and a free build, with a support inbox that fills up whenever a mid-range phone gets a firmware update.<\/p>\n\n\n\n
The device matrix is usually whatever could be bought over time: one flagship, four mid-range, two cheap, one phone a customer complained about, and one with a screen ratio the designer keeps forgetting exists.<\/p>\n\n\n\n
The flow is simple. Sign in, pick a plan, pay with a test account, restore a purchase. Six days, spread across two weeks, was the norm.<\/p>\n\n\n\n
Not six days of testing. Six days of fixing taps.<\/p>\n\n\n\n
Absolute coordinates broke on two devices with identical resolutions but different status bar heights. Percentages of screen width survived that and died on tall-screen models. dp worked until a phone shipped with a bumped system font size, wrapping every label to two lines and shifting the button down a row.<\/p>\n\n\n\n
Each round meant a full re-run of the matrix: edit eleven tap points, reinstall on nine devices, watch.<\/p>\n\n\n\n
The worse failure was the quiet one. A script tapped forty pixels left of “Continue”, hit the background, and the app never left the screen it was on. Every assertion after that measured the wrong page. One build shipped with a broken payment sheet because the report said pass. That is what a flaky test looks like from the inside, except the flakiness came from the device matrix rather than the assertions.<\/p>\n\n\n\n
The toolchain behind it rarely converged on one answer either. Appium with XPath locators, a uiautomator2 script for the screens Appium couldn’t reach, and two scrcpy windows side by side for the phones that had to be watched by eye. Three ways to name the same button, none of them portable to the next firmware build.<\/p>\n\n\n\n
Total Control exposes UI nodes to scripts. Queries take a resource ID, visible text, class name, content description, or a boolean property, and the device works out the coordinates:<\/p>\n\n\n\n
device.sendAai({query: “R:.pay_button&&BP:clickable”, action: “click”})
device.sendAai({query: “T:Total&&OX:1”, action: “getText”})<\/p>\n\n\n\n
Resource IDs are the stable option \u2014 they don’t shift with language, font scale, or panel density. Settings screens often lack them, so text plus an offset gets the value next to a label. That relationship holds on every device in the drawer, which is more than can be said for any hardcoded point.<\/p>\n\n\n\n
One gotcha: the template decides which nodes exist for the rest of the query. Narrow it to \/^[0-9]$\/ and then ask for the neighbour with OX:1, and it fails with “Node not found on offset” \u2014 the neighbour was never in scope. Use a wider template, or none, and it behaves.<\/p>\n\n\n\n
Assertions get simpler too:<\/p>\n\n\n\n
device.sendAai({action: “getText(+T:Order confirmed)”})<\/p>\n\n\n\n
Null means it wasn’t there. lastError() explains why.<\/p>\n\n\n\n
devices.sendAai({query: “T:Add to cart”, action: “click”})<\/p>\n\n\n\n
Results come back per device, so a failure names the device and the step. That’s roughly two hours of squinting at mirrored screens removed per pass.<\/p>\n\n\n\n
Object mode handles the exploratory case: perform the flow once on the master device, and the group follows the same nodes. No script needed for a sanity pass on a new firmware build.<\/p>\n\n\n\n
\u00b7 Portrait only.<\/strong> The tablet layout is landscape and still manual.<\/p>\n\n\n\n \u00b7 WebView content is often invisible.<\/strong> Moving checkout into a WebView made the nodes vanish. Same for custom-drawn UI. Mostly-native apps are fine; mostly-web wrappers should be checked in UI Explorer first.<\/p>\n\n\n\n \u00b7 Only one entry point at a time.<\/strong> Running a script, browsing nodes, driving the group by hand and calling the REST API can’t happen together. They queue.<\/p>\n\n\n\n \u00b7 Five second default timeout<\/strong>, except for sleep, openApp and scrollIntoView.<\/p>\n\n\n\n It’s also not a test framework: no case management, no reports, no retries. Results get collected separately through the REST API (Appium-shaped JSON, {“cmd”:”action”,”action”:”findnode”,”params”:{…}}, status:0 on success). For four people that’s acceptable. A QA department expecting a dashboard would find a hole.<\/p>\n\n\n\n Three devices, two releases a year: coordinates are fine. The cost of this only shows up once the matrix gets wide.<\/p>\n\n\n\n Weekly releases across a dozen configurations, with the same person re-mapping taps at 11pm: it pays back inside one cycle.<\/p>\n\n\n\n Start where the free edition stops: two devices, the flagship and the cheapest phone in the drawer, same script, no edits. If both come back clean, the other seven are a formality.<\/p>\n","protected":false},"excerpt":{"rendered":" A team of four, shipping a paid app and a free build, with a support inbox that fills up whenever a mid-range phone gets a firmware update. The device matrix is usually whatever could be bought over time: one flagship, four mid-range, two cheap, one phone a customer complained about, and one with a screen […]<\/p>\n","protected":false},"author":5,"featured_media":478,"template":"","sigma_tc_category":[],"class_list":["post-477","sigma_tc","type-sigma_tc","status-publish","has-post-thumbnail","hentry"],"yoast_head":"\nWhen it isn’t worth it<\/h1>\n\n\n\n