Photo by John Schnobrich on Unsplash

2 Common QA Misconceptions

Plan Performance Testing with Platform Architecture

If there is to be performance testing both the test tool platform and the test environment need to be robust enough to support it. This will require either a server farm capable of exercising the application at a realistic load or ensuring that the application performance test interfaces can be accessed by an external cloud-based platform. In the latter case, plan security testing to be done before the performance testing.

Automated Testing is Worth the Time

Many projects do not use automated testing because of the time involved in creating the tests. This is based on optimistic estimates of expected number of defects and iterations to resolve. Ironically, not having automated testing for regression testing increases the number of iterations to resolve defects and increases the total effort of testing.

Bonus Best Practice

Defect summaries should be formatted as TYPE: Component – Functional Error Summary

© Scott S. Nelson

Failing to plan is still a plan

Some planning tips from a retired page on this blog that are still relevant…

Periodically review tuning and best practice references related to the technologies, tools and products related to the project you are working on to catch potential issues before the occur.

Always include time for making necessary, realistic data available for development. Include approaches for resetting and refreshing data. The time spent up front will be half as much or less than the time spent afterwards creating it as needed.

Plan Your Monitoring Before Go-Live

This concepts sounds obvious and yet it so often does not happen even in mature organizations. Everyone will be much happier spending some time to think about scenarios where things could go wrong and determining thresholds for alerts on any area where a variance can impact functionality or availability.

Ever hear the boiling frog analogy? While the basis is not true, the concept is important, especially with software. Be alert. The world needs more lerts.

© Scott S. Nelson
SFDC Login Use Custom Domain

Trailhead Log In to Personal or Scratch Org SOLVED!

Having problems logging in to your dev, personal, or scratch org to verify the completion of a 500 point Trailhead lesson? Personal dev orgs are Production orgs and use and dev sandboxes are sandboxes and use and since I usually just use the CLI to log in to scratch orgs I can never remember which to use. And I don’t need to. There is enough to remember about Salesforce and technology in general, so if I can simplify something to a common approach, I always do. In this case, when authoring an org of an OAuth connection I always use the Use Custom Domain option and paste in the domain of the org I want to use.

© Scott S. Nelson
Bone-in or Wild Caught Lobster Tails Photo by Ruben Mishchuk from Unsplash

When Change Sets Fail in Salesforce

With the growing popularity of DX and the GA release of DevOps Center, I’ve seen fewer questions about Change Sets the last couple of years. I expect that organizations that have used change sets successfully for a long time are less motivated to change their processes and those that had issues have had sufficient time to move to the newer options.

What I have seen in the past around legacy processes that work well for small teams is that they are often passed to newer members experientially and at some point someone joins that is not mentored into to how things have been done and struggle on their own. Here are a few tips for those that run into this gap with change sets.

Practice makes it home by dinner time

Even the simplest change can result in big problems if something critical is missed. Always test the change set by pushing from one sandbox to another that has been refreshed since the last production update. If there is a possibility of changes being done directly in production, this means to create or refresh the test target sandbox immediately before the deployment test.

Go small or stay home

Incremental changes are best. I prefer to do a deployment anytime there is a completed task that has tested in development. The push could just be to a fresh sandbox with the final production release being a series of pushes. Another approach is to use dark deployments, pushing out tested work products incrementally even though not all pieces are ready for users. The dark deployments may require some custom metadata types or permissions to keep them from being used before they are ready, something it is really useful for large projects to avoid big-bang pushes.

The incremental pushes to sandboxes should result in a series for change sets. As they progress, dependencies may be discovered and indicate a need to revise the change sets so that dependencies are pushed first. Again, the dark deployments are useful here.

The mighty DX

Among many good reasons for switching to DX, verbose error messages for deployments helps speed up debugging. Using Workbench, it is possible to turn change sets into packages for use in DX, which is handy if you are just starting to migrate to DX. Again, test deployments against fresh sandboxes are critical to avoiding critical situations.

The only constant…

Is change, not change sets. Eventually change sets will probably go away, so if you are reading this post you are either bored and avoiding more productive tasks or you are struggling with a change set today.  Now is a good time to start looking into alternatives.

© Scott S. Nelson