After Four Questions the Quote Changed from Guesswork to Calculation
A group message says the app ships next week and crashes on low-end phones. The numbers that actually go into a quote don't exist until after three rounds of follow-up.
You open your saved message list. One notification comes from a Telegram group you authorized. Next to the sender’s profile picture it reads “Sun – Wanxiang Interactive.”
(The following is a composite scenario used to illustrate a reasoning method. It does not represent a real conversation.)
Sun – Wanxiang Interactive in “East China Testing & QA Exchange Group”: “We have a social app going live next week. Users are reporting that it crashes on low-end Android devices as soon as it opens. Looking for a lab to help test it. DM me if you have availability.”
You open the chat. The other side asks: how much?
You pull up your quote draft. The cursor blinks on the line labeled “Total.” You realize that before you write a number, you need to know what range of work that number covers. So you flip over a blank booking form — not starting with “Client Name,” but with the first question.
Start with the Device Boundary, Not the Price
You ask Sun for the specific models. He sends three: Redmi 9A, OPPO A16s, Samsung Galaxy A03 Core.
You write them into the device list. Then you ask one more thing: “Did these come from user reports, or did your developers reproduce the crash on these exact handsets?”
This question is worth the extra step. If users reported them, the crash logs may contain other models nobody has compiled yet. If the developers own these devices and verified the crash, the problem is locked to these three. The range of devices you need to cover could differ by a factor of two between the two scenarios.
He replies: “Users reported them. We verified on these three and can reproduce it.”
You follow up: “Have other users mentioned it without saying which phone they use?” Sun says a few people in the group mentioned something, but the information has not been collected yet.
Below the device list you add a note: Recommend preparing backup devices in the same SoC tier as the Redmi 9A (MediaTek Helio G25 class) in case coverage needs to expand.
The starting point of your quote is not the three phones you have. It is the question mark of whether a fourth one exists.
The OS Version Line: One Detail That Changes Everything
OS version. Sun says Android 11. You are about to fill it in, but the Redmi 9A in the device list makes you pause.
This phone shipped from the factory with Android 11 Go Edition — Google’s lightweight OS customized for devices with 2GB of RAM. Go Edition manages memory differently from standard Android 11: it reclaims background processes more aggressively and limits the heap memory available to foreground apps. An app that runs fine all day on standard Android 11 can crash on Go Edition the moment it opens. That is not unusual.
If a tester runs the app on a Redmi 9A flashed with standard Android 11 for two days, writes “Android 11 compatibility: normal” in the report, and the app still crashes on users’ Go Edition devices after launch — who owns that gap?
You ask Sun: “Does your Redmi 9A run the standard version or Go Edition?”
“I am not sure. Let me check with the developer.”
You write on the OS version line: Pending confirmation of the Android 11 variant for each model — whether the Redmi 9A is Go Edition. Then you cross out the number you had been mentally calculating. Until this is confirmed, any price you quote contains an unknown adaptation cost. It is not deep engineering — ask the other side to take a screenshot from “About phone.” Three seconds and you will know.
“Crashes When It Opens” Maps to Three Completely Different Workloads
The problem Sun described: “crashes when it opens.”
But “opens” in actual testing means three different things, and each has a different quoting logic:
- Scenario A: Tap the icon, the splash screen loads halfway, then exits. A tester can confirm this on one device in five minutes. Quote it as standard compatibility testing — priced per device.
- Scenario B: Enter a phone number, request a verification code, fill in profile details, tap register — it crashes on the fourth step. The tester needs a test account set up in advance and must walk through the full flow. Effort doubles.
- Scenario C: Swipe through the feed ten times. It crashes only on the third and seventh swipe. The reproduction rate is around 20 percent, requiring repeated runs to identify the trigger conditions. Quoted by person-day for issue localization, the price can be two to three times what you would charge per device.
You ask Sun for the crash logs. He says the developer has them and will contact you directly.
(The above is a reasonable extension of the simulated scene. Actual communication results may vary.)
Once you get the logs, you do not need to read every line of the error code yourself. Pass them to a technical colleague at the lab. They can tell in a glance whether it is a memory overflow, a null pointer, or a resource-loading failure. Each root cause requires a different reproduction environment and device setup. Until you know which scenario this is, the word “crash” alone cannot determine the effort.
“Next Week” Breaks Into Two Completely Different Quotes
Release date. What Sun said: “going live next week.”
On the “Target Launch Date” line you draw two dashes and write two possibilities:
- If it is Monday of next week: four working days left. Device preparation, OS flashing, app packaging, test execution, and report delivery all have to fit into 48 hours. For this kind of rush, the industry practice is generally a 30 to 50 percent premium over the standard rate.
- If it is Friday of next week: nine working days left. Standard process, normal pricing, and no scheduling conflicts.
(The dates above are simulated numbers used only to illustrate the reasoning method.)
The launch date also determines the nature of the test. You ask one more question: Is this the “final round of overall validation before launch,” or a “targeted investigation of a known issue”? The first requires a conclusive assessment of overall compatibility, with risk levels and a go/no-go recommendation in the report. The second only needs to answer “under what conditions does it reproduce.” The depth of the deliverables differs, and the quote gap is over 30 percent.
Sun replies: “Let us first see if we can reproduce it.”
You confirm the test type is targeted issue localization, not full compatibility testing. The rough direction of the quote is set.
After three rounds of follow-up, the booking form looks like this:
Client Name │ Wanxiang Interactive
Source │ Telegram group — East China Testing & QA Exchange Group
Device List │ Redmi 9A / OPPO A16s / Galaxy A03 Core (complete list TBD)
OS Version │ Android 11 variant per model pending (Go Edition to be ruled out)
Reproduction Scene │ Crashes on open; exact trigger steps pending crash log review
Test Type │ Targeted issue localization (not full compatibility)
Target Launch Date │ "Next week," exact date TBD
Quote Amount │ ________
Schedule Window │ ________
Status │ Following upThe quote amount and schedule window are still blank. But they are not blank because you do not know what to write. They are blank because you now know exactly what is missing.
You did not give a single fixed price. You sent something like this:
“Based on the information so far: targeted issue localization across three models on standard Android 11 — base estimate is $X,XXX. If the Redmi 9A turns out to be Go Edition, compatibility verification would add $YYY. Once you confirm the launch date, I can tell you whether a rush fee applies based on the remaining working days. Does this direction work for you?”
This is not a final price. It is a conditional quotation that lets the other side confirm the scope. Each blank row has become an optional add-on instead of a risk buried in a lump sum. They know what they selected and what they are paying extra for. You do not have to quote a number that is wrong in both directions because the information is incomplete.
Chasing Answers Is a Standard Step in Quoting, Not an Extra
Go back to that first group message. Eight seconds to read it. One sentence that says “need to test it.” If you had quoted without those rounds of follow-up, the number you sent would have been either too low and cost you money, or too high and scared them off.
Asking more questions is not distrust. Asking more questions turns the basis of your quote from “what I guessed” into “what you confirmed.” Every question you ask fills one more line on the booking form with a piece of information you can rely on. The process moves from guesswork to estimation, from estimation to calculation.
Next time you see someone in a group message say “the app launches next week, we need to test it,” do not rush to quote. Open your booking form first. Look at which lines are blank. Those blanks are your questions. Ask them, then quote. The number you write will have something solid behind it.
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
