Functional testing is conducted as the primary activity, to ensure that the application, be it Native app, Mobile Web app or Hybrid app operating on Android, iOS or Blackberry, etc. meets all the specified requirements, all its features are responsive, and serves the end-user as expected. Identifying who are the target end-users and which purpose does the application serve is a prerequisite for any type of app testing.
Here are three main focus areas that should be checked and kept in mind. Always check your project-specific requirements on what type of bugs are expected and what is out of scope, not all the categories listed here will apply for all projects.
1) The main functionality of the apps
What to check?
- Identify functions that the app is expected to perform. Usually, you have a test case designed for that.
- Check the mindmap to build a better understanding of features and their potential relations.
- Understand the most business-critical features and make sure to keep them in mind throughout the testing.
- Check the help of the application to build a better understanding of how the features are expected to work.
- Check different heuristics like FEW HICCUPPS to remind yourself of critical aspects.
- When checking fields, mind doing a boundary value analysis. However, keep in mind real-life use-cases.
- Make sure there are no navigation issues
- Verify how the application behaves on backgrounding and resuming. Cold start (app not running) and warm start (app running on backgrounds) can produce different results.
- Check if the sharing feature through the application is working.
- Verify all the modes of payment transactions that the application supports.
- Think about particular platform-specific features.
Example: If it is a desktop application, how does it behave on minimizing, maximizing, full screen, etc.
Make sure to read through all the texts presented in the application
- Sometimes simple errors in grammar can be easily overlooked.
2) Real-life scenarios
What to keep in mind?
- Put yourself into a real-life scenario where the end-user might be in.
- Think of the end-to-end scenarios and paths the user can take when using the app
- Make sure that the end-user can continue its actions when the application receives an interruption.
- Check the offline/airplane mode behavior in different features.
- Check if the mobile device is able to send, receive, and store the content of other applications while the application is being run.
- Check the application behavior on the different combinations of carriers: 2G, 3G, 4G, and in general low-network conditions.
- Think about the environment where the application is being used
- Is the user switching between networks or online/offline mode
- Does the user need to often rotate the device to get a better view of the content
- Is the application used in different regions?
- How does it behave with different locale settings?
- Is the application meant to be used with different accessories?
Example: What happens if you plug in your headphones while the application is playing a video?
3) Avoid thinking too out of the box
As stated in the beginning, always check your project guide, since a particular customer might exclude some types of bugs as not priority ones for them. Whenever experiencing an error scenario, ask yourself the golden question - Why this issue should be fixed? I.e. Why should the customer spend money and time on fixing this bug?
The list of closed and not approved issues (bugs) is always helpful to understand the patterns in issues (bugs) that are not valued in a particular project.
What to keep in mind?
- What is the likelihood of this action to be made or experienced for the end-user of this application
Example: A situation where the tester is pressing two buttons at the same time - This is not an action the majority of users would do, and should not be listed as an issue or a bug.
- Comparing the functions of the application with other similar applications is a valid idea. Although, keep in mind that application under test still has to remain unique and it might be an intended design to change some common use-case
- Do not write feature requests instead of bugs. The application has been designed with some intent in mind and implementing a new feature is not something that can be easily done.