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.
Salesforce Functional Testing Part 2: Tips & Tricks
While my first Blog was more about the process and team dynamics, this blog will feature some more practical tips & tricks on how to test. All of these come from my personal experience as a tester in a Salesforce implementation.
Individual Test Users
During the first months of our development, every now and then we encountered issues that weren’t reproducible. Clicking on a button or link on the screen might open a completely different page then expected or give a nasty error without any clue what could’ve caused that. Given the non-reproducible nature and the fact that it wasn’t occurring all the time, investigating this was a challenge. It was only over time that we got an idea of what might have caused this: user accounts.
At the beginning of the project test users were created in all our environments and since I was the only tester, I would be the only one who would use those accounts. After a while, we decided that our configurators and developers should unit test their new features before releasing it to test, to improve the quality throughout our whole development process. What we didn’t consider during that decision is which users they’d use for those intakes. Of course, they ended up using the test user accounts, which is no problem for as long as you are not logged in at the same time, but it is a problem if that user account is used by multiple logins at the same time. Salesforce gets confused and as a result all your test results are corrupted.
From that point onwards, everyone had to create his or her own individual test user. This will save you a lot of time investigating false positives!
Browser Banter
This tip is as old as Netscape Navigator. When you’re testing features, improvements, regression or bugs, sometimes you forget Salesforce is running in your web browser (at least I do every now and then). This means what might work in Firefox isn’t working in IE, especially when it comes to apex, JavaScript or using web elements. The out-of-the-box features are all pretty straight forward, but once you are entering the custom code domain, it pays off to execute every test case in the browsers that should be supported by your solution.
A nice trick that can help you identifying issues in browsers is that IE (11) has the tendency of not showing an error, if something goes wrong in your code. It just shows a blank screen, whereas if you do the same thing in Firefox, there’s a nice error message that will probably help you with debugging the issue.
Another top tip is to not forget the development tools/extensions/options that are in the modern-day browsers. Firebug, Chrome apps & extensions, developer tools, etc. They can really help you in the debugging process.
In those browsers, there’s another cool feature for testing: private browsing. Sometimes you want to make changes to your test data or Salesforce configuration while testing. Usually this can only be done with an Administrator account, while your test execution is done with an end user (test) account. To prevent you from the hassle of logging off, change settings and logging in again, you can use private browsing. Just open 2 separate browser windows (not tabs!): in 1 you log in with the Administrator and in the other one with your test user. A Great time saver this is!
I hope this will bring you some extra convenience when it comes to functional testing your Salesforce implementation. More to come in a Nekst Blog! Stay tuned.
If you have any additions or questions you want to bring to my attention, feel free to contact me on LinkedIn.
Would you like to learn more about Salesforce functional testing?
Download our whitepaper for free, and find out more about tips and trics regarding Saleforce Functional Testing.
