Mobile applications need to be updated for many reasons. It’s common for an initial release of a new app to contain bugs that weren’t caught in sandbox and developer environments, for example, or for a misunderstanding of workflow to pass through the UAT stage unnoticed.
Beyond this, once an app is live and mature, it will still need to evolve in line with many factors including (but not limited to): new business requirements, regulatory updates, alignment with new OS and hardware capabilities, and of course in our world modifications to support new Salesforce releases.
Whenever Salesforce patches make their way into pre-release orgs our daily test runs kick off and identify the change. These tests run on 15+ org setups and report back any issues that might have been observed. One such observation was reported back during the early days of Summer ‘17 patch rollouts into pre-release. The issue manifested itself initially as the inability to complete the authentication flow on iOS devices built with Salesforce Mobile SDK v4.0.2 and lower.
During the investigations into the issue, we raised a notification on our trust site to keep our partners and customers aware of the risk of the behaviour. We also developed some internal work-arounds. If the issue wasn’t fixed prior to Summer ‘17 making it’s way into our partners’ sandboxes, these would let us unblock them from their development and testing processes.
We also discovered that the bug broke the vanilla experience of browsing standard Visualforce pages on iOS Safari; this could be bad if it got through into production.
What is a Salesforce community?
A Salesforce community is an online platform for organisations to connect employees, partners, and customers, while providing seamless access to the data and records they need to get work done or complete tasks.
Built on the Salesforce Community Cloud, they offer real-time engagement and the ability to share any file, data, or record anytime and from anywhere.
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.
One of the most exciting things about our Application Delivery Framework (ADF) is that it’s constantly growing and evolving, to allow our partners and customers to push the boundaries of what can be achieved with mobile apps on the Salesforce platform. As such, it’s vital that we help our community stay abreast of all the new MobileCaddy features and updates as they’re released.
With that in mind, I’ve decided to record and publish my regular discussions with Paul, our CTO, Todd, our Chief Mobile Technical Architect, and Frank, our Lead Product Engineer. In these sessions we’ll be covering what’s new with MobileCaddy, and will be sharing this with you to provide a first-hand look at everything we’ve been working hard on to improve.