Ostia Solutions Agile Testing Sandboxes

Many of us are familiar with the term ‘sandbox’ from our childhood. A sandbox was a safe, isolated environment where children could play without fear of hurting themselves or damaging anything else in the process.

Consider a sandbox to be like a flight simulator for your back-office environments. A sandbox running on premise using commodity hardware and software simulates the back-office environment (applications and data). The sandbox is dedicated to an individual developer or tester; they have their own standalone environment which reacts exactly like the real environment. Once created, a sandbox can be fired up as often as required as a cost-effective solution to the problems caused by challenges of shared test environments.

Sandboxes fit perfectly into the worlds of Agile Development and Continuous Integration enabling real benefits of early delivery, productive cross-functional teams (including development and testing), evolutionary development and validation of deliverables.

Without sandboxes, the effectiveness of Agile development is often limited by the following:

  • Agile development is very much about trial and error until you get it right. Often such ‘trials’ can cause problems and instability on the 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.

Portus testing bottleneck example

Ostia’s Portus sandboxes have the following key features:

  • No sharing of the environment; the developer is isolated and will not impact others or be impacted by them
  • Crash and burn environments; the environment it can simply be discarded and restarted.
  • No access required to production or test environments or data
  • Data can be created locally in the sandbox
  • These eliminate the bottleneck:

    Portus testing bottleneck example

    In summary, a Portus sandboxes acts just like the sandbox kids play in. It provides an environment where developers and tester and work safely in isolation from other sandboxes, testing and production systems.

    • Earlier delivery
    • Improved productivity
    • Improved quality of the released product
    • Lower costs
    Contact Us To Learn More