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.
Why bother with Proof of Concepts?
PoC applications are pivotal to any mobile app proposal, allowing the demonstration of fundamental concepts and principles. Including a PoC as part of a pitch is a great way to put something tangible literally in the hands of the decision makers. It’s an opportunity to reaffirm confidence to key stakeholders, particularly where critical technical requirements come into play.
“The Proof of Concept system gives stakeholders a chance to understand the capabilities and limitations of the system.” - Anderson IT
A common scenario we’ve come across at MobileCaddy is the desire of our partners to reassure clients that fully network resilient mobile apps for Salesforce are possible. This example is also applicable to internal development teams working in larger organisations.
Our experience with offline-first architecture has proven this to be a grave concern for enterprises. As such, a PoC demonstrating exactly this functionality has been fundamental in progressing conversations beyond these sticking points, and further onto the real topic of how value can be gained from taking Salesforce operations mobile.
An overview of Salesforce releases
Three times per year, a major Salesforce release occurs which introduces updates to its software. These releases happen automatically and affect everyone within the ecosystem, including regular customers and ISV partners with related solutions such as MobileCaddy.
These spring, summer, and winter releases are planned months in advance and are kept on a very precise schedule to allow for as much preparation as possible. The release cycle is made available to everyone, and Salesforce administrators are alerted via Salesforce’s own email alerts for admins.
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.
Operating and supporting any enterprise application in the context of mobile is challenging, because you don’t have control over that app’s underlying operating systems, nor can you predict new updates, upgrades, or patches being released.
This presents a problem for those responsible, because changes to an OS can cause mobile apps to suffer in their performance, or even stop working entirely. When those apps have been deployed into functions which are critical to the daily running of the business, that effectively renders the employees or community users relying on the app incapable as well, which simply can’t be allowed to happen.
So, firstly… Understand your app
You need to be aware of all the various components which make up your application, how they interact with each other, and what relationship they have with the OS.
Any number of things within your app can change without your knowledge, and the various elements and supported systems mean that continual testing is an absolute necessity to avoid app failure. This becomes even more important when applications are supporting business critical processes and workflows.