When I was just learning Salesforce and starting my career, the company I worked for at the time often tasked me with the exciting and highly sought after role of writing test scripts and performing Quality Assurance testing. It turned out I had a knack for it. First and foremost, because as I was new to Salesforce, I excelled at blundering my way through the system breaking everything imaginable as I went. Picture me as a hurricane of user errors, wreaking havoc on even the simplest of test scenarios. The second more important reason I excelled at QA, was because when I wasn’t breaking things on accident, I tried to break them on purpose.
Three incidents occurred recently that inspired me to write this blog post…
Incident 1
A new admin, I’ll call him/her Admin Shmadmin, writing their first process asked me for some help. I told them to make sure they test it to verify it works as expected, then to make sure they test it to validate it doesn’t work when it’s not supposed to. They said, “Why should I test it at all when I can see from the way I wrote it that it will work?”
Just because you think you see that it will work doesn’t mean it will, which leads us to incident 2…
Incident 2
Another admin, Admin Shmadwin Badwin, wrote a validation rule that they thought was so simple nothing could possibly go wrong so they didn’t test it at all. It turned out they used a function that doesn’t really work (See IsNull) and when it came time to demo to the stakeholders, it didn’t work at all. How embarrassing.
Incident 3
Yet Another admin, Admin Shmadmin Badwin von Sadwin, built some automation to create tasks every time a specific type of record was created, but they forgot to add the specific type of record to the criteria. When they tested they created the specific type of record and it worked, so they moved it on up to production. Then all the non-specific records triggered task creation and all hell broke loose.
When we build things that are glorious, we want them to work.
Take a few minutes and try to solve this puzzle in this New York Times article.
Let’s say theoretically you spent 15 hours, or 10 story points, or one long torturous weekend, working to make sure something functions to its exact specifications. You awake the following morning all bright eyed and bushy tailed, fantasies of the applause and congratulations you’ll get from the rest of the project team, only to receive one single bleak email informing you that the thing you put your blood sweat and tears into had immediately and without a doubt failed QA. It’s the kind of thing that makes you want to pull all your hair out and set it on fire.
Just because you really really want something to work doesn’t mean it always will. We have to remember this and try to break our own stuff. It’s the responsible thing to do. Don’t let confirmation bias ruin the Quality of your work. Assure success and make absolutely sure your stuff can’t be broken.
Good luck and happy testing!
