It’s common to focus on functional requirements and usability when testing an application, areas which are often where most of the effort is spent once an app has moved into the testing, QA, and UAT phases of a project.
Before even thinking about any functional app code, though, it’s important to test all the app’s non-functional elements first. If those aren’t prioritised, not only will it have a knock-on effect on all other testing, it will also impact the app’s ability to function once deployed.
Defining, and clearly understanding, non-functional testing processes is the key to releasing a defect-free mobile app into production. When separated into two groups, these can be referred to as ‘initial’ non-functional tests, and ‘running app’ non-functional tests. But before we go into more detail, it’s necessary to understand why non-functional testing is unique for mobile.
Code deployment validation
With the MobileCaddy Application Delivery Framework (ADF), code deployment is made simple from a developer’s perspective, thanks to the CodeFlow development environment. CodeFlow enables one-button deployment, from the developer’s local environment up to the Salesforce platform. This bundles up the application logic, UI, and much more into one simple flow.
Following this, an extremely important step in the testing is to ensure that code has deployed successfully. By using the MobileCaddy Platform Emulator, along with the browser’s development console, developers can validate the code immediately after it’s been deployed. This is beneficial because a partially failed deployment, or missing assets, will be picked up for correction before any QA or UAT processes begin.
You’ll always need capable, competent people to build a mobile app which can add value to an organisation beyond the obvious improvements to basic worker productivity. That’s why finding a solution which allows the people you already have to rely on their existing skills and focus on delivering that app, rather than working on tedious, time-consuming development, is so important.
With the MobileCaddy Application Delivery Framework, developers can quickly and easily build these more advanced mobile apps using a familiar set of skills, as the solution removes the need for specialist development, and provides helpful guidance across all stages of the project.
Here, we’ll answer key questions our partners and clients ask us about the skills needed to begin a mobile project on the Salesforce platform using the MobileCaddy Application Delivery Framework.
The benefits of using the Salesforce platform to develop enterprise mobile apps are extensive, but there simply aren’t anywhere near as many enterprises doing so as you might expect. The reason for this is, in many cases, that it’s simply too challenging, too costly, or the expertise just aren’t available.
However, there are solutions within the global Salesforce ecosystem designed specifically to ease the pain of mobile app development for both end customers and consultancy firms alike. Once these inherent challenges are removed, the advantages of having mobile applications supporting business critical processes move into focus. These positives vastly outweigh the negatives, making those complementary partner solutions well worth searching for.
One of those negatives is the time mobile app development projects can take when approached without the necessary tools or understanding. Looking specifically into the need to accelerate the development process for those tasked with actually building mobile apps, we’ve highlighted five advantages the MobileCaddy package offers:
Visibility is key. When building, testing, and beyond into production, just having insight into what is going on with mobile users who may be thousand of miles away in different time zones, or developers working under pressure to strict deadlines, understanding the actual data which is being processed can be a lifesaver.
For every user/device (or emulated ‘devices’ for developers or testers using a CodeFlow Emulator or a Platform Emulator), you can see exactly what data was requested by each synchronisation, either at a table-by-table or record-by-record level.
To do this, navigate to the Connection Session tab and locate the Connection Session record which pertains to your user/device and for the Mobile Table you want to inspect.