Published Articles

Most of the posts are just notes, but some are more like articles, or actually were articles that were moved here once my rights reverted back per contract. In other cases they are cross-posted on a vendor blog site.

5 tips for using JMeter Fragments for enterprise API testing

Scott S NelsonLeave a comment

Google is the greatest boon to software development since disks replaced those paper bunch tapes … but solutions for individual topics found online often skip the implications when applied at scale. This blog post will not add new information to the collective knowledge of using fragments in JMeter to test APIs; it will put some important concepts in the perspective of applying them to real-world enterprise solutions.

First things are not always first

Ideally, this article would start with the first tip. I know I generally prefer my information that way, i.e., direct and to the point. If you are reading this, it is because you understand that isn’t always the best way to get to where you need to be. Specifically, a good tip to start with for using Test Fragments in large-scale JMeter API Test Plans is how to plan your taxonomy. The problem with that approach is that you may not understand why that is important until you get to the point where significant refactoring will be required. So, we’ll start with the “why,” then get to the “how.”

Tip 1: Not all fragments are the same

The main purpose of a Test Fragment is to apply the same type of reuse that is encouraged in enterprise design. The other value it provides is the ability to cleanly separate different aspects of a single JMeter Test Plan in support of multiple contributors and source control.

There are two types of Test Fragments in JMeter:

• A node with a Test Plan as the parent and referenced by a Module Controller that is a child to a Thread Group. For convenience, these will be referred to as Test Fragment nodes.

• A JMX file that is created by applying the “Save As Test Fragment” menu option on a Controller and then referenced by an Include Controller that is a child of a Thread Group. These will be referred to as Test Fragment files.

Test Fragment nodes cannot be included in a Test Fragment file, which is why they either need to be saved off as a Test Fragment file or duplicated within the controller that will be exported as a Test Fragment file. This is the first thing to know before creating your source taxonomy.

Tip 2: Refactoring before committing

A key concept in using Test Fragments for large Test Plans that is rarely pointed out is that it is best that Test Fragment nodes are only used during development to avoid redundant refactoring. When specific steps are required multiple times, placing them in a Test Fragment node while working them out is a huge time-saver.

At the completion of development, the contents should be saved as one or more Test Fragment files that will be included in the main JMX file containing the Test Plan and potentially (though rarely) other Test Fragment files. The value of moving the node to a Test Fragment file before committing to source control is that it minimizes the overlap in Test Fragment files between efforts. Working alone, this doesn’t present an issue. But as soon as there as multiple contributors, it quickly becomes very time consuming to manage merge conflicts when too much is in the main JMX file. The use of Test Fragment files greatly simplifies this.

Tip 3: Rules are made to be broken, except when they shouldn’t be

The decision to save a Test Fragment node as a Test Fragment file is based on how many other Test Fragment files may require the Test Fragment. For example, if a Test Fragment node is used a few times in a specific Test Fragment file but not in any other Test Fragment file, then saving as a separate Test Fragment file is of little value. Likewise, if the Test Fragment node is only referenced once or twice and in only two Test Fragment files, it is still not worth creating a separate Test Fragment file, because they should rarely need to be refactored once the API they test is released to production. This is when you must break the rule of re-use and simply duplicate the nodes where necessary once they are stable.

While this type of duplication would not be appropriate in an application developed in an object-oriented language, JMeter is a platform that runs off configuration files where re-use is possible only in a limited way without becoming more work than it is worth.

There may be cases where a particular process is repeated several times. First, review the use of this process to determine if there is a more elegant solution. If not, continue to develop with the process in a Test Fragment node and later save it as a separate Test Fragment file with the naming convention of [parentFragment.childFragment.jmx] to make the usage and dependency clear.

Finally, it is important to understand that APIs are meant to abstract the underlying code. Even if you know the origin of the code, test fragments should be grouped primarily by functionality and (where appropriate) by common test data and not by the namespaces of the source code.

Tip 4: Plan fragments like they are stand-alone test plans

Remember that part earlier about occasionally needing to include other Test Fragment files in Test Fragment files? One of those occasions is when a fragment depends on a variable that is the result of another fragment that is included in the thread. For one reason or another, that first fragment may later be excluded from the thread. In such a case, the dependent fragment should test for the variable with an IF Controller and then include the Test Fragment file to generate the necessary variable.

One additional note about Test Fragment files including Test Fragment files: When a Test Fragment file refers to another Test Fragment file, the path is relative to the main JMX file.

Tip 5: The simplest approach to refactoring is to use two files

This last tip raises a lot of eyebrows when first presented. In the likely event that a Test Fragment file has to be updated, either as a result of debugging or an update to the application behavior, the way to work on the Test Fragment file is to copy the nodes into the main JMX and do the work there, then export the results back to the Test Fragment file. The temptation to make the changes in the Test Fragment file and then test from the main JMX should be avoided for all cases but the extremely trivial, like a variable with a name change and only referenced in a single node. Trying to do all of the work in the Test Fragment file will result in moving back and forth between the files and take much longer than anticipated. Just remember to run a final test with the new Test Fragment file and the original main JMX.

Bonus Tip: Taxonomy

Since I clearly pointed out the need for this in the introduction, I feel obligated to include this last tip. At a high level, the recommended taxonomy looks like this (replace [BRACKETED_TEXT] with your own labels and the example text as necessary):


.
+-- [APPLICATION_NAME]_API_TESTS.jmx
+-- Test_Data
|  +-- [COMMON_DATATYPE].csv
|  +-- [FRAGMENT_NAME_01].[DATATYPE].csv
|  +-- [FRAGMENT_NAME_02].[DATATYPE].csv
|  +-- ...
+-- Fragments
|  +-- apis
|      +-- FRAGMENT_NAME_01.jmx
|      +-- FRAGMENT_NAME_02.jmx
|      +-- FRAGMENT_NAME_02.SUB_FRAGMENT.jmx
|  +-- common
|      +-- login.jmx
|      +-- logout.jmx
|      +-- create_account.jmx
|  +-- setup
|      +-- environment_prep.jmx
|      +-- generate_common_data.jmx
|      +-- [OTHER].jmx
|  +-- teardown
|      +-- data_clean_up.jmx

More tips to come

This post is based on common guidelines I help enterprises define. It has been my experience that using fragments as described here is the best way to support testing of a large, complex, API-driven application that is continuously evolving. It has also been my experience that using them counter to the recommendation of always moving fragments to files early results in productivity loss by requiring more time in maintenance, which detracts from expanding the testing footprint. But it is not the only important lesson is scaling JMeter API testing. If you benefited from reading it, please let me know what other areas are of most interest to you and I will base the next article in the series on that.

Originally published at https://logic2020.com/insight/tactical-jmeter-fragments-enterprise-api-testing/

If you found this interesting, please share.

© Scott S. Nelson

How to set up self-registration in a Salesforce community

Scott S NelsonLeave a comment

This is the unedited version of the post on my employer’s site at https://www.logic2020.com/insight/tactical/how-to-set-up-self-registration-in-a-salesforce-community

Salesforce Communities are a really cool way to interact with your customers in the context of your product or service. Like most good portal products, it has a lot more features than most people will ever use. The upside to that is if you think of something you think your portal should have, odds are pretty good it does. Downside is that it can sometimes be onerous find all of the details you need to make something work. Community Self-Registration is just such a feature. While I can describe the details in under a page (with the two screens removed and linking to one page of documentation directly from Salesforce), it took me three hours of reading blog posts, user community threads and Trailhead training entries to get all of these steps down and working. To make sure I had it all correct, I then spent 20 minutes repeating the process in a different org from scratch and writing up this article.

With all that said (which almost doubled the content), here are the steps…

First, create the account you will use for assigning users to. This should be an account specifically for this purpose for ease of reporting and managing accounts.

Next, make sure your profile has a role (the default Developer org does not have one assigned).

Clone the Customer Community Login User profile for the profile you will use for community members that self-register.

From Setup, open the community from All Communities > Workspaces. Go to Administration and Members and add all profiles that should have access to the community, including the one you just created (you may need to use the All option from the dropdown for them to show).

SFDC Community Member Management

Remember to scroll to the bottom of the page and click Save when done.

Now you can follow the instructions at Use the Configurable Self-Reg Page for Easy Sign-Up, but before you test your login, make sure that you have activated your community from the Workspaces > Administration > Settings page.

One other hint: If you get errors, open the Developer console and the Log panel and try again to see what the error is. Next article will be how to customize the login page since your user probably don’t have access to the developer console to find out their password must include a symbol ?.

If you found this interesting, please share.

© Scott S. Nelson

Get Hands-on with VS Code, Salesforce DX and Packages

Scott S NelsonLeave a comment

(Originally published at Logic 20/20 as SFDX, VSCode, and deploying from a package the editors stripped out all of the links, rendering it an entirely different post. This is the original version.)

While I do not immediately dislike new tools, I do struggle with adopting them when I find nothing wrong with the old ones. And then I delay learning them until I’m forced to, which is the case of Visual Studio code for Salesforce (they are no longer supporting the Eclipse IDE and abandoned the DX extension for Eclipse before DX went GA) and Git (because that is the way the dev world has gone). I find the best way to learn new tools is to write about how to learn them, so here we go.

(In the spirit of working in a low code platform, we will also see how much of this I can do with just links to existing documentation…)

If you haven’t already, Install Salesforce Extensions for VS Code.

Then Enable Dev Hub in Your Org and Enable Second-Generation Packaging (note that while 2GP is beta as of this writing, this is required to enable first generation Unlocked Packages which is GA).

Next…Well, that didn’t take long. I cannot find a stand-alone URL for creating an SFDX project, so I’m going to steal a section from a Trailhead lesson (because it is as much typing to say what not to do as it is to re-create it here):

  1. Open VS Code.
  2. From the menu, select View | Command Palette.
  3. In the command palette search box, enter [PROJECT_NAME].
  4. Select SFDX: Create Project.
  5. Use the same name as your GitHub repo, then click Enter.
  6. Click Create Project.
  7. Create a .gitignore file to ignore hidden directories:
    1. Hover over the title bar for the DX project. then click the New File icon.
    2. Enter .gitignore. [check if it already exists and just edit if so]
    3. In the text editor, indicate to ignore these two hidden files:
.sfdx
.vscode

To foster good habits, I will set up a github repo to store this project in (though following a full lifecycle will be another article) by following the excellent documentation at https://help.github.com/en/github/importing-your-projects-to-github/adding-an-existing-project-to-github-using-the-command-line and add the project to the repository.

Now go do some work in Salesforce. For example purposes, let’s do the Build a Simple Flow project.

After you complete the project, follow the instructions to Create and Upload an Unmanaged Package, skipping the Upload part. I named the project TH_Flow_Project, which you don’t have to, I only mention that as I will use that text in the example commands.

Salesforce provides a nice reference to Create a Salesforce DX Project from Existing Source.  I have some additional thinking around how to go about this part, so I will end the approach of linking to references and switch to my own approach. If you followed the last link and stopped here, you won’t learn anymore about the Salesforce DX capabilities, but you may miss out on some of my shortcuts and wit. With that said…

Authorize the org you created the flow in with the following:

sfdx force:auth:web:login –setalias <MY_SOURCE_ALIAS> –instanceurl <MY_ SOURCE_ORG_URL>

Example:

sfdx force:auth:web:login --setalias TH-ORG02 --instanceurl https://infa-ca-wav-dev-ed.my.salesforce.com/

A bit late to mention, but if you are using a Developer org, I highly recommend to Set Up My Domain. Trailhead orgs already have one. If you haven’t, you can probably leave off the instanceurl parameter and it should pick it up from the default configuration for your project (YMMV). Otherwise use the URL that you login to your org with.

Next, download the package using the following:

sfdx force:mdapi:retrieve -r ../ -p <PACKAGE_NAME> -u <USERNAME>, ex:

sfdx force:mdapi:retrieve -r ../ -p TH_Flow_Project -u scott@trailh2.org

Let’s break that down just a bit. The first part is the base command to retrieve (sfdx force:mdapi:retrieve). The -r parameter determines where the downloaded zip file will be located. The example uses a relative path indicating the folder above the DX project. As a best practice, I recommend always staying in the project directory inside the VSC terminal, with all commands base on being relative to that location. This way you can maintain a list of commonly-used commands that will be re-usable across all projects. The downloaded file name is always unpackaged.zip.

The files need to be unzipped before they can be used (someone should make a feature request for the convert command to work on zip files instead of having to unpack them first). In Linux the relative command is:

unzip ../unpackaged.zip -d ../

Now we add the files from the package to our project using the relative path command:

sfdx force:mdapi:convert -r <PATH_TO_UNZIPPED_PACKAGE> -d <PATH_TO_[/force-app]>, ex:

sfdx force:mdapi:convert -r ../TH_Flow_Project -d force-app

Now all of the files from your package are part of your project.

To add this to your target org, first authorize that org as done previously for the source org, i.e.:

sfdx force:auth:web:login –setalias <MY_TARGET_ALIAS> –instanceurl <MY_ TARGET_ORG_URL>

Example:

sfdx force:auth:web:login --setalias TH-ORG02 --instanceurl https://infa-ca-wav-dev-ed.my.salesforce.com/

And (almost) finally, deploy the updates from your project to the target org with:

sfdx force:source:deploy -u <TARGET_USERNAME> -x <PATH-TO-PACKAGE.XML>

sfdx force:source:deploy -u apex@theitsolutionist.com -x ../TH_Flow_Project/package.xml

(Another feature recommendation is to have an alias option instead of only the username.)

And finally (this time for real!) look in your list of flows to see the flow installed in your target org.

Of course, you are doing this with a throw-away org, right? Because I forgot to mention that deploying will over-write any existing components with the same name.

One final note. We used the package.xml from the downloaded package for the sake of simplicity. Once the package import is validated, you will want to combine the package.xml from the download with the package.xml in your project located in the manifest folder of your project.

The project created from the writing of this article can be found at https://github.com/ssnsolutionist/trailhead1

If you found this interesting, please share.

© Scott S. Nelson

Test automation: 3 things you need to know

Scott S NelsonLeave a comment

Test automation — using automation tools to execute test case suites — delivers numerous benefits, including greater time- and cost-efficiency, the ability to run tests unattended/overnight, and a lower risk of integration and production issues. Particularly well suited to automation are test cases that are:

  • New or modified functionalities
  • Business critical
  • Repetitious
  • Tedious for humans to perform
  • Performance sensitive
  • Time consuming

It’s important to recognize that automation can’t eliminate all manual testing because automation is for testing functionality. You still want users doing hands-on testing to ensure the usability of the application.

If your organization is considering automating parts of your testing processes, here are three things to keep in mind.

1. Cost and time requirements will be lower than you think.

Many teams don’t implement test automation because they believe that it takes too much time or too many resources. While this may have been true in the earlier days of test automation, it is no longer the case with modern tools and cloud services. For example, most tools can record user interactions and then allow developers and testers to modify the results for more dynamic testing. Also, most automated build tools can now incorporate many test engines into the build process, catching issues before they are deployed, and can impact live production use.

2. There are no static inputs in the real world.

Teams that do automation testing often use static, hard-coded parameters rather than dynamic parameters. This not only misses mimicking real-world use cases; it also will not properly reflect performance and scalability metrics where caching is in use. Dynamic parameters can either be randomly generated using standard scripting languages or driven from prepared input files. The parameters also need to be as realistic as possible. The use of nonsensical values to populate text fields and simple sequential numbers for complex number fields such as phone or amount can miss validating even the minimal edge cases

It is also important to have in place a procedure to reset databases to pre-test conditions for consistent re-testing.

3. Know when to run the automated tests.

In the Test-Driven Development (TDD) approach, the tests are written before the code. Even if your development team doesn’t follow TDD, writing tests as soon as the interfaces are created and callable can save hours of time spent performing manual functional tests. The amount of testing necessary to get from the first stubbed interfaces to ready-for-deployment into an integration environment is almost always underestimated. Not writing the tests as early as possible consistently results in either increased effort during development, manually testing functionality as the code changes (versus a button click or one-line command to run the automated test), or increased time during quality assurance debugging all of the scenarios that were insufficiently tested during development

Even if you balk at automating functional testing, testing before turning over to QA will save many hours spent in the writing of defect reports, triage reviews, debugging, and re-testing. Most true DevOps approaches include testing with every build-and-deploy cycle.

Conclusion: The bottom-line is about the bottom line.

The time spent developing and maintaining test automation will deliver a positive ROI by reducing the number of production issues and shortening QA cycles. The time it takes to realize that ROI will vary based on complexity and technical culture, though it is often much sooner than anticipated even with the best application teams.

As with most cases of process automation, automating testing is neither a silver bullet nor a one-size-fits-all solution. The value of real user testing is still valid and necessary, as there will always be use cases that are not anticipated by designers, developers, and testers. By taking the time to determine all use cases that can be automated, selecting the tool that best meets your organization’s needs, and leveraging best practices like using dynamic parameters and testing as early as possible, you stand the best chance of improving productivity, shortening QA cycles, building customer trust, and achieving positive ROI.

Originally published at https://www.logic2020.com/insight/tactical/test-automation-three-things-to-know

If you found this interesting, please share.

© Scott S. Nelson

Preparing for (and passing) the Salesforce Certified Platform Developer I Exam (WI19)

Scott S NelsonLeave a comment

(Originally published at InfoWorld, this version has an additional section on test taking tips.)

I’m ambivalent about certifications. Because I spent enough time in school for the equivalence test validation to be embedded in my psyche I have enough certificates to fill a two-inch binder clip. Because I have been working in the real world long enough to know what most of them truly reflect, I actually display them all in two-inch binder clip with a sticky-note on top that says “Pick One”. Anyone who has multiple certification knows that not all are of equal value in terms of proof of knowledge. I have one from an enterprise vendor that is a household name, very fancy looking with a hologram in the middle. It is the result of showing up for class every day for two weeks and the check clearing. Yet I learned a great deal achieving it. Another was acquired as a pre-requisite for continued employment following a merger, which was easily achieved with no study and only a third of the allotted test time. The next took a solid year of daily study and was taken in hopes of leveraging it to leave the employer that required the previous one. 

My most recent certification was one of the more difficult to study for: The Salesforce Certified Platform Developer I (WI19). While I have plenty of practical experience working with Salesforce, there are many aspects of the product that are required knowledge for certification that just haven’t come up for the businesses requirements I have been fulfilling. However, I enjoy working with the product and Salesforce has done a good job of convincing decision makers of the value of certification as an indicator of ability that I wanted to have it to please those decision makers. So here is how I went about it.

Trailhead

Trailhead is an invaluable resource for learning Salesforce, regardless if you are seeking certification or not. I use it all the time to keep up on new and updated features and whenever I run across a requirement where a tool that I’m not thoroughly familiar with may be helpful. Also, in 2018, Salesforce move the certification verification to Trailhead as well as the maintenance exams.

If you have not already created a Trailhead account, do so before reading on. If you already have a free Developer org, sign up at Salesforce Trailhead. If not, go to the Developer Edition site and get yourself one first. Pro tip: Don’t use your email address as your user ID for the Developer org, even though that is the default value on the sign-up form. User IDs must be unique to all of Salesforce, not just the org.

On Trailhead, navigate through the menus under Credentials > Certifications then to the specific certification you are interested in (or jump to the Platform Developer I (PDI) page). Here you will find the Exam Guide, which is a good way to understand the structure of the exam. There is also a link to a Trailmix. Trailmixes are groupings of Trailhead training modules and super badges created by Salesforce and other Trailhead users. These are a great way to begin preparation for a certification. If you have been working with Salesforce, many of the modules will be topics you are already familiar with. Skip those according to your own confidence level. I will add this personal anecdote about skipping Trailmix modules: The second-lowest score I received on the exam was in a category I work with regularly. The exam questions were about aspects that I no longer consciously think about, similar to how it may be hard to give directions with street names for a route you travel daily because you traverse them on autopilot. A refresher may be useful.

Udemy

I used Udemy to great success for the Salesforce Administrator’s exam by taking an excellent preparation course taught by Francis Pindar and then a practice test course with three practice tests. Preparing for the Developer’s exam was a bit more daunting, mostly because the nature of the exam has evolved in the last couple of years and the courses have not caught up with it.

Before you get sticker shock looking at the Udemy courses, here is the strategy to pay a reasonable price for Udemy courses in general. Create your account on Udemy and take one or two free courses (there are many worth doing). Eventually (at longest up to three months) you will receive and offer for all courses for a flat rate per course that is quite reasonable. If your employer has a discount program that includes Udemy (such as Fond), you can get an even better price. I only paid $9.99 per course through my company’s Fond program.

As of this writing, the best Udemy course I found for the Developer’s exam is Salesforce Platform Developer 1 Certification Course by Deepika Khanna. It seems to be an Apex developer course that was later re-purposed for certification prep. As such, most of the content is there, though it may not be clear how it translates to the exam. There are also several course files that are not referenced in the course. One of these is a practice exam that has all of the answers in Word. Most of these questions are also in Salesforce Certified Platform Developer practice Tests, so I suggest you not read the Word document until after you have gotten everything you can from the practice exams.

I had taken another prep course on Udemy that had a great outline, but I did not find it a good learning resource as evidenced by the abysmal score I achieved on the first of the two practice exams.

The practice exam on Udemy is not the greatest, though it does reflect the actual exam process well, if not the questions themselves. There are a lot of spelling and grammatical errors in the practice exams and the mistake I made was to assume that an incorrectly spelt answer was automatically wrong. The spelling issue is not seen in the actual exam, so it is just an issue with the practice exam author.

Another lesson about practice exams is to avoid the temptation to take them early. There are only so many questions and you can end up memorizing the answer to those rather than learning the topic well enough to answer similar-but-different questions on the actual exam.

Other practice exam sites

The site I got the most from for drilling on test questions is a ProProfs Quiz, appropriately titled  Salesforce Platform Developer 1. Questions are added and updated occasionally. There were 131 questions available the final week before I took the exam. The same spelling issues seen on the Udemy practice tests are there, and many of the same questions. I also noted questions from the course quizzes from the exam preparation course I took, though not sure who copied who there. One thing to be aware of is that not all of the questions have the correct answers. Believe it or not, that is a good thing if you use the strategy I did. Every time I took the exam, I would research the questions I missed to better understand the concepts. This helped a lot. I also would save the final page with the answers to a PDF that I stored on my phone and reviewed when idle.

Some other useful practice sites:

  • Salesforce Certification Dev 401 #1 (also on ProProfs Quiz) is for the older exam. Most of the questions are still relevant, as the new exam has more topics than the old one.
  • Salesforce Certified Platform Developer 1 Quiz at Salesforce Tips, Tricks, & Notes is short but some of the questions are really hard. The order of events question was especially helpful in getting this topic down.
  • Simplilearn’s Free Salesforce Platform Developer I Practice Test is very hard, probably because they sell a certification preparation course. It requires some contact info, but I found they only send you ads a couple of times. No telling if they sell the info, though. Which is why I keep an anonymous account for such registrations.

Key topics to study

  • There are many questions related to Triggers and Order of Execution. Memorize this as best you can.
  • Knowing the Data Model well will boost your score. If you are good at memorizing things, the link will be sufficient. Otherwise, hands on experience (at work or on Trailhead) is the best way to embed the key points into your subconscious. I studied this the least and it was my highest scoring area from a combination of project work and Trailhead modules. YMMV.
  • Apex Testing has a multitude of sub-topics and there are some over-lapping concepts that can be confusing if you don’t regularly use this aspect of Salesforce.

Test Taking Tips

(This is a bonus section for readers of my LinkedIn or Solutionist blogs)

The process of answering the test questions is just as important as the approach to preparation in ensuring a passing score. I first go through the test quickly, reading each question and response options and answering those that are immediately obvious to me. I then go through a second time, answering the questions skipped the first time through and marking for review any that I don’t feel 100% confident about. An advantage to this approach is that sometimes one question is worded in such a way that I easily remember the answer and it reminds me of the correct answer to another, related question.

I then go back and review all of the questions marked for review, re-read the question and answer and asses my confidence. I do this in order of the exam questions because I still might leave it marked for review on this pass. The ones I was still unsure of on the review I then re-review. Finally, I go through the test from start to finish, reviewing each answer.

While this may sound very time consuming, I usually still finish with 20 – 30 minutes to spare.

Some final comments about certifications

The Salesforce employment market is heavily slanted towards certified applicants, so if you really like working with Salesforce and aren’t already in your dream job (or are a consultant who is always pursuing new clients), Salesforce certification is a must have. The Salesforce Administrator certificate I find the easiest to achieve, and if you are serious about Salesforce development I recommend getting both certificates because knowing enough administration to be certified will help you in designing better components.

No matter how hard or how easy a certification is to obtain, almost all are proof only of knowledge. In general, the application of knowledge is where the value is. As someone pursuing certification, continue your learning after certification. I find participating on the support discussions and completing Trailhead modules regularly to be a good way to grow beyond the day-to-day tasks.

And for employers, please weigh overall experience with certification achievements. Someone that has years of technical experience on multiple platforms and coding languages will be able to become very proficient in Salesforce in a short period of time, and someone with several certifications who has little experience outside of Salesforce and all within a small variety of orgs may not be the right fit for a complex implementation.

Finally, my own score on the exam was not in proportion to my actual capabilities. The exam results are broken down by category. In one case I scored very low in an area that I use regularly and frequently advise others on. In another case I scored quite high in an area I rarely use and most of my learning was academic. Having previously passed the administrator’s exam, it is no surprise that my best categories were the areas that overlap.

If you found this interesting, please share.

© Scott S. Nelson