OSS/BSS Testing – Transitions

One of the most vital, but underestimated aspect of OSS/BSS project implementation is ensuring momentum is maintained. These large and complex projects are prone to stagnating at different stages, which can introduce pressure onto the implementation team.

As mentioned in yesterday’s post, the first in this week’s series, the test strategy and scheduling is regularly overlooked as a means of maintaining OSS project momentum. More specifically, careful planning of transitions between test phases and the environments that they’re run on, can demonstrate progress – where progress is seen through the introduction of business value.

The following diagram provides a highly stylised indicative timeline (x-axis) of activities, showing how to leverage multiple different environments (y-axis). See here for examples of additional environments that you may have on your project.

You’ll notice that this diagram covers:

  • Environments
  • Test phases (eg FAT, SAT, SIT, DMT, NFT, UAT – see descriptions of these test phases here)
  • Build phases (build, configure, integrate)
  • Data loads (reference data, symbolic data and/or real data extracts)
  • How builds and data loads can be cascaded between environments to reduce duplicated effort

OSS Phasing - Testing, Environments, Data

Some other important call-outs from this stylised diagram include:

  • The Builds and Data Loads cascade from lower environments (eg from PROD-SUPPORT to PRE-PROD). Thought needs to be given as to which builds and data sets need to be cascaded from which environments
  • However, after PRE-PROD is handed over and becomes PROD, it is common for cuts of production data to be regularly loaded back into the lower environments so that they are PROD-like
  • Stand-up of new PROD environments is often a long lead-time item (because of size and complexity such as resilience architectures, security, etc), compared to lower environments. Environments such as DEV/TEST could be as easy to stand up as creating a new Virtual Machine/s on existing hosting
  • Different environments may have access to different data sources / integrations. For example, the lower environments may be connected to lab versions of devices and NMS/EMS. Alternatively, the network might be mimicked by simulators in non-PROD environments. Other integrations could be for active directory (AD), environment logging, patch management, etc. Sometimes production data sources can be connected to non-PROD OSS environments, but this is not so common
  • The item marked as Base-build on the PRE-PROD / PROD environment reflects the initial build and configuration of virtualisation, databases, storage, management networking, resilience / failover mechanisms, backup/restore, logging, security hardening and much more
  • Careful transition planning needs to go into PROD cutover. In the sample diagram, a final cut of data comes from the Current PROD environment to PRE-PROD before it becomes the Future PROD environment during official handover
  • You’ll notice though that there may still be a period of overlap between cutover from Current PROD to Future PROD. This is because there needs to be staged data source cutover in cases where data sources like network devices can’t multi-home data feeds to both environments in parallel.

This earlier post provides some insights into novel ways to slice and dice your OSS implementation by planning of regular drops and consistent release of business value

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.