Evaluate a WebFOCUS report as a complete user task: choose the right data, understand the result and use the required export. Record the installed release, report type, browser, access tools and output formats before testing. An authoring option is one input to that process; the rendered report is the evidence readers actually encounter.
Start with the installed release
The WebFOCUS 9.3.6 ACCESSIBLE parameter documentation describes SET ACCESSIBLE = 508 for HTML report output; OFF is the documented default. It also says the accessible HTML setting turns off pagination, placing column titles and headings at the beginning and page footings at the end. Check your release’s documentation and the generated output before applying this setting to a production report.
Record which report and configuration you tested. Include authentication, filters, empty results, long results and any interactive chart states that users depend on. A report embedded in a portal inherits additional navigation and control behavior that should be checked in that portal.
Use a small report with a known answer
The following fictional dataset represents open support cases at three branches. It is a native HTML illustration, not output captured from WebFOCUS. Build the same small report in your own test environment so that you can compare the intended information with what users receive.
| Branch | Open cases |
|---|---|
| East | 12 |
| North | 8 |
| West | 5 |
The total is 25 cases. East has the most, and exceeds West by 7. A chart alternative should communicate both the values and the comparison relevant to the report. Ask a tester to identify West’s value and the largest branch without relying on bar color or position. If the answer requires guessing which heading belongs to a cell, inspect the header associations. The W3C tables tutorial explains how captions and structural headers convey these relationships.
Follow the report through its changing states
- Choose a filter. Use the keyboard to reach the branch control, identify its label, select West and run the report. Focus should remain visible and the result should clearly identify the selected scope.
- Read the result. Confirm that West’s 5 cases can be located by row and column, and that the page identifies the report and its reporting period.
- Check a change. Return to all branches and confirm that the total becomes 25. If the update is dynamic, check how a screen-reader user learns that new results are available.
- Recover from an empty result. Use a test filter that returns no rows. The page should explain the state and provide a usable route to revise the filter.
Repeat the task at a larger text size. Check that labels, filter values and chart explanations remain available, including information normally revealed by pointing at a data mark. Capture the input and observed result whenever the workflow stops.
Check every required output separately
Export the same known dataset in each format people actually use. In a spreadsheet, check headers, sheet names, data types and reading order. In a PDF, inspect text, tags and navigation with suitable tools. An HTML report result provides evidence about that HTML; inspect each exported file on its own.
Keep a compact test record: release and report identifier; filter values; expected rows and totals; browser or document reader; access tools; actual result; issue owner; and retest date. For example, “All branches: HTML exposes West = 5; PDF omits the branch label in the reading order” pinpoints an export problem while preserving the successful HTML finding. Recheck the record after a report template, portal or export component changes.