Best practices - Test recommendations for devs
Guidance for devs on how to test their Bubble.io application.
When we build an application, part of the process as developers is to test that everything works correctly before handing it over to QA for evaluation.
This is often left to the last minute and is done without following a straightforward process to help us locate problems before delivery.
There are best practices for performing these tests that can help us deliver consistently excellent work every time.
To help developers reduce the number of bugs in their applications by providing them with guidelines so that they can structure and optimize their testing process.
First of all: have a checklist of the requested functionalities and verify that you have added all of them and that they are working correctly.
This checklist should be checked before each delivery to ensure that we have not forgotten any functionality.
The Features table in the scope doc has a Status column that you can update with the build status. This can be a useful checklist too.
One big problem with tests done by the same developer who built the app is that the developer "knows" what the user should do, so all the test steps are linear and always done in a way that matches what the developer has planned that the user "should" do.
The solution to this is to change your mindset when you test. You must forget what you know about the app and stress it as much as possible.
For example:
- Don’t open a form, fill it in and press “Send”/”Create”. Instead, open the form and press “Send”/”Create” without having entered any data and see what happens. Try to anticipate any possible non-standard user behavior.
- Abandon a form midway through it and see what happens when you return to it.
For example:
- Negative values where they should be positive
- Text where it should be a number
- Empty fields where there should always be a value
- More than 100% where it’s a percentage
- Very large or very small values
Think: What could go wrong? What could the user enter incorrectly here?
Testing with real data provides a more accurate representation of how the app will perform in the real world.
Not only can it help you detect bugs in the application, but when the customer tests the application, it will look similar to how it would in a real environment, providing a better image and customer satisfaction.
For example:
- Check how an app will treat a longer profile description instead of just entering “Test”
- Check how the app calculation will treat a product price with cents ($9.99) or thousands ($1,000)
- Upload a data file similar to what an actual user might upload
Are there mathematical operations in your app?
- 1.
- 2.Enter the same values in the spreadsheet and in the app.
- 3.Compare the results of your app with those of the spreadsheet.
The calculations in the spreadsheet will not be dynamic as in the application, which allows you to build it quickly, but nevertheless with accurate results that will allow you to check the results of the application.
Is there any data on your application that the user shouldn’t be able to edit? This won’t be always specified on the scope, so try to think of common behavior.
This need will appear frequently in: stored reports, invoices, notes, etc.
For example, if your application generates invoices and provides the means to pay them, make sure that:
- 1.The data of a paid invoice cannot be edited.
- 2.Changes in other parts of the app don’t affect issued invoices. For example, the company name on an issued invoice shouldn’t change even though the name of the company changes in the future. (Same for the other fields on the invoice)
Always make sure that you have entered all the needed data on your database (test, live, or both).
For example, a common oversight is that:
- 1.You have created new variables (or other data type that needs to have some value) in version-test
- 2.You deploy the app to live not having to deploy the database (imagine it’s not the first time you deploy the app, so you don’t have to copy the database from test to live)
- 3.You forget to populate the values in the live-database
- Are all the data types correctly protected?
- Are all the data types visible when they need to be visible?
- Are all records visible to their creators?
- Are all records visible to the App Admin? (not always needed)
- Have you added new fields to some data types after setting up your privacy rules? They will be hidden by default, so make sure that they are visible where needed
A bug fix or an enhancement may result in a new bug. It is important to retest the existing flow that is related to the updates to find out if there are other consequences of changes.
Sometimes, additions or improvements in the application generate problems in what has already been built that are difficult to foresee. Testing previous flows is often the only way to detect them.
For example:
- A bug fix is implemented to fix multiple-day service booking. You tested that multiple-day service booking is now working, but you should also check if the one-day service booking is still working.
One last tip: don't leave testing to the last minute. Testing during building will help reduce errors to a minimum.
Also, detecting a bug at an early stage of development will save us work in fixing it, as dragging it can affect many more parts of the build.
Happy bubbling!
Last modified 1mo ago