On a hosted browser provider, what does a test run consume, and what sets how much?

## Consumption is an area, not a duration A hosted browser provider does not sell test runs; it rents **sessions that are open**. When your suite asks for a browser, the provider starts one somewhere on its fleet and hands back an identifier. From that moment until something closes the session, a target on the far side is reserved for you and nobody else. What a run consumes is therefore the sum, across every session it opened, of how long that session stayed open. That sum is easier to reason about as a rectangle: - the **width** is how many of your sessions are open at the same moment — the concurrency the run actually reaches; - the **height** is how long a session stays open, from the browser becoming usable to the close arriving; - the **area** is the session time the run spends, and it is the quantity that moves when either edge moves. Take a regression suite for a council planning-application tracker: cases that submit an application, cases that walk an officer's case-note trail, cases that post a public comment and check it appears. The browser work those cases need does not change when you decide to run them all at once rather than in sequence. What changes is when the suite finishes. ## The two edges do different jobs This asymmetry is the whole reason the model is worth carrying, and it separates a candidate who has run a suite from one who has paid for one. | change you make | wall-clock the pipeline waits | session time the run consumes | |---|---|---| | open more sessions at once | falls | broadly unchanged | | make each session shorter | falls | falls | | run fewer cases | falls | falls | Only the top row moves one edge without moving the other. A suite run wider finishes sooner and consumes broadly what it consumed before, because the same browser work has simply been rearranged in time. This is why *"we made the suite fast"* and *"we made the suite cheap"* are different claims, and why a team reporting the first as though it were the second is usually about to be surprised. **"Broadly unchanged" is doing honest work in that table.** Widening a run can lengthen the sessions inside it. More of your sessions driving the application under test at once makes every page slower; contended hardware on the provider's side makes every command slower; shared fixtures and shared test data make cases wait on each other. The width grew and the height grew with it, so the area can rise even though the pipeline waited less. How to shard a suite so the wall-clock actually drops is a separate subject with its own owner — the point here is only that the two edges interact rather than moving independently. ## Where the height quietly grows Duration is the edge you control most directly, and most of it is not test steps at all: - a fixed sleep left in a case, waiting out a condition that was already true; - a session opened before the data fixtures are built rather than after; - the last assertion passing while the browser stays open through report writing and artefact collection; - a retry opening a replacement session before the previous one has finished closing; - teardown that drives the application through the browser to clean up instead of calling its own interface; - an authentication flow repeated in the browser for every case rather than established once and reused; - a session left behind by a case that failed on a path with no teardown on it. Each of these is time the meter sees and the tests do not need. They are the cheapest savings available precisely because none of them costs any coverage. ## What you can measure and what you must establish The rectangle splits cleanly into what is yours and what is the vendor's. Measurable from your own harness, exactly, without asking anyone: - when you asked for each session and when it became usable; - when you closed it, and how it closed; - the peak overlap your sessions actually reached, which is not the same thing as the worker count you configured. To be established with the provider rather than guessed: - which shape the meter uses — time a session is open, reserved parallelism and per-person access are different shapes with different levers, and that mapping belongs to Usage Metering; - whether a request waiting for a free slot is counted while it waits; - whether consumption is rounded to some unit before it is summed. Be careful with a third category that looks like the others and is not: what a provider's *own* costs do while your sessions are quiet is internal economics, not something a tenant observes. Reasoning from a guess about it produces confident nonsense. Say what you can observe, and name the rest as a question for the vendor. ## The interview shape Answer with the rectangle in one breath, then the asymmetry, then the honesty: width moves wall-clock, height moves the total, widening can lengthen the sessions inside it, and the meter's own rules are established rather than assumed. That answer is short, correct at every edge, and needs no figure at all to be right.