Test Data and Environments

In this episode of the Art of Modelling Test Approaches on Test Data and Environments Rich Jordan considers how your organisation can evolve its relationship with data and the amount required to effectively run functional tests and increase your options for test environments.

Previously, we’ve considered the impact of implementing the test pyramid, but also limiting the blast radius. This complements any loose coupled architecture being developed, and key to keeping your data and environment requirements targeted to minimise the risk of accidental complexity. 

Modelling is a great way of achieving these outcomes. On top of this, parametrising your model steps to align the data, or the criteria,  will keep your data requirements aligned. Additionally, modelling is a great was to collaborate around how an interface should work, and you might even look to build virtual interfaces from models.  

As your isolation strategy gains momentum, so do your options for environments. The ideal you want is an ephemeral environment, short-lived environments that last the length of your test execution and then get dropped. This allows you to be cost-effective with your test infrastructure and gives you options to start to adopt things like environments virtualisation and sandboxes.  

With these principles in mind, the outcome is the removal of data requirements entirely. Start to replace actual data with regular expressions, and this approach is useful for a large proportion of those less critical tests to the broader SUT.  

Often, teams may not think ahead about the data requirement, then with an execution window dawning on them, they’ll just default to using the same integrated test environment that they have always requested.  

To learn more about how you might use modeller to overcome some of these challenges, check out the webinar in the link provided: Isolating Blast Radiuses For Testing Webinar | Curiosity Software.

This segment is part of Art of Modelling: Test Approaches, with Curiosity Software Enterprise Solutions Architect, Rich Jordan. Drawn from expertise in Test Design, the series asks: What does a good test approach need to consider?