PetProov: QA for
a React and Firebase Verification Dashboard

An admin dashboard that emails real people and writes to a live database is the kind of software you cannot test carelessly. One sloppy test run and you have spammed users, corrupted production records, or quietly left the door open to anyone who is not an admin. The PetProov Dashboard touches all three of those risks at once, which is exactly why its testing had to be deliberate. This is the story of the software quality assurance that made it safe to ship and safe to change.

The PetProov Dashboard is an admin tool for running pet-verification checks. Admins log in with role-based access, start a verification check that emails an invite to the user through SendGrid, and see the resulting checks in a paginated table with type, name, contact, date and time, and a risk status. They approve or reject each check, which updates its status and emails the user, resend invites when needed, and watch a set of summary cards that count checks by risk level. It is built in React on Firebase, using Firestore and Authentication, with SendGrid handling email.

Put simply, this dashboard is delicate because it touches real people and real services. It sends email, it reads and writes verification records, and it gates everything behind admin access, so it had to be tested thoroughly without emailing users, without corrupting production data, and without leaving the access boundary unproven. The QA approach met that with a layered strategy run in a safe environment and automated on every change.

The Starting Point: Real Emails, a Live Database, a Hard Boundary

An admin dashboard tied to email and a live database is easy to test badly and risky to test carelessly. Six problems set the testing agenda:

• Email without spamming anyone. Initiating, approving, rejecting and resending all send SendGrid emails, so the flows had to be verified without any real message going out.
• A live database to test against. Checks are read from and written to Firebase, so tests had to run on realistic data without touching or corrupting production.
• An access boundary to prove. Only admins may use the dashboard, so role-based access had to be tested from both sides rather than assumed.
• Actions that must be correct. Approve, reject and resend each change state and send email, so every action had to be checked end to end for the right status and the right message.
• Numbers that must match. The summary cards and the table are driven by Firebase data, so their counts and rows had to be verified against the source, including through pagination.
• Regressions across changes. As the dashboard evolves, working behaviour has to keep working, so the testing had to be repeatable and automatic.

The QA Approach: Make the Risky Parts Safe to Test

The testing runs at three levels so defects surface as early and cheaply as possible: unit tests for components and the risk-status logic, integration tests for the Firebase and SendGrid touchpoints, and end-to-end tests for whole admin journeys. What made that possible was neutralizing the two dangerous dependencies. SendGrid is mocked or run in a sandbox, so email flows are verified by asserting that the right message would be sent, with nothing actually delivered. Firebase runs in its emulator with seeded test data, so every test works against realistic records without ever reaching production.

With the dependencies made safe, each action is tested the whole way through rather than in fragments. A single verification action is verified as an ordered sequence:

1. The Firebase emulator is seeded with known test records so the starting state is fixed.
2. The action is triggered, an initiate, approve, reject or resend, from the admin UI.
3. The test asserts that the check’s status changes correctly in the data.
4. It confirms the change is reflected in the table and the summary cards.
5. It checks that the correct SendGrid message would be sent, without a real email leaving the system.

On that foundation the specific behaviours are proven. Role-based access is tested from both sides, so an admin reaches the dashboard and its actions while an unauthenticated or non-admin user cannot. The summary cards, total, low, medium, high and incomplete, and the checks table are tested against the seeded data so their counts and rows always match, pagination included. Because the whole dashboard hangs on two outside services behaving predictably, the safe-integration work here is the kind of connective testing our API development team does whenever a product has to talk to email and database services it does not control.

Technical Architecture of the Test Suite

The suite is a layered strategy run in a controlled environment: a Firebase emulator with seeded data and a mocked SendGrid, exercised at unit, integration and end-to-end levels and automated in continuous integration. The pieces that matter:

• Layered tests. Unit tests cover the components and the risk-status logic, integration tests cover the Firebase and SendGrid touchpoints, and end-to-end tests cover whole admin journeys, so each defect is caught at its cheapest level.
• Safe third-party testing. SendGrid is mocked or sandboxed so no real email is sent, and Firebase runs in its emulator with seeded data so no test ever touches production.
• Access testing from both sides. Role-based access is checked for the authorized and the unauthorized case, so admin-only entry is demonstrated rather than trusted.
• Flow and status testing. Each action is verified end to end for its status change, its UI update and its SendGrid message.
• Data-accuracy testing. The summary cards and the checks table are compared to the seeded Firebase data so counts and rows match the source of truth, through pagination and larger datasets.
• Automation and regression. The suite runs in CI on every change, and test cases and bug reports keep the coverage traceable.

Verifying a data-heavy dashboard like this, where auth, state and email all have to stay in step, is exactly the ground our software QA and testing team covers when the goal is confidence on every release rather than a single passing demo.

Challenges Solved

Testing email without spamming anyone came down to mocking or sandboxing SendGrid and asserting the correct message, so every flow was verified with no real send. Testing against a live database safely meant the Firebase emulator with seeded data, giving realistic, repeatable runs that never touched production. Proving admin-only access meant testing the boundary from both the authorized and the unauthorized side, so the security line was demonstrated rather than assumed. Verifying every action meant end-to-end checks of each state change, UI update and email, so a passing test meant the whole behaviour worked. Keeping the numbers honest meant comparing the cards and the table to the seeded data, including across pagination. And catching regressions meant running the entire suite in CI on every change.

The through-line was that the riskiest parts were made safe first, then the important behaviours were proven on top. A dashboard that verifies people needs its own verification, and this pattern of gated access, audited status changes and matched counts is common across real estate and property management tools, where screening and approval workflows have to be trustworthy end to end.

The Result

Every important behaviour on the PetProov Dashboard is verified. Only admins get in, each action updates the right status and sends the right email, and the summary cards and table always match the underlying data, all proven safely and repeatably. Because the risky parts are tested without real sends or production risk, the dashboard can be shipped and changed with confidence, and a regression is caught in CI before it reaches a real admin or a real user.

If you are building an admin tool that leans on email, authentication and a live database, you can bring on back-end developers who have tested exactly this stack, or tell us about your dashboard and we will map out how to make its risky flows safe to test.

Frequently Asked Questions

How do you test email flows without sending real emails?

By mocking or sandboxing the email service. Here SendGrid is stubbed so that initiating, approving, rejecting and resending are all verified by asserting the correct message would be sent, and no real email ever leaves the system. That lets every flow be exercised fully without spamming a single user.

How do you test against a live database safely?

The tests run against the Firebase emulator seeded with known test data rather than the production database. That gives realistic, repeatable records to test on while keeping production untouched, so a test run can never corrupt real verification data.

How do you prove admin-only access?

By testing the role-based access boundary from both sides. The tests confirm that an admin can reach the dashboard and its actions and that an unauthenticated or non-admin user cannot, so the security boundary is demonstrated rather than taken on trust, which matters for a tool that handles verifications.

How do you make sure the summary cards and table are accurate?

The cards, total, low, medium, high and incomplete, and the checks table are tested against the seeded Firebase data, so their counts and rows always match the source, including across pagination and larger datasets. If the data-driven numbers ever drifted from the source, the tests would catch it.

Is the suite automated?

Yes. The whole suite runs in continuous integration on every change, so regressions are caught before release, and test cases and bug reports keep quality traceable as the dashboard evolves.