Release process

How WEBBE-B tests browser tools.

A public tool is reviewed as a working product, not only as a collection of files that happens to load. The exact test plan changes with the tool, but the release process follows the same sequence: verify the primary task, attack obvious edge cases, check the interface at different viewport sizes, review user-facing claims, and confirm that the surrounding site is complete enough to navigate and understand.

1. Primary workflow

The first test is the reason the product exists. A screenshot stitcher must produce an export, a duplicate finder must identify exact matches, and a calculator must update from its inputs. Controls that appear to work but do not affect the result are treated as defects rather than decorative placeholders.

2. Input boundaries and errors

Tools are tested with empty input, common valid input and at least several inconvenient cases appropriate to the feature: very long filenames, unsupported formats, zero values, conflicting rename results, large dimensions or missing fields. Error messages should identify what the user can change instead of leaving the page in a silent broken state.

3. Result verification

A result should be checkable independently where practical. File duplication is verified from byte content rather than filenames. Finance formulas should expose the assumptions behind the displayed value. Image exports should be reopened and inspected rather than trusted because a download button fired.

4. Browser-local claims

If a tool says that selected files stay in the browser, that claim is reviewed against the implementation. The wording must distinguish the local task from ordinary page requests to hosting or third-party services. Privacy wording is treated as a technical claim, not a slogan.

5. Responsive and keyboard behaviour

The main workflow is checked at desktop and narrow mobile widths. Important controls should remain reachable without horizontal-page breakage. Navigation menus need an accessible label and state, forms need labels, and the page should remain usable with ordinary keyboard navigation wherever the control type supports it.

6. Content and navigation

Every public product needs enough explanation for a first-time visitor to understand what it does, what input it expects, what output it creates and where the limitations begin. Core network links—Tools, Guides, About, How we test, Standards, Contact, Privacy and Terms—must not lead to unfinished pages.

7. Search and metadata checks

Public pages are checked for a unique title, description, canonical URL and indexing directive. The root site maintains a sitemap and robots file. Product discovery data is generated from the central registry so visible tool names and URLs can be tested against the same source.

8. Advertising separation

Advertising code is not treated as part of the product result. Pages that are mainly navigation, error handling, legal reference or another low-value action can be kept without ad loading. On interactive products, advertisements should not be placed in ways that invite accidental clicks next to primary controls.

9. Release evidence

For larger changes, WEBBE-B keeps machine-readable or text reports covering syntax checks, generated-directory tests and other release gates. A passing automated test is useful evidence, but it is not a substitute for checking whether the user-facing behaviour matches the claim.

What testing cannot guarantee

No release process can prove that a browser tool has no defects on every device or with every input. Browser versions change, user files can be malformed, and external services can change. When a defect is reported, the goal is to reproduce it, identify the affected version and correct the claim or implementation rather than hide the limitation.

Found a problem? See how to report a reproducible issue.