Delivering a crash free app
Quality assurance of any app is one of the important reasons of its success. Quality Assurance not only covers the testing aspect of the product but also the overall impact your product is making. A successful app is always appreciated by users, however a lot of effort is put behind it to make it seamless and bug free.
The primary concern of a QA is to ensure that the app runs crashfree on different devices. There are multiple reasons of app crash/ANR. I’m listing some of them and QA approach to find them
Your app may run well in OnePlus phone but not in Samsung Duos because both devices are different in terms of CPU speed and processing power. That doesn’t mean that newer and faster devices guarantee crash free apps. If your app takes more than 5–6 seconds to launch or switch from one activity to another, it will result in ANR/crash .
- Test your app in low end phones with limited memory
- Try to cover all android versions in testing
- Test when multiple apps are running in background
- Switch from one screen to another when some downloading/processing is happening on first screen.
- Move your app to SD card and test
Second reason why apps crash is due to network connectivity. We often notice that apps work perfectly when device is connected to WiFi but as soon as you switch to 2G or no internet, apps start to crash or behave randomly. A change in networks, going into and out of elevators, or losing reception can result in lost or scrambled packets
This is a very important aspect while testing your app.
- Test your app in offline mode (end to end testing)
- Switch from WiFi to 2G to no internet while testing your app
- Test network blip scenario when app is downloading data from server
Developers : It’s a good practice to notify users of network connectivity issue. In this way users will blame the crash/ANR on network and not your app.
A good quality app should work reliably irrespective of network.
Another reason of app crash is poor coding. Developers often miss integration scenarios and do not handle null pointer exceptions. Finding such crashes is tough for a QA.
- Client + server integration — e.g missing conditions on JSON data
- Adding new implementation in an already developed feature and not considering all cases
- Adding an element in XML layout and not creating its reference
- Poor naming conventions leading to logical errors
- Type mismatch issue while dynamically setting margins, padding in views
- API started providing numeric value instead of text.
- Resource not found at run time
- Verify all layouts in different screen sizes.
- Test for all negative cases
- Write unit test cases for code verification
- Write Automation suite for app regression testing
Top 5 crashes and how to avoid them
The top location for Null pointer exceptions is the Android onResume() method. When the app goes to the background, it may have to get rid of some memory, losing various references along the way. To avoid this, save your data from the onPause() method into a more persistent layer like a local database or cache, then pull it back out within onResume().
Be sure to recycle objects like bitmaps as soon as you can. Always make sure you are adhering to proper memory standards
Save your instance state and reset the context references on any changes that change the state.
Avoid forgetting to add an Activity to the Manifest,Loading UI elements directly from a background thread, trying to use a recycled bitmap
Always use the provided database helper to create, open and upgrade the database.Use a single SQLite connection to avoid race conditions or scenarios where relational data is dependent on other data that may have been changed, modified or not inserted yet
Apart from the QA approach mentioned in above crash scenarios, here are some tips for finding bugs in an android app
Test for Boundary values
Always test boundary values of all input conditions. Developers often do simple mistake of writing “less than” zero instead of “less than or equals to” zero.
Test for negative scenarios
While developing an app, developers do not consider negative scenarios. Like if a user presses back button on a screen.
Test your app in Landscape mode
You’ll get UI bugs while testing app in landscape mode
Test app integration with third party apps
When third party app updates, your app might crash in integration flow.
E.g your app might be integrated with FB’s old version, and will not work with its updated version.
Test for time zone mismatch
This will give server integration bugs. If API is not implemented to handle timezone mismatch.
Test App Localization
If code is hardcoded to use some specific string, it will fail in localization testing.
Analytics driven testing
Check your user base and test on same devices.
Never trust Developers
Never trust if developers say new implementation won’t affect existing features. Always do sanity testing even if there is minor change in code. We can never be sure of the ripple effect of code.
A Digital future cannot come at the cost of quality. Overlooking quality of any app will lead to its uninstall. Even if the code is perfectly optimized it doesn’t mean app works in a way that user expects.