3

I need to check a few feature like:

  1. Supported Browsers for Lightning Experience Supported Browsers for Salesforce Classic

  2. Rich-Text Editors Disabled When LockerService Critical Update Is Active

  3. Create Shortcuts to Your Top Salesforce Pages with Favorites

  4. etc.

How can I check in my sandbox how these features affect to my existing code or any other process in my org?

4

Beyond the Hammer Test results mentioned by Adrian, which is basically running your Apex test cases before and after the release, you will need to have a separate process for evaluating each change or new feature made in a seasonal release.

For example: Create Shortcuts to Your Top Salesforce Pages with Favorites

This is specific to Lightning Experience and the general navigation. Between that and being a new feature your Apex test cases are unlikely to even consider it (if at all for UI features).

So, in summary, your Apex test cases will give you some indication is anything has affected you code. There could still be side effects that you just can't test for.

The only way to know with reasonable certainty is to run through all the required parts of your app manually. You might be able to automate some of the UI intereactions to test everything. You would need to make the call if the effort to do that is worth the benefit.

  • Hi Ballinger, So do I need to check in all version of supported browsers? Since it supporting Microsoft® Internet Explorer® version 9, 10, and 11, Apple® Safari® version 8.x, 9.x, and 10.x on Mac OS X, and Microsoft® Edge for Windows® 10. for supported browser Feature in Spring17 – user24737 Jan 23 '17 at 14:14
  • 1
    @chris you need to make the call about what is important to ensure full compatibility with against your org. Generally speaking, everything should just keep working from release to release. In practice there are always exceptions. Unfortunately there isn't an easy answer as every org is different and every release can have such a broad range of changes. – Daniel Ballinger Jan 23 '17 at 21:28
3

It sounds to some extent like your looking for Hammer Testing:

Every release, there is a period of time between our internal release freeze and the sandbox release. I like to think of this time as Hammertime. When it’s Hammertime, we do a lot of work to make sure we have not introduced regressions between releases.

In this window, we run a process we call “The Hammer”. The Hammer means taking every single Apex test that you or anyone else has created and running it twice. We run the test once in the existing version of our service – the one you’re using today in production – and once in the release candidate version of the service. We compare the results to identify any unexpected functionality changes between releases.

The next time you are wondering, “why do they make us have code coverage if they don’t force us to have assertions in the tests,” you now have your answer! Even if your tests don’t follow good practice and do not actually test things, just running the code in your tests allows us to perform our hammer tests.

Apex is not alone in running hammer tests. Visualforce, packaging, Trialforce, and dashboards all go through a similar process. The Apex process is the most involved, but the general principle of finding potential issues before you do is applied to all of these.

Viewing these results has been Generally Available since Winter 16.

  • So are you saying the we should not need to do our own testing? The hammer execution status says "The Apex Hammer process picks orgs selectively and doesn’t run in all orgs while the Hammer testing document says differently The Hammer means taking every single Apex test that you or anyone else has created and running it twice so is it all or some? Also, the execution results do not provide any detail. In an org I checked it showed 53.63% and 1497/1777 but does not provide any additional detail on what failed. I am assuming the 53.63% meant there were failures... – Eric Jan 22 '17 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy