QA for Bolt apps
A customer submits a request in your Bolt app. They need to know it was received, find it later, and get a useful answer if submission fails. Those are the steps we follow in a review.
VibeAssure reviews the tasks you want customers to complete. Get a report of what we tried, what worked, and the problems we found, with reproduction steps and priorities for fixes.
What to test in your Bolt app
Bolt Cloud provides hosting and database features. When your app uses them, include the published URL and the records created through it in your checks. Bolt documentation.
For an app that collects requests, follow one submission into the customer's history and the team's review screen. Leave a required field blank, correct it, and try again. Check repeat clicks and retries too: the customer should be able to tell whether the request arrived and whether another attempt is needed.
- Does correcting a form error preserve the answers already entered?
- Does one submission create one request in both people's views?
- Can the customer find the request and its status on a later visit?
These checks and the example below are starting points for choosing your scope. We agree the tasks, platform, and build before testing starts.
Walk through a customer task
Submit a request and check its status later
A customer wants the team to receive one complete request and keep them informed about its progress.
- Where the customer starts
- A customer test account with an empty request history and a reviewer account.
- What a successful result looks like
- The customer submits once. One request appears in their history and the reviewer's queue, with a matching status.
Cases to try
- Leave a required field blank, then correct it.
- Click submit twice while the first attempt is still loading.
- Return to the form after an unclear response and try again.
Problems to look for
- The form clears all answers after a validation error.
- Two clicks create two requests for the same submission.
- The customer sees a confirmation, but the reviewer has no request.
Test accounts: Customer, Request reviewer.
Services used in this example
- Request storage
- Notification email, if the app sends one
What a finding looks like
This hypothetical example shows how a problem is described in the report. Your review records what we observe in your app, how to repeat it, and which findings to address first.
Two clicks create two requests
Steps to repeat the problem
- Fill in the request form with the customer test account.
- Click submit again while the first attempt is still loading.
- Open the customer's history and the reviewer's queue.
What happens
Two requests with the same details appear in both lists. The form gives no indication that the second click created another request.
Why it matters
The team has two items to handle for one customer request and must work out whether the duplicate was intentional.
A finding with the field values, click sequence, and resulting requests gives Bolt or your developer a specific problem to investigate. It also gives you a way to repeat the check after making a change.
Other tasks to include in your scope
- Edit a submitted request.
- Receive an email after the reviewer changes the status.
- Withdraw a request and check both lists.
What to bring to the review
- Share the published URL and identify the form or request process to review.
- Provide a customer test account and access to the screen where the team receives requests.
- Tell us whether submission should send an email and which test inbox can receive it.
We usually need an app link or build and authorized test accounts. You or your developer make the fixes using the report. A retest after changes can be quoted separately.
Plan your app review
Tell us what your Bolt app does and which tasks matter most. In a 15-minute call, we’ll confirm the scope, access, price, and delivery timeline.