We have prepared a list of things that, in our opinion, must be checked out when trying a new feature. Most importantly, you need to validate that the newly added feature integrates well with the existing system. Most of the time, developers don’t know the entire product, as well as a QA, has investigated it. There will be a lot of edge case bugs if you do some boundary testing.

1. Acceptance testing, which simply means 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, which have to be tested for:

  • initial button state;
  • conditions for field availability ON or OFF;
  • min or max;
  • accepted characters;
  • requirements;
  • 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. Buttons testing – verified for conditions for field availability ON or OFF, negative and positive testing as well as error handling – fill out invalid data in one or more of the 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 in some fields non-standard characters by picking some from the UTF-8 catalog and 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, which must be thoroughly checked.

7. Navigation testing –  back and forth navigation;

  • Check if the data you populated the fields with still remains saved while browsing, or do 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 when certain things outside of it happen on the device.

  • 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.
  • You can uninstall the application and install it again and check its behavior or even 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 which 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 say, iOS and Android.

11. Compatibility testing – check for backwards or forwards compatibility with other versions of the product;

  • See how compatible is it with other platforms (e.g. iOS vs Android).

12. Test if the feature is working and showing up properly in all of the approved app languages.

  • Test any other regional settings – check if they are respected by the application.
  • Accessibility options should also be tested – see how does the app behaves with these.

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, think of how is the feature communicating 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 exact same as the one sent by the designers?

16. Component integration testing –  check out how does the feature integrates with existing sibling features; e.g. how does Login or SLA affect 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 is close to the limit, at the limit and above the existing limits.

Web-related testing and API testing – but not limited to the web.

  • Multiple browsers compatibility;
  • Windows resizing – the UI elements should still show up properly, no matter 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 that, if you tap a button multiple times, the request isn’t sent more than once.
  • Validate fields limits them 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

While these may not be all the things that a QA tester should take care of when testing a new feature, it can be a useful list for anyone trying to make sure nothing important has been skipped while performing quality assessments.