1. What should you automate first?
Begin with business risk, repetition, and the reliability of the test interface. For a checkout system, a wrong total or duplicate charge may deserve attention before a low-impact visual variation. Choose a layer that can detect the risk with a clear failure signal. Not every assertion needs a full browser journey.
Our example separates a discount calculation into unit-level cases, payment integration into controlled API tests, and one customer checkout journey into an end-to-end check. Explain what each layer proves and what it deliberately does not prove. The distribution should follow the application and risk, not a fixed percentage copied from a testing diagram.
2. How do you make browser tests reliable?
Playwright's guidance emphasizes user-visible behavior and independent tests. Prefer interactions that represent how a user finds and operates the interface, and avoid coupling every assertion to internal implementation details. Give each test a controlled starting state so an earlier failure cannot silently determine a later outcome.
In our checkout exercise, one test creates its own basket and user rather than relying on a basket produced by another test. The test verifies a visible order confirmation and relevant persisted state through an approved test interface. Resetting data is part of the test contract, not a manual step somebody remembers before running the suite.
3. What do you do with a flaky test?
Collect evidence from failures and successes: timing, test data, logs, screenshots, network activity, and environment differences. Separate a product race from an automation race or an unstable dependency. A retry can reveal intermittency, but it does not establish that the application is correct or repair the test.
Imagine an assertion reads the cart total before a discount request completes. Replace a fixed delay with a condition tied to the expected state, then test slow and failed responses. If the application never indicates completion, the investigation may expose a product usability problem as well as a test problem. Record ownership and a deadline if quarantine is necessary.
4. Why do tests fail only when run in parallel?
Look for shared accounts, shared files, fixed record IDs, mutable global settings, and cleanup that deletes another worker's data. Parallel execution exposes dependencies that a sequential run can hide. Design independent fixtures or use explicit coordination where the application itself requires shared state.
For example, two tests both edit the same profile name and then assert their own value. Neither test is isolated. Give them separate users or test records, and make cleanup specific to the data each test owns. Do not solve every collision by serializing the entire suite, because that preserves the hidden coupling and increases feedback time.
5. What belongs in a CI quality gate?
Choose checks that are fast enough to run at the intended stage and meaningful enough to block an unsafe change. A pull-request gate might include focused unit, contract, and a small critical-path suite, while broader compatibility runs occur elsewhere. Explain the risk accepted between stages and how failures are assigned.
Report more than pass percentage. Track duration, unstable failures, time to diagnosis, and escaped defects relevant to the tested paths. A suite that always passes because assertions are weak is not a useful gate. A suite that blocks every release with unrelated instability encourages bypasses. Treat signal quality as a maintained engineering property.
A checkout interview exercise
List five risks: incorrect discounts, duplicate submission, expired authentication, unavailable payment dependency, and lost confirmation. For each, choose a test layer, required data, action, and observable result. Then ask which test would fail if the user double-clicked the final button during a slow response.
Practise explaining why you excluded some cases from the browser suite. Cluegent can help challenge your test plan during preparation, but validate proposed assertions against the application's actual contract. A strong closing answer describes useful coverage, independent execution, actionable evidence, and a maintenance plan rather than promising that automation eliminates all manual testing.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should every test be end-to-end?
No. Choose the lowest useful layer that can detect the risk, then retain end-to-end coverage for critical integration paths.
Do retries fix flaky tests?
No. They can collect evidence or temporarily reduce interruption, but the underlying product, data, timing, or environment issue still needs diagnosis.