Automated Salesforce Testing – Top 6 issues tackled.

  April 15, 2014       Pierre Positiveur

Thinking about options to automate your Salesforce testing? Here’s our top 6 pointers to help you along the way to ensuring you can save time and money with a better testing solution.

  • Only testing via the UI is slow to execute and painful to maintain

For standard Salesforce screens each field, button and page needs to be mapped and maintained with each release. UI tests are notoriously difficult to maintain and very slow to execute. Alternatively it is possible to execute all the triggers, validation rules and custom logic for each of your objects using API tests. API tests include Create, Update, Delete to manipulate your Salesforce objects and Read to assert your results. The API are easier to maintain and quick to execute. Create your set-up (seed) data using API tests and only create UI tests where they are needed.

  • GUI tests don’t work when switching test environments

Automated tests need to work in all your test environments without being updated when running in a different environment. Field Locators are how your automated tests, find the field or button on a page. There is an issue creating field locators for the Salesforce screens as some field Ids differ between Orgs. You will need to anchor these fields to a label, but this can become complicated and will not work for multiple languages.

  • Testing Visualforce pages is difficult

The issue lies in creating field locators reliably on a page. Salesforce will generate the Ids at runtime which means any change to your APEX code leads to the field locators based on Ids to need constant maintenance. You can either anchor against labels or ensure the developers uniquely name every tag on their page.

  • Testing is being done by developers

It is common with Salesforce projects to create an in-house framework based on the open source product Selenium. There are many hidden costs in this approach and it will require an investment in developers to create and maintain a framework. An automated test engineer capable of creating a robust, scalable and re-usable framework is an expensive specialist skill and each new feature such as reporting, integrating with Continuous Integration, loading data from different sources, testing upstream/downstream applications needs to be developed. Any non-technical testers are resigned to manual testing.

  • Duplicating the Salesforce fields in your tests is inefficient

If left unchecked an automated framework and testcases can exceed the lines of code in your Salesforce implementation. You will need to repeat the Salesforce object, field, picklist and report definitions in your testcases and tests need to be updated in multiple tests when object definitions are modified.

  • System Integration Testing is still largely manual

As your automated testing becomes more mature there are great efficiencies to be gained at the system Integration test layer. Your automated testing needs to support asserting your neighbouring systems, inbound/outbound emails, databases, web services and messaging systems. Automation at this layer helps convince business users that their end to end scenarios are understood and executed before sign-off. This is usually manual on Salesforce projects.

  • Welcome to Provar

Provar is a testing application, designed for Salesforce. It is has a number of rich features which solve the issues described in this blog. It combines API and UI testing and tests complex Visualforce pages with a point-and-click Page Object editor. It can perform end to end testing and also fulfil your own bespoke testing needs. Attend our next webinar if you would like to see a demo.