What can a hosted browser provider count as usage when your test suite runs?
answer
- usage has to become a quantity somehow
- three common shapes, often combined
- time open, width held, people admitted
- a reserved width bills when empty
- know which quantity your charge follows
basics
~20 sA hosted browser provider can count the time each session stayed open, the parallelism you reserved whether you used it or not, the people granted access, or some combination of those. Each shape rewards a different discipline.
solid answer
~50 sA hosted browser or device cloud has to turn your use of shared hardware into a quantity it can charge for, and there are three common ways to do it. It can count **elapsed session time** — the span each browser session stayed open, usually from creation to release rather than just the part your assertions were busy. It can count **reserved parallelism** — a width of simultaneous sessions held available for your account, charged whether you fill it or leave it empty. Or it can count **people granted access**, which makes the charge a function of your team rather than your suite. These are not exclusive: an arrangement often combines a reserved width with metered consumption above it. The practical consequence is that each shape rewards a different discipline, so before optimising anything you should be able to say which quantity your own charge follows.
go deeper
Be ready to name the three shapes in plain words: time a session stayed open, parallelism reserved in advance, and people granted access. Interviewers ask this to check you have looked at where the money goes.
Be ready to explain why the shapes are not interchangeable. Each makes a different thing free and a different thing expensive, so the optimisation that works under one does nothing whatever under another.
Be ready to say which shape your own team is on and how you know that. Teams routinely optimise against a shape they assumed rather than the one their arrangement actually describes.
Be ready to treat the shape as a constraint on how teams work. Metered time pushes towards frugal short runs, a reserved width pushes towards dense scheduling, and access counting pushes towards one shared pipeline.
## Why a provider has to count something A hosted browser or device cloud rents you machines you neither own nor can see. A browser cloud runs virtual machines or containers that boot a browser on demand; a real-device cloud keeps actual handsets and tablets wired into a rack. Either way that hardware has to be there and stay there, whether your veterinary booking suite is running against it or not, so the provider needs a quantity it can measure and turn into a charge. Hosted providers of this kind — BrowserStack, Sauce Labs and LambdaTest among them — sell capacity you do not operate, and how they choose to count it is one of the first things a new user should find out. Three quantities come up again and again. They are worth learning as *shapes*, because particular arrangements change but the shapes do not. ## Time a session stayed open The most intuitive shape. A session opens and a clock starts; the session is released and the clock stops; what you owe grows with the accumulated span. - The counted span is usually the whole life of the session, not the part your assertions were busy. Browser startup, the receptionist login your suite performs first, and teardown all sit inside it. - A session that is open but doing nothing still accumulates, because the provider is still holding a machine for it. - The discipline this shape rewards is **frugality**: never open a session you do not need, and release the ones you have as soon as the work is done. ## Parallelism reserved in advance Here the provider does not count what you used. It undertakes to hold a width of simultaneous sessions available to your account, and charges for that undertaking. - The charge is settled before the period starts, so nothing that happens during the period is an input to it. - Reserved capacity is perishable. A quiet Tuesday does not accumulate into a busier Thursday; the unused width is simply gone. - The discipline this shape rewards is **density**: fill the width you already bought, and treat empty width as waste you have already paid for. ## People granted access The third shape counts neither time nor capacity but the group admitted to the account, which makes the charge a function of your organisation rather than your workload. - Nothing the veterinary booking suite does is an input. It can run nightly or never, wide or narrow, and the charge is identical. - What moves the charge is breadth of access, which is why this shape pushes teams towards one shared pipeline running on everyone's behalf. - The discipline this shape rewards is **consolidation** — and, less obviously, *more* testing, because the marginal run genuinely costs nothing. Side by side: | what is counted | what makes it grow | the discipline it rewards | |---|---|---| | time a session stayed open | longer and more numerous sessions | frugality | | reserved parallelism | a wider reservation | density | | people granted access | a broader group holding access | consolidation | ## They combine, and that matters Real arrangements are frequently hybrids: a reserved width as a predictable base, with metered consumption above it when a week runs unusually hot. That is a sensible split of risk — the provider can plan hardware, you can plan a budget, and an unusual week is served rather than refused — but it means two levers apply at once. Utilisation governs the base; frugality governs everything spent above it. A team that knows only one of the two will optimise half of its charge and be puzzled by the other half. Note also what none of these shapes counts: the wall-clock time of your own pipeline job. If the veterinary booking pipeline spends a long stretch installing dependencies and building the application before any browser session opens, that stretch costs your CI provider's time and not the browser cloud's. Conflating the two sends optimisation effort to entirely the wrong place. ## Why an interviewer asks this It is a check that you have looked at where the money goes rather than treating the provider as an infinite resource behind a URL. The follow-up is almost always *which shape are you on, and how do you know* — and the honest answer frequently reveals that nobody on the team has read the arrangement. The point of the question is not the taxonomy. It is that every optimisation you might propose bites on exactly one of these shapes and slides off the other two, so you cannot sensibly choose a lever until you know which quantity your own charge is a function of.
- Why would a provider combine a reserved width with metered consumption above it?It splits the risk. The reserved width gives both sides a predictable base — the provider can plan hardware, the customer can plan a budget — while metering above it means an unusual week is served rather than refused. For the customer it means two levers apply inside one arrangement: utilisation governs the base, and frugality governs everything spent above it.
- Which of the three shapes makes an extra test run cheapest?Access counting, by a distance: once someone holds access, an extra run of the veterinary booking suite adds nothing to the charge. A reserved width is next, provided the run fits inside capacity you already hold and were not using. Metered time is the only shape where an extra run carries a direct and unavoidable cost, which is why frugality is the discipline it trains.
saying these in an interview costs you the question
- Assumes every browser cloud charges only for time a session was open.
- Thinks reserved capacity is refunded when it goes unused.
- Believes the shapes are exclusive and a charge can only be one of them.
- Cannot say which quantity the team's own charge is a function of.
- Confuses the provider's charge with the wall-clock time of the pipeline job.