Salesforce Functional Testing Part 1: PROCESS & TEAM DYNAMICS
Looking back at 3 years of functional Salesforce testing, Dimitri would like to share his experience in a series of blogs and hopefully prevent you from making the same mistakes & assumptions he did.
It was early 2014 and I got hired as an agile tester in a project that was implementing Salesforce on a global scale. Back then I didn’t know anything about Salesforce, but I knew a lot about testing (close to 10 years’ experience).
As usual I started off with some google queries on best practises, tips ‘n tricks and other helpful info on how to test Salesforce, but I found surprisingly little. That’s little when it comes to functional testing, since the Apex Developer Guide is quite extensive when it comes to this subject: from best practices on how to get to the forced 75% code coverage to a Stub API, developers are very well taken care of. But all of that is unit tests and only covers code related testing, no functional testing of the configured Salesforce parts.
Over the Nekst few blogs (not sure how many it will be, but 3+) I'll share some of the challenges I've come across over the past 3 years.
One of the key features of Salesforce is the out-of-the-box and custom code combination. Or maybe it’s more out-of-the-box vs. custom code. Both have their pro’s and con’s which are depending on a lot of variables which can even change over time, with new and updated features introduced by Salesforce. Not even considering new requirements coming from the business.
Basically, a Salesforce configurator configures the functionality, objects and other features that are in the Salesforce Box. A Salesforce developer can build custom features and functions that are not part of Salesforce or if a standard feature just needs that extra zing.
As a result, most of the time the features delivered by the configurator or developer, are working fine by itself, but it can be a different story once you start testing it from a functional perspective, let alone a UAT. A configurator might not have considered the impact on the custom code part and vice versa, simply because both sides lack that knowledge. Here the tester comes in, from the moment you start discussing a feature in your (agile) team, challenge the solutions brought in by the different team members.
Reason to do this is that people generally approach problems and challenges with the tools they master (in this case configuring or coding) but as a result, not always consider the bigger picture. As a tester you’re usually working closely together with the business analyst and end users, which gives you the advantage of assessing the solution as a whole and putting single features in a perspective that adds most value to your solution. Often, I found that the combined ideas that were sparked by the input from every team members first ideas, were most valuable and usable!
With the combined forces we managed to evolve the case creation process from an out-of-the-box new case page with prefilled fields to a super smooth case creation wizard, that fitted and fits the business perfectly.
Another advantage of continuous challenging is less bugs in a later stage of development. To me there’s nothing more annoying than testing a combination of functions that were all developed separately and seeing it fail at the first (integration/end-2-end) test case. Also for a configurator or developer this will be a big plus, since who likes to rebuild the same thing over and over again?
In my Nekst blogs I will focus more on practical tricks, deployment & test automation. If you have any additions or questions you want to bring to my attention, feel free to contact me on LinkedIn or Twitter.