When building out various components of a demand generation strategy within Marketo, testing is an area that can often be overlooked. It’s tedious and time-consuming and not always the most exciting task, but the more complex the logic is within a component, the more important testing becomes. Something as simple as a missed flow step or incorrect trigger may have downstream implications that impact the accuracy of your team’s reporting, sales processes, or even external user experience. It’s much easier to catch and fix errors prior to going live than to attempt to trouble-shoot, fix and clean up data within live programming. A solid testing plan will help you do this.
The answer here is – everything you build. This may include (but is not limited to) lead lifecycle programming, lead scoring, lead nurturing, channel tracking programming, data management programming, email compliance (CASL/GDPR) flows, integrations, and user-facing assets such as emails, landing pages and forms.
When you're testing a piece of programming, you'll want to make sure you're testing all possible scenarios that could happen to a record within that flow to ensure nothing is falling through the cracks. The best way to do this is to create a spreadsheet that lists out all of these scenarios, the starting attributes a record should have for each scenario, the test steps or updates you'll need to make to a record to simulate a scenario, and the end result that should happen if everything works properly. Include columns where you list the test record you used for each test, pass/fail, and any notes for failures. Remember to include edge cases, and not just perfect path scenarios.
A standard naming convention for your test records is useful for several reasons. First, you'll want to be able to easily differentiate test records from live data if you're doing you're testing in a Marketo production instance rather than a sandbox. Second, for documentation purposes it’s good to have a way to quickly associate a test record with a particular scenario, especially if you're testing complex logic that requires multiple rounds of testing, fixes and re-testing. Our team uses the following standard format for our test records:
First Name: [tester first initial][tester last initial][yyyymmdd]-[numerical designation]
Last Name: Test
Email: [tester first initial][tester last initial][yyyymmdd]-[numerical designation]@test.com
So, for example:
Be sure to take into consideration any required fields as well as starting data attributes that are needed for your scenarios.
Sometimes it will be necessary to test programming in a Marketo production instance rather than a sandbox. When you do this, you'll want to be cognizant of the fact that there may be live data, reporting or routing in place. There are a several measures you can take to mitigate the impact of your testing in a production instance:
Documentation is an important part of the testing process. It helps you keep track of your progress, and down the road if something breaks you'll have a documented history of when it was working, which can help with trouble-shooting. As you go through your test scenarios, mark off each pass and fail. For the failures, make note of what went wrong. When you complete your scenarios, go back to the failures and determine what fix is needed, then re-test afterward, indicating the passes and failures for the additional rounds within the same spreadsheet. If you're testing programming that was built by someone else, look for trends around what’s failing to summarize for the builder, to help them identify where an error might have occurred in their programming.
Below are some testing tips for common components that you may have built or are planning to incorporate into your Marketo infrastructure.
When you design and implement lead scoring, it’s a good practice to test out your scoring model itself prior to building it in Marketo. This is particularly important if you have score thresholds aligned to certain stages of your Revenue Cycle Modeler. Run some tests to make sure that if someone does a certain amount of activities, or submits your progressive form a certain number of times, they accumulate enough behavioral points from the activities and demographic points from data entered via form submission to reach the score threshold for the stage you consider them to be in. Check your math. If you document your scoring model in a spreadsheet, you can create Excel formulas to quickly sum up a person’s score when you simulate various activities.
Once you finalize your scoring model and build it in Marketo, you'll need to test all of your triggers and flows. Ensure the correct amount of points are being appended to your demographic, behavioral, and total lead score fields as defined in your scoring model. If you're building multiple scoring models, ensure the correct score fields are leveraged throughout each build.
Before you build your RCM, it’s a good practice (and not just for testing purposes) to document the criteria a record must possess to move into each stage – scoring thresholds and any field attributes. When you're creating your RCM test scenarios you can use this as a guideline. You should test every trigger and flow step within each Smart Campaign that is leveraged in your RCM logic. Consider any skip or turn-back logic you have incorporated, where a person can move from one stage to a non-subsequent stage. If your RCM listens for contacts to be added to opportunity records in your CRM, then you'll want to simulate this behavior within your CRM (if you're testing an RCM in a Marketo production instance, be aware of implications this will have in your CRM production instance). Testing an RCM is often more time-consuming than building it.
It’s likely that your team is leveraging Marketo Programs, channels and triggered Smart Campaigns in some capacity to capture content interactions across various engagement channels. A common approach to this also involves a URL querystring strategy so that a single landing page can be promoted across channels. Anytime you build a new tracking program it’s best to visit the corresponding URL with querystring, submit the form, and ensure the correct Smart Campaigns are triggering, and appropriate actions are then taken to the newly created record (depending on your architecture this may be data value updates, a confirmation email, and/or a Marketo Program status update).
Run a test record through each Smart Campaign used within your Marketo Program. Ensure Marketo Program Status updates, wait steps and re-sends are all happening as intended. If you're using filter logic, run some checks to ensure there are no errors here. Before you schedule your batch campaign make sure that the number of people expected to run through the Smart Campaign is in line with what you'd expect, and ensure your Smart Campaign settings are correct.
Whether you're leveraging Marketo Engagement Programs to house your nurture logic, or building “from scratch” with traffic cops, watchdogs, and wait steps, you should be sure to test all logic that moves people into, out of, and within your nurture program. Ensure that only the people you want nurtured are able to flow in, and make sure that if a person’s data profile changes then they are moved to the correct new spot within the nurture program, or out of nurture completely. Furthermore, ensure that the correct emails are being sent at the correct points in time, and that interactions with the promoted content in those emails are accurately tracked. You'll also want to test the emails themselves – send tests to designated people on your team to ensure links are correct, and everything renders appropriately.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.