Your team re-records its JMeter plans from the browser each release. How would you decide what stays recorded?

The failure mode this question is really about is a team that treats "re-record it" as the maintenance strategy. It works for two releases and then the plan is a museum: nobody remembers which samplers were pruned on purpose, the extractors were lost in the last capture, and the only person who can regenerate it is the one who remembers the browsing order. ## Draw the line by ownership, not by convenience Ask of every part of the plan: *did the application decide this, or did a person?* | The application decided it | A person decided it | | --- | --- | | Which requests a journey makes, and in what order | Which of them are worth recording | | Methods, paths, parameters, request bodies | What each step is called | | Which headers the browser sends | Which managers hold state on replay | | That a value exists in a response | Which values are extracted and how | The left column is what the recorder discovers, and it genuinely re-discovers it better than a human reading a diff. The right column is design, and every re-record that overwrites it is throwing away work. ## Make the recording arrive comparable Small standardisations remove most of the churn: 1. **A shared exclude list.** `proxy.excludes.suggested` seeds the **Add suggested Excludes** button; ship the team's list in `user.properties` and every recorder starts from the same pruning. Otherwise one engineer's capture has fonts and analytics in it and the next one's does not, and the diff is unreadable. 2. **A grouping and naming convention.** Grouping into Transaction Controllers plus the recorder's Transaction name field driven per step means the capture arrives already named after user actions, so the same journey recorded twice produces recognisably the same tree. 3. **UDVs before you record, not after.** With User Defined Variables in the target controller, the recorder writes `${host}` and `${basePath}` into the samplers as they are captured, so an environment switch is not part of the cleanup. 4. **Record into a new controller.** Point the Target Controller at a fresh Recording Controller, capture, then merge into the maintained journey. Never record on top of the plan you have curated. ## Decide what a re-record is for Once the split is clear, the release-time question becomes narrow: *did the request sequence change?* If a new call appeared or a form gained a field, a fresh capture is the cheapest way to find out and the merge is small. If only the ids and tokens changed, re-recording gains nothing and costs you the correlation. That also tells you when recording stops being the right tool at all: - A journey that only exists behind a browser workflow — record it. - A single API call you already have as a `curl` line — `Tools > Import from cURL` is faster and reproducible from the ticket. - A journey whose requests are generated by client-side code and change per release — recording buys you one sample of a moving target; think hard before making it the source of truth. ## Costs to state out loud - **The recorder is GUI-only.** Nothing about capture can run in CI, so recording is inherently a manual step performed on someone's laptop. That is the strongest argument for keeping the *maintained* part of the plan small enough to reason about by hand. - **HTTPS recording means trusting a generated CA** on that laptop for the length of its validity. It is a real, if bounded, risk, and it belongs in the team's decision rather than in an individual's habit. - **Captured plans encode one person's browsing.** Two engineers recording "the checkout" produce different trees unless the conventions above are enforced. ## What good looks like A team that has this right can answer three questions instantly: which parts of the plan are safe to regenerate, which must be merged by hand, and what a fresh recording is expected to reveal. The recorder then stays what it is good at — a fast, faithful way of finding out what the application actually asks for — and the parts that make the plan a *test* stay under human control, reviewed like any other change.