Testing Salesforce and other core Applications

Any large application you have that was “not made here” will present a different testing challenge and focus from those developed in house.  Probably, one of the main reasons for acquiring preexisting technology is to avoid the time and cost associated with building rather than buying or consuming.  It may be also that the leading-edge functionality available exceeds that you would reasonably built for yourself. The combination of these factors is reflected in the licence, maintenance and subscription costs of these business critical applications. 

multiple choice tick char with pen

Responsibility for Testing

Without the intrinsic knowledge of how the system has been constructed from the ground up, the responsibility for testing of any changes and integrations falls either directly on the users, a group representing and supporting the users, or frequently a combination.  The focus of testing becomes process, capability and output from an end to end, cross system perspective.

There is often a mixed attitude from IT teams to this situation which can vary from IT teams doing some testing, to IT doing zero testing and leaving the responsibility solely with the real users – “After all, it is the users’ system; that is why we dropped the legacy system at great expense. They should test it, we just provide the platform!”

Testing pain

 

Corporately, what is required is a system that works reliably, empowers users and supports the future. These were the key tenets of the business case supporting the large investment at the time of purchase. Those that have this viewpoint can often then forget or ignore the reality that despite having purchased this expensive top of the range solution, there will be on-going changes, integrations, patches, enhancements and upgrades to contend with.  All of which will need to be tested if the high-level goals of reliability, empowerment and future support are to be continually achieved.

The result is many man hours of business users, or subject matter experts involved in manual testing.  Why manual testing? Because almost all of the automated testing tools in the market are not designed with this type of user, or this type of process, in mind. They are technical, programmatic, complex and flaky in an environment where change is outside of your control. 

Cloud applications, and Salesforce is a classic example of this, exacerbate this with frequent invisible technical changes which do not massively impact a user’s ability to adapt to the change, but easily break most automation solutions.

process ring graphic
businesswoman sitting at laptop

Change-friendly automation

Original Software has created a suite of products designed to support this process and when it comes to automation, a solution that does not rely on programming, which can be widely used by people with no programming skills. It has patented technology to adapt to change in the same way a user does.  TestDrive it a key part of an integrated suite of products which manage IT tasks, QA testing, User Acceptance Testing, resources, business process capture, manual testing, automated testing and creation of training materials with a simple goal – ensure that application changes do not adversely affect business operations and can be rolled out as quickly and painlessly as possible. 

The end result is a change project that has been delivered more rapidly, with less effort and cost, and most importantly with maximised quality avoiding expensive business interruption.

Test automation success at Edrington

Hear Alistair Norrie, Business Technology Programme Manager share in three minutes how Edrington successfully automated their testing processes, enabling a modernisation that effected more change in twelve months than had taken place in the previous ten to twenty years.

How We Help

What Next

Related Articles