A report export is complete only when the file is useful

Define the question the report should answer

Begin with a practical goal. In an illustrative activity tool, a manager might need last week's completed items for one team. Record the selected dates, filters, role and known synthetic dataset.

Before exporting, inspect whether the interface explains what will be included. “Export all” can mean all matching rows, the current page or every record the role can access. The label needs to match the implementation, and the reviewer needs to know the intended rule.

Follow the generation and download path

For an immediate export, check the feedback after activation. For a queued export, inspect progress, completion and the route back to the file. If the person leaves and returns, can they identify which generated file belongs to their request?

Use an authorized test environment for failure scenarios. A failed generation should not be presented as a completed empty report. A delayed result should not encourage the person to create repeated jobs without understanding the consequence.

Open the actual file

Check the contents using the intended reader or spreadsheet application. Use known fixtures so you can compare the exported rows and values with the expected scope.

Review practical details:

• The filename distinguishes the report and, where useful, its date or scope.
• Column headings make the values understandable.
• Dates, units and time zones are identified where ambiguity would matter.
• Important text is not truncated beyond use.
• The exported scope matches the documented filter behavior.
• Empty output is distinguishable from an export failure.

For a PDF, inspect page breaks and readable tables. For a spreadsheet, inspect data types and leading zeros where relevant. Do not declare correctness merely because the file opens.

Treat sharing as a separate decision

An export can contain more information than the on-screen view made obvious. Review the file before sharing it and confirm the intended recipient and data scope. Use synthetic fixtures for test evidence, not live customer reports.

A usability review does not replace authorization tests or a complete audit of spreadsheet and document safety. Keep those requirements visible if the product's export risk warrants them.

The strongest report records the request, the generated output and the comparison against known expectations. That makes “export works” a specific, reviewable claim.

Next step: Define the exported result as an acceptance criterion in the Golden Journey Test Contract.