🧩 The Edge Case | Could Your Testing Tool Accept Dangerous Input? ✅

Sponsor Spotlight • Level 1

Partner with QA Testing Jobs to feature your tools, platforms, or services to thousands of testers every week.

Hi there,

We spend plenty of time testing the inputs our applications receive. But the tools doing the testing consume inputs too: archives, file paths, configuration, JSON responses and browser-driver messages.

Selenium 4.46 offered a useful reminder. It hardened Selenium Manager against path traversal during archive extraction and tightened its Java JSON parser around malformed input.

Here are five checks you can try against a parser, installer or test utility:

1. Escaping path: Add an archive entry such as ../outside.txt. Confirm extraction cannot write outside its temporary directory.
2. Absolute path: Supply a filename pointing somewhere outside the extraction destination. It should be rejected.
3. Control character: Put an unescaped control character inside a JSON string. Expect a clear parsing error.
4. Broken structure: Try truncated JSON or incorrect comma placement. The tool should fail without accepting partial data.
5. Malformed number: Try values such as 01 or an incomplete exponent such as 1e. Confirm the parser follows the expected JSON standard.

If you are newer to testing, turn these into one small parameterised test and record the expected error for each input.

If you lead an automation suite, look at the tools your CI pipeline downloads, extracts and parses. Check that failures leave no partial state, expose no sensitive paths and stop the pipeline safely.

The useful lesson is simple: your testing tools are software too. Anything that downloads, extracts or parses data deserves negative testing.

Yours in testing,

Farid Vaswani

Community Partner

Have a QA community, course, or event to promote? Reply to reserve this feature placement.