Test reuse by in APM is a practice in software engineering that involves leveraging existing test cases or suites to monitor applications, modules, or components.
With the increasing use and complexity in both modern custom apps as well as packaged app platforms (such as ServiceNow, Salesforce, Workday, and SAP), the need to ensure that business critical workflows function as needed means that testing must extend across transition (environment) boundaries as well as continuously over an ever-changing production landscape. To do this manually would take countless toilsome hours for every new feature, every production release, and every change to environment.
Test reuse by in APM is a practice in software engineering that involves leveraging existing test cases or suites to monitor applications, modules, or components. Application Performance Management (APM) is a practice in systems delivery that focuses on monitoring and managing of infrastructure, its performance and availability, as it supports production apps and services. Synthetic monitoring uses automated checks rather than real human users to continuously verify that known patterns and workflows in apps are working as expected.
Using existing API, end-to-end, and performance test assets as the basis for synthetic monitoring can save engineering team time, decrease risk continuously as changes occur to production environments and infrastructure, and maintain alignment in risk as software transitions from lower to production environments.
Test reuse by APM can improve quality engineering practices in several ways. First, it promotes consistency in testing. Reusing established test cases can ensure that testing procedures are consistent across applications, modules, and components. It encourages better documentation of test cases. When tests are reused, documentation must be updated to reflect the changes made for the new application, module, or component. This process ensures that test cases are well-documented, which can help with future maintenance or updates.
Test reuse can also lead to increased testing efficiency. Because the tests have already been created, there is no need to reinvent the wheel for every new application, module, or component. This reduces the time required for test development and allows teams to focus on other important aspects of testing, such as test execution, analysis, and reporting. Writing new tests for every application, module, or component can be time-consuming and expensive. By reusing existing test cases, organizations can transfer the time and costs associated with initial test creation to include value as synthetic monitoring assets. Additionally, because the tests have already been created, there is less risk of errors or omissions in the test cases, which can result in expensive rework or production failures.
However, test reuse also has drawbacks. Reusing tests without proper customization can lead to false positives or false negatives. False positives occur when a test passes even though there is an error in the system, while false negatives occur when a test fails even though the system is working correctly. Customization is required to ensure that the tests are suitable for the new application or module, which may have different requirements or functionality.
Additionally, many tests expect input data to match underlying data in the systems making up the environment under test. Think about it long enough and you may arrive at how important data is to testing, then also how many tests often exercise the system and cause state change; in other words, tests change the data in an environment. Imagine your sales team’s or finance department’s reports including test data in their projections, or wasting time calling in to fake account phone numbers, or simply biasing the numbers reported to federal agencies.
This is one of the primary reasons why ‘testing in production’, if applied in a traditional manner without re-thinking the reasons and value using synthetic monitoring, can often be a controversial or divisive topic for people who’ve been around the technology block. Some tests that don’t create records or alter account state may be fine, but only if you know exactly what it’s doing, and even if you do it doesn’t solve for monitoring the critical workflows and transactions that do interact with critical data.
Using test accounts in production to retain segmentation is also tricky, even if you do have a systems-wide approach to excluding them from any and all production critical reporting because of their security implications.
In conclusion, test reuse by APM can provide significant benefits to organizations, including cost savings, increased testing efficiency, and improved software quality. However, there are also drawbacks that must be addressed to ensure that the tests are suitable for the new application, module, or component. When properly customized and implemented, test reuse can promote consistency, better documentation, and increased efficiency in testing, ultimately leading to better software quality.