Fiddler is a family of tools for analyzing and modifying HTTP traffic. It helps QA verify what a client actually sent, which response it received, and how it handled an error. This is useful for web applications, desktop clients, and other systems that can use a supported proxy route.
First establish the product and version. Fiddler Classic and Fiddler Everywhere have different interfaces and configuration mechanisms. Instructions for AutoResponder, Rules, and FiddlerScript are not interchangeable. This article describes response replacement through Rules in Everywhere; for Classic, consult its documentation for the corresponding AutoResponder scenario.
What a proxy helps you investigate
Imagine a form that sometimes shows “unknown error.” Fiddler connects that symptom to a request: whether a call occurred, whether parameters matched, and which status and body were returned. This helps distinguish a server failure from the client's incorrect interpretation of a response.
A proxy can also return prepared responses. You can test an empty list, access denial, or temporary unavailability without waiting for a random failure. This is a controlled client check, so a substituted response does not establish how the real server dependency behaves.
Routing and capture scope
Check that your test application uses the intended proxy. System settings may not affect a client with its own network stack. An absent record does not necessarily mean no request was sent: the client may bypass the proxy, use another interface, or read a local cache.
Limit domains and processes to the task. First make one control request without replacement and locate it by method and path. Capturing all work traffic on the computer hides useful signals among background requests and makes the saved artifact harder to control.
HTTPS and trust
To read HTTPS, enable the appropriate decryption and configure the test client to trust the selected Fiddler product's root certificate. Configuring only the computer does not guarantee trust on a phone or within a separate runtime.
Pinning and independent trust stores may prevent operation. Use agreed debug-build settings for your own application. A protected build rejecting the proxy certificate is no reason to disable checks in the production product. Observing proxy routing and inspecting TLS request contents provide different levels of evidence.
A session as evidence
Inspect more than the status: request body, parameters, authorization headers, Content-Type, redirects, and response all matter. Compare successful and failing actions using the same build and data. An automatic retry may create a second session with a different outcome.
Timing through a proxy reflects the selected route and tool processing. It can help locate a delayed step but is not a guaranteed measure of server latency. Serious performance conclusions require control measurements and infrastructure observations; otherwise, the cause of slowness remains an assumption.
A replacement rule in Everywhere
Rules connects conditions to actions. For a test catalog, restrict matching to the exact host, GET method, and /api/catalog path. Create an action returning a manual 503 response with a JSON body matching the application's error contract.
Check rule order and confirm application in the session. Return Manual Response completes the call locally, so the server never receives the request. Modifying a response already received from the server has different semantics. This distinction is crucial for creation and save operations.
Practical example: temporary catalog failure
Your store's catalog should show a clear message and retry button while retaining selected filters. Prepare a test build, a filtered request, and a known nonempty result. First verify that the scenario works without Rules.
- 1.Enable a narrow rule returning 503 with Content-Type application/json and the agreed error structure. Only the intended request should match.
- 2.Open the filtered catalog. Expect loading to end, a clear explanation of temporary failure, and an available retry action.
- 3.Disable the rule and retry. Expect successful loading with the same filter, without an unnecessary state reset or endless retries.
- 4.Repeat with an empty successful collection. Expect a distinct empty state that does not resemble a server error.
This tests distinctions between business states, beyond simply displaying text. If the API error uses a different contract, replace the teaching example with an agreed real example.
Repeating requests and side effects
Repeating a read is usually simpler than repeating order creation, but the method alone does not guarantee no side effects. Clarify the contract before resending. State-changing operations need test data and an understanding of idempotency.
The server may have performed an action even when the client received no confirmation. Read the final object separately, then retry with the original idempotency key if supported. A new key may represent a new operation; it is not a universal way to retry without duplication.
Saving and sharing evidence
Save the minimum session set needed for reproduction. Specify the Fiddler product, version, rule, application build, and action sequence. Without the rule, a colleague may receive a normal successful response and be unable to reproduce the client issue.
Remove tokens, cookies, and personal data from all shared material. Even unrelated requests may be included in the same file. A rule containing a secret header is also sensitive; text export does not automatically make it safe to publish.
Mistakes and completing the check
Common mistakes include following instructions for another edition, leaving a rule enabled, treating a local mock as a real server failure, and failing to verify state after an error. An overly broad host or path match can affect token refresh and create secondary symptoms.
After the experiment, disable rules, restore network settings, and remove unnecessary test trust according to team procedure. A useful outcome is a verified reaction to a known contract, an exact request, and reproducible conditions that let a developer fix specific behavior.