Our QA cheatsheet is a must-read before trying out a new feature.
Before we start, validate that the newly added feature integrates well with the existing system.
Most times, developers don’t know the entire product as well as a QA (who investigated it thoroughly). There will be a lot of edge case bugs if you do some boundary testing.
QA Cheatsheet for Testing a New Feature:
1. Acceptance testing – simply test if the feature works or not.
2. Functional aspects. Take each element of the app and compare it to the written functional specification – this is called validation.
3. Fields – have to be tested for:
- initial button state;
- conditions for field availability ON or OFF;
- min or max;
- accepted characters;
- backend validation vs. frontend validation;
- does an empty space count?
- behavior with characters that are not accepted;
- check how and if copy-paste works;
- microphone input.
4. Button testing:
- Verify conditions for field availability ON or OFF, negative and positive testing, as well as error handling
- Fill out invalid data in one or more fields and press a button to see how the app reacts.
5. Keyboard testing:
- Look at the initial keyboard state; check for a return or a done button, as expected.
- Predictive text function should work properly, except for the credentials fields, for example.
- Input non-standard characters by picking some from the UTF-8 catalog. Also, try to see how the app behaves with funky characters.
6. Testing duplicate data behavior, removal of data behavior, expired data behavior, and spelling mistakes (must be thoroughly checked).
7. Navigation testing – back and forth navigation.
- Check if the data you populated the fields with remains saved while browsing or if you have to repopulate it.
- If there are links within the feature, check to see if they are relevant.
8. Device integration – how the feature behaves with external factors.
- Check how the feature acts when you receive a call or a text message, Wi-Fi is suddenly disconnected, or the user is disconnected via 3rd party.
- Change the screen orientation and check the feature.
- Uninstall the application, reinstall it, and check its behavior. Also, try installing it with an older build existing side by side.
9. Cross-platform testing – test the feature on the accepted iOS and Android versions.
- Test the most common screen sizes. They can distort the UI in an erroneous way.
- Test the feature on devices with low performance.
- Devise some stress tests and see how the app behaves when you load up a bunch of other apps and throttle down the available device memory and CPU power.
10. Test the feature to be as user-friendly as possible.
- The feature must also respect the OS standard approach as it might differ between iOS and Android.
11. Compatibility testing – check for backwards or forwards compatibility with other versions of the product.
- See how compatible it is with other platforms (e.g., iOS vs. Android).
12. Test if the feature is working and showing up properly in all approved app languages.
- Test any other regional settings – check if they are respected by the application.
- Accessibility options should also be tested – see how the app behaves.
13. Security testing. Check for vulnerabilities within the application and information possibly being leaked to other destinations.
14. Sync testing – check when the local data gets synced to the server.
- Use a network throttle tool to check the functionality on different bandwidths. When testing the sync function, check how the feature communicates with the cloud.
- Try to perform test syncs while dropping the Wi-Fi before, in the middle, and after the connection is processed to the cloud.
- Using the same account, try to perform changes using multiple devices.
15. Design testing – Is the implemented UI the same as the one sent by the designers?
16. Component integration testing – check out how the feature integrates with existing sibling features; e.g., how Login or SLA affects the feature.
- Check using valid and invalid data.
17. Performance testing, load testing, and levels of stress testing.
- Use scripts to reach the specification limit and closely monitor the app when it’s close to the limit, at the limit, and above the existing limits.
Web-related testing and API testing:
*Not limited to the web.
- Multiple browsers compatibility.
- Windows resizing – the UI elements should still show up properly, regardless of the differences between screen sizes.
- Try logging in on the same account on multiple tabs and doing contradictory edits to the same data object (e.g., patient data).
- Check if the selected data in the UI is the one that is actually sent to the server once the Send button is clicked.
- Make sure the request isn’t sent more than once if you tap a button multiple times.
- Validate field limits and see if the same limit exists on both the server and client sides.
- Check the error status handling on the client by faking bad data and modifying the requests received from the server-side (using Charles, for example).
- Block API requests using Chrome – see how the client handles a blocked request.
- Edit API request payload using Charles – see how the client or server behaves with unexpected data.
We hope this list is useful to anyone trying to make sure nothing important was skipped while performing quality assessments.
Schedule a meeting if you want to know more about our QA services: