Incorporating performance testing into the software development lifecycle
In traditional software development environments, ensuring consistent and optimal performance of applications is a significant challenge. When issues surface in the hands of end-users, they result in degraded user experience, increased customer dissatisfaction, loss of revenue, and potential damage to your organization's reputation. You're looking to avoid these problems and improve the quality of your releases by using Splunk Synthetic Monitoring in your software development lifecycle.
How to use Splunk software for this use case
There are a few ways to incorporate Splunk Synthetic Monitoring into your software development lifecycle, depending on how you like to work.
Run tests in both PROD (more frequently) and pre-PROD (less frequently, based on your release velocity)
Running tests in pre-PROD helps in a few ways:
- Getting the baseline for pre-PROD performance will help you understand spikes, as well as help address performance issues for users who are testing or building content in pre-PROD.
- Catching true performance degradation. If there is a sudden change in performance in pre-PROD due to a release deployment, the issue can be caught and remediated before it impacts end users in PROD.
- Catching flaky tests. If there is a code change that impacts a selector value or workflow, for example, testing in pre-PROD can help prevent false negatives (and fire drills) in PROD.
Create naming conventions and custom properties
Name your tests clearly and in a consistent pattern to better understand and prioritize tests. Doing this means you can quickly understand how, for example, "[staging] home - mobile EU" differs from "[prod] checkout - desktop US" and how they might relate in priority. Add custom properties to better group your tests.
Choose appropriate testing locations and authentication
If your pre-PROD environments are internal only, you can test these from private locations. If they require authentication, that can be built into the test steps or preloaded in advanced settings, depending on the type of authentication.
Create detectors
Create detectors for your KPIs in both PROD and pre-PROD. This will alert you if something unexpected happens in either environment so you can triage as needed. Set the severity of the alerts with intention, customize the alert message payload, and add tips and link to runbooks.
Create events
Push events to Splunk Observability Cloud to give context to changes in KPIs on dashboard charts. Create events that align with your code changes or other notable timestamps, like new content campaign launches. Events can be managed in the Splunk Observability Cloud GUI or you can incorporate them into your deployment process by using the API endpoint for events. This way you can more easily view performance trends as they relate to potentially impacting causes without disrupting your CI/CD.
Send metrics from Synthetics to the Splunk platform and ITSI
Synthetic performance metrics can be sent to the Splunk platform via the Splunk Infrastructure Monitoring Add-on and ITSI as part of the Content Pack for Observability Cloud. There is an API for all test types, and also Terraform support for Synthetics. Depending on how you are building automation into your workflows, you can incorporate those performance KPIs to flag release versions as needed. You can also use the HAR Ingester Add-On for Splunk to pull in metrics about each resource loading in your browser tests; view trends in resource size and load time; and even segment by synthetic transaction to directly understand how resources impact what your end users need to do.