Disruptive Test Automation for Salesforce Applications
This article talks about the power of Test automation for Salesforce Applications , the real ROI and the goal of a strong regression test suites being available for an application .
How many times does a user story that is scoped for a particular release be tested in its life cycle. Atleast once in each of the 6 phases – Development , Integration , QA , UAT , Staging and Production . Its fair to assume that the application needs to be tested on atleast two browsers [ I am very conservative J ] . And the scenario may need to be tested for 3 different data sets [ be it with a different role , with different approval process flow or work flow or a different pick list value ] –
The Test effort will end up as this for quality and predictability .
6 release phases * 2 browsers * 3 data sets = 36 testing combinations
Did I mention about the maintenance of this user story after release – due to some hot fixes / any customizations ? – Assuming a decent development effort – its fair to say 2 defects in the quarter . [ I already said I am an optimistic and conservative fellow J ]
So, does it mean the 36 testing combinations need to be tested for these two defects , all over again ?
Not a happy thing to do , but it must be done considering the impact of how much a bad fix can impact a business . Especially , if it is a Salesforce application , its all numbers. Any bad fix in production can result in great errors in the piplelines , profits and goals .
Based on the above number A hot fix that is addressing a critical issue and should go to production asap will need extra 6 man-hours just in testing itself [ Assuming it takes 10 mins for a tester to understand the scenario, login to Sandboxes , prepare the test data , run the test cases and prepare the result report ] . I am not talking about the communication overlays between various test teams , release teams about sharing the defect details, test kick-offs , escalating new issues and test closure. Add this time, and it means that in addition to the analysis and development effort , the hot fix is delayed by 1 full day in getting released to production .
While , the above testing effort , I am sure is accepted in any medium / large sized Organizations and automating the test scenarios can help set up a strong regression platform for the application to survive such scares and brings scalability to the development and testing teams – Salesforce test automation is still a distant reality .
The top-3 reasons that are deterrent for Salesforce Test Automation as per our surveys in various Salesforce Meet-ups , interactions with various clients are cited here :
- It needs specialist Automation Team Members who write scripts and they need to be maintained .
- With every release , with every change that is done , the scripts also need to be updated.
- Over a period of time , the test scripts become as complex as code and we may not have the same people to maintain them .
With AutoRABIT , aimed at streamlined Salesforce Release Management and Continuous Delivery for Salesforce Applications – the days can just be better .
One of the most appreciated components in AutoRABIT Salesforce Release Management suite is Test Automation Factory which has a curing engine for Selenium recorder to enable business analysts / test teams generate automated test cases with an effort that takes to test your user story just once.
The Salesforce Test Automation Factory in AutoRABIT also has a data transformation component that separates test script logic and data so that you can change your data sets or release environments and with just one click you have all the test cases generated for all your data combinations .
Am I talking of 36X savings in your test effort ? . Yes, It’s a reality with Salesforce Test Automation Factory component in AutoRABIT .
Salesforce Test Automation has become disruptive. Try it , experience it and Believe it .