How Testing Works

A practical guide to what you're reviewing, how to submit feedback and bug reports, and what makes a useful contribution.

Orientation Series Required reading — all tiers ~5 min read

What You're Testing

The RBA Case Management System is a web-based tool built on Duda with a Google Firebase backend. It's made up of several distinct components — forms, dashboards, and data views — each of which goes through review before being considered ready for production use.

As a volunteer, you'll be assigned specific components to review. Each assignment tells you which component to look at, what to focus on, and what questions to answer. You're not expected to test everything — just what's assigned.

Components in the system
Case Intake Form — how new arbitration cases are entered into the system
Case Dashboard — the main list view of all active and closed cases
Case Detail View — the full record for a single case, including hearing and ruling data
Settings Page — system configuration options including the AI intake toggle
Reports Page — output views for case history and practice summaries

Two Ways to Submit

The portal has two separate forms for submitting your findings. Use the right one for the right type of input — they're tracked separately in the admin dashboard.

💬

Feedback Form

For observations about the user experience — layout, labeling, clarity, flow, and anything that feels off but isn't technically broken. Use this for impressions, suggestions, and UX notes.

→ /feedback-form

🐛

Bug Report Form

For functional problems — something that doesn't work, produces an error, shows wrong data, or behaves differently than expected. Requires steps to reproduce and a severity level.

→ /bug-report

When in doubt

If something bothers you but you're not sure which form to use, default to the Feedback Form. It's better to over-report than to stay quiet about something that might matter.

The Testing Cycle

Testing follows a straightforward cycle. John creates assignments, you complete them and submit your findings, and John reviews and acts on the feedback before closing the assignment. Here's what that looks like step by step:

1

Assignment arrives

You receive an email notification and the assignment appears on your volunteer home page with a title, description, due date, and any relevant reference documents.
2

Review the component

Open the component or screen you've been asked to review. Read the assignment description carefully — it tells you what to focus on. Take your time and interact with it the way a real user would.
3

Submit your findings

Use the Feedback Form for UX observations and the Bug Report Form for functional problems. You can submit multiple forms for a single assignment — one per distinct issue is cleaner than combining everything into one submission.
4

Mark the assignment complete

Once you've submitted everything you found, go back to the Review Assignments page and mark the assignment complete. This lets John know you're done and he can review your submissions.
5

John reviews and acts

John reviews all submissions from the admin dashboard. Issues are addressed, changes are made to the component, and the assignment is closed when the cycle is complete.

Tips for Effective Testing

The quality of the software depends directly on the quality of the feedback. These habits make a significant difference:

Be specific

Name the exact field, button, or screen you're describing. "The dropdown in the Property Information section" is more useful than "one of the dropdowns."

Think like a user

You don't need to know how the code works. Ask yourself: "If I were an arbitrator using this daily, would this make sense?" Your instinct matters.

Reproduce bugs twice

Before reporting a bug, try to reproduce it a second time. If you can, you'll know it's reliable — and your steps to reproduce will be more accurate.

One issue per submission

Submit separate forms for separate issues. It makes triage much easier and ensures nothing gets buried inside a longer submission.

Note your browser

When reporting bugs, mention your browser and device. A problem on Chrome on Windows may not appear on Safari on iPhone — that context helps narrow it down fast.

Positive feedback counts

If something works well or feels intuitive, say so. Knowing what's working is just as valuable as knowing what isn't.

What Happens to Your Feedback

Every submission goes directly to John's admin dashboard. Feedback and bug reports are reviewed, triaged, and tracked. Some issues get fixed immediately, some are logged for a future build cycle, and some may be intentional design decisions — but everything is read.

You won't always receive a response to individual submissions, but your work is genuinely used to improve the system. If a submission raises a question or needs clarification, John may follow up directly.

Questions?

If you're unsure about an assignment, can't access something, or have questions about the testing process, email john@rbamgr.com.