How to Write a Good Bug Report (and Get Credited for Testing RSFlowHub)

"The form is not working" is the most common bug report, and one of the least useful. The person who reads it has to ask which form, which browser and what you typed before they can even start. A good report saves that back and forth, and a report that gets fixed quickly is the best evidence of testing skill you can show. This guide gives you a template and a worked example, then explains how to practise on a live website and get credited for it.

What a good bug report includes

• A clear title. Say what fails and where: "Password reset email link shows a 404", not "Login problem".
• The page or link where it happens.
• Steps to reproduce. Number them, and start from a place anyone can reach.
• Expected result. What should have happened.
• Actual result. What happened instead, with the exact error text.
• Your device and browser, such as "Android 14, Chrome".
• A screenshot or short video, with any personal details hidden.

Before you send it, try the steps once more. If the problem only happens sometimes, say how often, for example "3 times out of 5".

A bug report template you can copy

What went wrong:
Page or link:
Steps to reproduce:
1.
2.
3.
What you expected:
What happened instead:
Device and browser:
Screenshot or video link (hide any personal details):

Bad and good reports compared

This is a made-up example, not a real RSFlowHub bug. Both reports describe the same problem:

How serious is the bug?

You do not have to rate your own report, but thinking about it helps you put the most important facts first:

• High: people cannot complete a main task, such as signing in, or they lose data.
• Medium: a feature is broken, but there is a way around it.
• Low: something looks wrong or reads badly, but everything still works.

A security problem is a separate case. Do not post it publicly or send it through a normal support form. Use the channel the company gives for security reports.

Common mistakes

• Several bugs in one report. Each one may be fixed at a different time, so send them separately.
• Guessing the cause. Describe what you saw. "The server is down" may be wrong, but "the page shows error 500" is a fact.
• Skipping the first steps. The step you think is obvious may be the one that causes the bug.
• Sharing private details. Hide passwords, keys and personal data in screenshots.
• Reporting a preference as a bug. "I would like this button in blue" is a suggestion. Suggestions are welcome, but label them as suggestions.

Practise on a real website

Demo sites are useful, but their bugs have already been found thousands of times. Testing a live product is different: nobody knows what you will find, and a real team reads your report.

RSFlowHub is a no-code AI chatbot platform for websites, and our testers program is open to anyone:

1. Create a free account. You do not need to apply first.
2. Test with your own made-up data.
3. Send your report through the contact form, and say what name or link you would like us to use.
4. Get credited. If it is a real issue that we can reproduce and did not already know about, we ask how you want to be named and add you to the list of people who helped.

What to test on RSFlowHub

• Sign-up and sign-in: creating an account, verifying email and resetting a password.
• Chatbot setup: adding business details and trying the test chat.
• The chat widget: try the live demo, then add it to your own test page.
• Forms: try the forms demo and test its validation.
• The APIs: run endpoints in the playground and compare them with the docs.
• Language: ask questions in Hindi and Hinglish and check that the replies make sense.
• Phones: look for pages that overlap, get cut off or cannot be used on a small screen.

Rules for testing a live site

Real customers use this website, so testing has limits. These apply on RSFlowHub, and they are a good habit anywhere:

• Use only your own account and made-up data, and never look at anyone else's.
• Do not run load tests or automated scanners.
• Do not spam forms, chat or support, and do not trick staff.
• Do not create extra accounts to collect free credits.
• Do not make a real payment just to test checkout.
• Stop as soon as you have confirmed a problem, and give us time to fix it before you post about it.

Found a security issue? Email security@rsflowhub.com instead of using the contact form, and follow our vulnerability reporting rules.

Using this in your portfolio

If you are learning QA or looking for your first testing role, keep copies of your best reports with any private details removed. A credit gives you a public link to show. Describe it accurately, such as "found and reported a bug in RSFlowHub". It does not mean that you worked for the company, and it does not guarantee a job.

Frequently Asked Questions