How We Test Kaazo Tools
A green “Done” message is not proof that a tool works. A page can load correctly and still generate the wrong file; a converter can produce a valid download and still lose data; a perfect tool can become unusable because one CSS change hides the important control.
We test those failure types separately.
1. Page and asset checks
The first layer is mechanical. Production builds are scanned for missing JavaScript, CSS, images and internal destinations. We also check canonical URLs, sitemap targets, redirects, duplicate IDs and malformed markup that can quietly affect browsers or search crawlers.
This sounds boring. Good. Broken production paths are boring bugs with outsized consequences.
2. JavaScript parsing and regression cases
Core bundles are syntax-checked before packaging. More important, bugs that have actually occurred are turned into regression tests where possible.
Examples from Kaazo's own QA history include quoted CSS URLs being corrupted by a minifier, a valid JavaScript regular expression being mangled, duplicate CSV headers overwriting data, invalid RGB/HSL values slipping through validation and malformed CSV quotes being accepted. Those are not hypothetical examples; they became reasons to strengthen the test set.
3. Output checks, not just button checks
For converters and editors, “the button responded” is a weak test. We inspect the resulting structure or file for the property the tool claims to change.
- PDF page operations: page count, order, orientation and selected-page behaviour.
- Data tools: rows, columns, escaping, duplicate fields and malformed input.
- Image tools: dimensions, framing, format and metadata behaviour where relevant.
- OCR: whether text is actually extractable/searchable, not merely whether a PDF downloads.
- Editors: selection, drag/resize behaviour, undo state and export consistency.
4. Edge cases are chosen from real failure modes
Happy-path samples are necessary, but they are not enough. A one-page PDF and a tiny CSV tell you very little about what breaks under pressure.
We deliberately keep awkward cases in mind: mixed portrait and landscape pages, empty values, quoted commas, duplicate column names, out-of-range colour values, repeated edits and large inputs that stress browser memory.
5. UI changes are checked against the workflow
An editor should feel like an editor. That means direct work on the preview where practical—dragging, resizing, drawing or selecting—rather than forcing users to translate a visual task into raw percentage coordinates.
When we change explanatory content, we freeze the processing code unless a genuine tool bug requires a separate fix. That separation matters: a content release should not quietly change how a PDF is exported.
6. We keep the limits visible
No browser test matrix can cover every file ever created. Proprietary document features, damaged files, huge media and unusual encodings can still expose gaps. We say that plainly and ask users to keep originals and check important output.
Testing reduces surprises. It does not make honest caveats obsolete.
Reporting a problem
If you can reproduce a bug, send the tool URL, browser, source file type, what you expected and what happened instead. Do not send confidential source material publicly. See Feedback & Contact for the quickest reporting format.