“The form is broken” sounds clear until I try to fix it. Which form? What was entered? Did it fail before the request or after the response?
Before making another change, I want to write a small bug report. Even if I am the only person reading it, it gives the investigation a clearer start.
Write one reproducible path
For an imaginary profile editor, the steps could be:
- Open a test profile with a website address.
- Replace it with another valid address.
- Select Save.
- Reload the profile.
Then I separate the expectation from the observation. The new address should remain after reload. Instead, the old one returns.
That is evidence. “The database is broken” is still a possible explanation, not something those steps prove.
Add the context that matters
I note the page, browser, account state and whether this happened in a test or live environment. I include the visible error where there is one.
I use test data and remove private details from anything shared. A screenshot is useful only if it shows the relevant state without exposing someone else's information.
Try a nearby comparison
Does another field save? Does the same change work on a new test profile? I record the result without treating one comparison as proof of the cause.
I also keep track of changes already tried. Otherwise I can repeat an unsuccessful fix because I forgot what happened the first time.
Define the finish line
The original steps become the first verification check. After a fix, I repeat them and confirm the saved result survives reload.
I check a nearby action too, such as leaving the address unchanged while saving another field. The checks should fit what the change could affect.
If I cannot reproduce the report, I say so and record what I tried. That is more useful than claiming a fix without seeing the failure.
The report can be short. It needs enough detail to replace random edits with a specific question, and enough clarity to tell when I have answered it.