In a learning catalogue, selecting a category changes the product list, but the reset button does not restore its initial state. A message saying “the filter is broken” leaves the developer with many questions: which filter, on which page, after which actions, and what should have happened? A website bug report turns that observation into a testable task that can be reproduced and closed against a clear criterion.
The following is an illustrative exercise, not a real client incident. It requires only a browser and access to a test copy of the catalogue. Administrator permissions, package installation and code changes are unnecessary. If you are checking a production shop, stick to safe browsing: do not create paid orders or change someone else's data merely to reproduce a problem.
Start with one observation, not a diagnosis
A useful title describes the action and failure: “Resetting the category leaves the previous product list”. Saying “JavaScript works incorrectly” already assumes an unproven cause. The problem might involve the button handler, server response, stored state or another component. Record the visible behaviour first; add any technical hypothesis separately and explicitly label it an assumption.
Do not combine several independent problems into one ticket. If you notice both an incorrect list and an overlapping heading on a phone, write separate descriptions with their own steps. Discovering them on the same date does not establish a shared cause. A small task makes it possible to verify the fix without arguing over whether part of a large message remains unfinished.
Define the expected behaviour before assessing severity. If resetting should clear only the category, it does not necessarily need to remove the search text and sorting. The basis might be an agreed requirement, button label or scenario description. Where no requirement exists, ask what the intended behaviour should be instead of presenting your own expectation as a proven defect.
Build the shortest route to the failure
Record the starting address and page state. For this exercise, you can call the location “test catalogue” without inventing a live service address. State whether the user is signed in, whether the search contains text, which sorting option is selected and whether the page was reopened. A hidden initial state often explains why someone else cannot see the reported result.
The sequence for the learning example is: open the catalogue without filters; select one category; wait for the list to change; reset the category; compare the list and active-filter indicator. Give each action a separate step. Do not add incidental navigation or repeated clicks if the problem also occurs without them: a shorter scenario is easier to reproduce.
Describe the expected and actual results in separate sentences. For example, you expect products from all categories to return while sorting remains unchanged; instead, the category indicator disappears but the list stays as it was. Avoid merely saying “it does not work”: part of the interface has already changed in this example, and that distinction helps narrow the check. Do not present the example as a test result from your shop.
Repeat the scenario several times and record the actual outcome rather than inventing a reproduction percentage. If the failure is intermittent, record the time, preceding action and observed differences between attempts. Do not treat a page reload as proof of a fix: it might only clear the state. Repeat the same route that caused the problem.
Add evidence that helps reproduction
Include the browser and its actual version, operating system and device type. For a layout problem, viewport dimensions and screen orientation are useful. Do not invent parameters or say “on all phones” after checking one. Record the environment you verified and separately list what still needs checking.
A screenshot should show the problem location and enough context: the active filter, button and list. When the sequence matters, a short screen recording is more useful than several unrelated images. Keep written steps alongside the recording so that the task is understandable without watching a video. Remove personal data, private tabs, notifications and details of other people's orders before sharing the material.
If you know how to use developer tools, include the exact relevant error text and when it appeared. A red message alone does not establish a connection to the filter. Compare the timing of the click and error. Do not send a complete network export without reviewing it: it may contain tokens, cookies or private request bodies. Sharing a minimal, cleaned excerpt is safer.
Agree on priority and a completion criterion
Describe the effect on the user: returning to the full catalogue requires reopening the page. Separately mention any workaround and its limitations. Priority depends on impact and team agreements, not just an emotional description. Do not call the task critical merely because an error exists, but do not hide a genuinely confirmed blockage of an important scenario either.
The exercise's completion criterion is: after reset, no category is indicated, the list matches the initial set, agreed sorting remains intact, and selecting and resetting again works. If the issue was found on a phone, the check must include that environment. Add the adjacent search scenario if combining search and category is part of the requirements, rather than arbitrarily expanding the task after the repair.
After the fix, repeat the original steps on the agreed test version and record the outcome. State the build version or check date when known. If the failure remains, update the same task with new evidence. Keep this scenario as a regression check for future updates; technical changes should also be reviewed before pushing them in Git.
Conclusion: a good bug report does not require guessing the cause or writing code. It includes an observation, initial state, short steps, expectations, actual results and a completion check. If a problem is difficult to reproduce or describe without exposing private data, AriZone can help prepare a safe diagnostic scenario and agree on the next actions.
Leave a comment