Agile Testing Sandboxes

Agile Testing Sandboxes

What are they and why are they useful?

Many of us are familiar with the term ‘sandbox’ from our childhoods. A sandbox was a safe, isolated environment where children could play without fear of hurting themselves or damaging anything else in the process. So where does this concept fit into the world of Agile Testing?

The concept of Agile Development has been around for some years now and combines concepts such as speed of delivery, testing while developing, validation of deliverables (rather than long test cycles) amongst other things. While this works well for applications born in the Cloud and only running in the Cloud, it becomes more challenging for Cloud, Mobile or other developments requiring access to complex back office environments.

Agile development is often incompatible with such environments for the following reasons:

  • Agile development is very much about trial and error until you get it right. Often such ‘trials’ can cause problems and instability on these back office environments.
  • These environments are normally a subset of the production capability and are not built to handle potentially hundreds of developers testing while developing.
  • The nature of a shared test environment is that it is continuously changing leading to scenarios where something works one minute and five minutes later it doesn’t with no changes to the code. How often have developers spent hours looking for bugs when it was simply a change someone else made to the back office environment that changed the behaviour?
  • Non-functional testing is more difficult as changing the behaviour of the shared environment will impact on others.
  • Existing and even stricter upcoming data governance rules can often rule out access to such test environments due to data governance issues whether this is in house or off shore development.
  • Continuous Integration and Testing is a key part of the Agile Development cycle which is incompatible with shared test environments as the environment state can never be guaranteed.

The combined impact of these challenges creates a testing bottleneck.testing bottleneck 01

What this results in often is a total lack of access to test systems by developers and a long, frustrating test cycle getting shared access to limited resources for perhaps a couple of days a month. This is where a sandbox environment can help.

A sandbox running in the Cloud, Docker or on commodity hardware and software simulates the back office. Consider a sandbox to be like a flight simulator for your back office environments. The developer develops and tests against their own standalone environment which reacts exactly like the real environment. Once the sandbox is created, it can be launched as often as required as a cost effective solution to the challenges of shared test environments. It also offers a key capability to support Continuous Integration (CI) processes. The major differences are:

  • No sharing of the environment means that no one else can impact on that developer’s testing and that developer will not impact on anyone else’s testing.
  • As the environment is not shared, the environment has a state well known to the user of that environment.
  • These are crash and burn environments; if the environment is broken so badly by use, it can simply be discarded and restarted.
  • There is no access required to production or test environments thus avoiding potential illegal access to core environments or data, or any performance issues.
  • All the data can be created locally in the sandbox and is, by definition, test data with no connectivity to production or even test data on the test environments thus complying fully with existing and future data governance regulation.
  • Sandboxes can be used for Continuous Integration/Continuous test processes as an environment can easily be fired up that has a known state for these processes.

Compare the following to the previous bottleneck:

bottleneck releived 02

A key point here is that these sandboxes can be created for new systems or for legacy applications that have been in place for decades. Even the largest of legacy IBM Mainframe systems can be simulated in a sandbox in this way ensuring that no matter what type of system you are using, it’s possible to use this sandbox concept.

In summary, the Sandbox Environment acts just like the sandbox kids play in. It provides an IT environment where you can develop/test/play safely, both personally and for the organizations you represent, you are isolated totally from others working in other sandboxes and critically you can’t break anything that cannot be fixed within minutes. This leads to:

  • Faster delivery times
  • Improved productivity
  • Improved quality of the released product
  • Lower costs

Now who wouldn’t want that?

Written by : John Power