7 Best Practices To Help You Build Better Mobile Apps
Engineering
© 2024 Gleap GmbH. All rights reserved.
Whether you’re a developer who wants to test their builds more extensively or a tester who’s looking to bring more structure into their process – having an organized approach in how you engage with testing for bugs will not only calm your nerves but also yield measurable improvements, i.e. more bugs. It’s certainly possible to write dozens of blogs about different types of bugs in different frameworks categorized by different behavior. However, we don’t want to get lost in the details here. For now, we’ll just look into some approaches on how to efficiently group bugs so we can get at least some sort of structure into our testing process.
In theory, most of your interface elements exist to serve a certain purpose. This purpose can take various forms, but let’s focus on active and passive interaction for now. Active elements are for the user to interact with – a text field, a button, you get the idea. Passive elements are (you guessed it) perceived passively without active engagement, like colors and text fonts. Where am I going with this? Glad you asked.
Active elements, contrary to passive elements, have a singular specific purpose or function (most of the time anyway). The user also has a specific expectation as to what should happen when they engage with these elements. Breaking these expectations is confusing for the user to say the least and should be avoided at all cost.
However, you also have to think a bit further than purely active elements. For example, entering my login credentials into an app but ending up logged into a different account than mine would also fall under “functional bugs”. So, make sure to include any process which the user doesn’t necessarily have control over.
As the name might suggest, this type is purely about issues that occur when the user tries to navigate through the menu or more generally any interface that is serving a purpose of navigation. Please note that just because e.g. the login button is part of an interface, it might not make sense to categorize every single bug regarding this button as UI bugs. If the login button opens the system settings for example, it makes more sense to add this bug to the functional bugs.
If you let users enter data into your software which they shouldn’t, bad things are typically bound to happen. The perhaps most famous bug of this kind occurred when NASA lost its Mars Climate Orbiter after it entered Mars’ orbit at a much lower altitude than it was intended to. The cause of this failure was a software bug which used US customary units instead of SI units to calculate “impulses produced by thruster firings”. The good thing about making slightly embarrassing mistakes like this one public is that everyone can collectively learn from them without going through the consequences (in this case $327.6 million).
The approach on how to test for input errors is entirely up to you, but if you want some inspiration on how to get started, I’d like to refer to Rosie Hamilton’s blog post about “Data Mocking”. While you certainly don’t have to go to the lengths  described in her post, you can look for first steps to testing input data.
Ever had the pleasure of your internet connection suddenly dropping while you were in a zoom meeting? Or maybe you were trying to listen to music on your device while having a gazillion apps open? While some device system related circumstances like an internet disruption, may not be necessarily your top priority when developing, it can certainly lead to strange bug behavior. Reasons like these make testing for edge cases useful.
I’m not saying you need to rewrite your entire code just so there is a workaround when the user’s bandwidth or memory availability dips slightly. However, being aware of high severity bugs like a complete freeze or infinite loops because of system bugs shouldn’t be overlooked.
So, the client wants the buttons on page X to be this exact shade of scarlet red, and you get the feeling they’re the kind of client that cares about colors a lot. But are you going to use all the predefined colors when building the basic component structure? Probably not. Will the client get slightly upset when you forget to change some of the colors before sending them a build to test it out? Probably yes.
To prevent these kinds of errors you can group visual errors like incorrect colors, layout, margins, scaling and font families into the category “visual bugs” and extensively test for them. Testing for these is most important towards the end of the project, but if client satisfaction is something you take to heart you might want to do them for test builds as well.