BSC Digital Code logo
BSC Digital Code logo
  1. Home
  2. BSC & Codes
  3. BSC Digital Codes
Advanced Search
Previous version
Next version

CONTENTS

Testing Guidelines

v 13.0
Effective From Date:
Status:LIVE
Download

Testing Guidelines

Guidance Note

Purpose

This document provides guidelines for testing changes to the BSC Software, Systems and Processes. It also provides a high level view of test procedures that are followed by various parties involved in testing.

The management of testing and test deliverables is detailed in the Test Management procedure (Reference 1).

The scope of testing for each software release is detailed in the relevant Release Test Strategy document, which is developed by Elexon and the relevant Service Providers. The scope is agreed by all test participants and captured in the Test Strategy.

This document is specifically written as a guideline for testing the BSC Systems. However, the principles described may be used when planning for testing of other software systems.

1.Testing Process Overview

The following diagram illustrates the testing process used at Elexon. The Application Manager and Developer (AMD) develops and supports the software; the Business Process Operator (BPO) hosts and operates the live BSC Systems.

complex image of process

Stage 1 and Stage 2: Design and Development

    • The AMD produces software design in consultation with the BPO and ELEXON for any change to the BSC Systems.

    • All three stakeholders conduct a walkthrough of the design before ELEXON and the BPO approve the design.

    • The system changes are developed in accordance with the approved design. This may be done either by the AMD or a Third Party on AMD’s behalf. When the changes are developed, the AMD or the Third Party will perform Component and System Testing. Any defects found during this phase of testing must be rectified during this stage.

Stage 3: Factory Acceptance Testing

Following successful Component and System Testing, the AMD carries out a formal testing phase: Factory Acceptance Testing (FAT) and Installation Testing. Any software defects found are reported and the software developer, i.e. AMD or the Third Party fixes the defect and releases it for retesting. This will continue until no test defects are found by the AMD or until Elexon agrees that the software should be released to the BPO for its testing. The AMD then delivers the fully tested software to the BPO.

If a release involves complex changes, Elexon and the BPO may ask the AMD to complete test of critical functionalities first and provide a software drop for a dress rehearsal of Operational Acceptance Testing (DR OAT). The AMD will continue testing remaining functionality while the BPO conducts the dress rehearsal OAT. The dress rehearsal is used to give an early sight of any potential issues that may be discovered later on.

Stage 4: Operational Acceptance and Integration Testing

The BPO carries out Operational Acceptance and Integration testing of the software to provide assurance that the software will function correctly in the Live environment. Any defect found during testing is reported to the AMD or if applicable, the Third Party. The software defect is fixed and tested by the AMD or the Third Party and delivered to the BPO for re-testing.

On successful completion and approval of all testing, the software is ready for deployment to the Live environment.

Elexon will review all design and test deliverables issued by both the suppliers; test scripts will be reviewed before the relevant test phase begins and a test phase will not be deemed complete until Elexon has reviewed and approved its test report.

Service Provider and Test Participant Support

Successful testing depends upon the support and communication between Service Providers involved in the testing. The AMD, the BPO and other Service Providers should support each other with testing. It also depends on Service Providers supporting other test participants involved in the testing process. Test participants may include interested BSC Parties and BSC Party Agents, among other participants.

2.Application Manager and Developer Testing Overview

The AMD carries out the test types as shown in the diagram below. Generally speaking, the AMD does not conduct performance tests on the Live data volumes since the size of its test environment is not comparable to the Live.

Elexon may decide to witness AMD’s tests or nominate another stakeholder such as the BPO or any party from the industry for witnessing.

Elexon carries out Pre-Production Testing (PPT) on SVA Party Agent Applications, i.e. Estimated Annual Consumption / Annualised Advance (EAC/AA) and Non Half Hourly Data Aggregator (NHHDA) which are managed and developed by the AMD.

BSC Release specific testing

complex image of process

Other testing

complex image of process

complex image of process

Explanation of Test Levels and Test Types

The AMD is responsible for the testing of changes to the BSC software, hardware and processes. The testing carried out by the AMD falls into some/all of following test levels and types.

AMD Testing Overview

Test Levels and Test Types

Purpose

Component and System Testing

This is the lowest level testing of software code, required for all software changes. Testing should reflect that the design specification has been implemented correctly in each of the software components and the systems which they make up.

Factory Acceptance Testing (FAT)

FAT consists of Change Specific, Regression and Performance Testing. One or more of these test types will be carried out depending the scope and impact of the change.

  • Change Specific Testing (CST)

This verifies that specific changes to software have been successfully implemented. The AMD produces scripts to test specific changes. Change Specific Testing should ensure that the user requirements of that change are met.

Though the tests are conducted on a smaller set of data compared to the Live data, it is very important that it mimics the Live data as much as possible, e.g. if a data field is defined to be 3 decimal places long, it is crucial that the AMD does not limit this data to just one or two decimal places.

The AMD will either tailor existing test scripts in the FAT pack or write new test scripts to test new functionality. After the change is made Live, the AMD will include these CST scripts into the FAT pack for use as regression tests or to test future changes.

  • Regression Testing (RT)

This verifies that the unchanged functionality is unaffected by other software changes. This should be carried out if it is possible that any existing areas may be affected. A standard set of Regression Testing material is contained in the FAT Test Pack.

  • Performance Testing

This verifies that the changed and impacted functionality is performing without any significant impact. The AMD uses the FAT test input data and carries out performance tests to compare the pre and post change performance.

However AMD’s tests have limited scope because AMD’s test environment does not replicate the Live environment in terms of the hardware capacity and data.

Installation Testing

The AMD must ensure that the BPO is able to install the software. The BPO may be executing Deployment, Backout and Data Migration testing as required by a change.

  • Deployment Testing

This tests that a new version of software can be deployed and built into the necessary environment, which may also be new.

  • Backout Testing

This tests that new software or data can be restored to its previous version. For example, testing that an Oracle database is returned to its earlier version.

  • Data Migration

This tests that data can be transferred from a current software and /or hardware system to a new system. A typical case would involve data migration from one database to another, e.g. an upgrade to a newer version of Oracle database. Another example would be migration of data to a different operating system.

Ad Hoc Testing

Elexon may ask for ad hoc testing to be carried out in any part of the AMD testing. This may be used, for example, to test particular areas not covered by the current test types. Examples include:

Providing Test Data Flows for publication,

Testing connectivity for BSC Service Users, and

Testing Data Changes and System Parameters

Installation Verification Testing (IVT)

This is carried out if the AMD has made amendments to any of the Party Agent Application Software. The Service Provider uses an Installation Verification Test Pack to verify that the new software can be installed correctly. The IVT test pack is a cut down version of the FAT test pack. If any changes to the Party Agent Software impact the IVT test pack, the AMD will update any relevant tests in the test pack and run the IVT test pack to verify correct installation of software for the Party Agents.

Pre-Production Testing (PPT)

Elexon may conduct PPT of NHHDA and EAC/AA Party Agent Software. This involves full width data from a production database. This is typically an extract from a Participant’s (BSC Party Agent) database. The AMD will support Elexon in carrying out PPT testing.

Walkthrough and Page Turn

Changes to processes, systems and documentation are discussed and considered by stepping through the changed areas. This is typically done in a workshop or meeting with appropriate subject matter experts. The purpose of Page Turning is to step through new or changed documents which affect business processes. Page Turning can also indicate whether any process Walkthroughs, which have not already been identified, are required.

Test Witnessing/ Witness Testing

Test witnessing may be carried out by Elexon or by a participant nominated by Elexon (e.g. The BPO Host or someone from the industry) when a change is risky, e.g. changes to the Settlement calculation. Witness Testing should include positive (testing system meets requirements) and negative (testing erroneous data and conditions are handled correctly) scenarios.

Emergency Fix and Workaround Testing

This means testing of an emergency fix or a workaround to an existing process. An emergency fix or workaround may apply to a defect in the Live environment, for example. Any of the above test types may be applicable to the emergency fix or workaround.

Third Party Software Development

Elexon may use a Third Party to develop software and software changes to BSC Systems. Third Party software development is managed by the AMD. Third party software development should follow these guidelines:

1. The Third Party should adhere to AMD’s development standards, procedures and processes.

2. The Third Party should carry out Component and System testing of the software it has developed

3. The AMD will use FAT and Installation pack tests to test the software developed by the Third Party.

4. Any Third Party development software defect, whether it is identified by the Third Party, AMD or BPO, should be fixed by the Third Party under terms and conditions covered by the warranty between the AMD and the Third Party. After the relevant warranty period has expired, the AMD will be responsible for correcting any defects.

AMD Test Packs

The AMD uses the following test packs, which are a collection of previously carried out test scripts.

1. Factory Acceptance Test Pack

2. Installation Verification Test Pack

These test packs are enduring and should be maintained. The AMD should update existing tests and create any new tests in line with any changes to the software, systems or processes.

Elexon Test Packs

Elexon uses the PPT Test Pack to test EAC/AA and NHHDA Party Agent applications.

What Testing needs to be Carried Out?

The scope of testing is based on the scope and business risk of change/s being made.

Component and System, FAT and Installation testing are usually carried out with all changes to the BSC Systems. However, the amount of testing required depends on the change and is considered on a change by change basis. This allows the testing requirements for a change to be specified appropriately. Some points to think when determining the test scope are:

1. Is any process documentation affected by the change?

Consider a page turner and/or a walkthrough

2. Does the change affect any interfaces or the flow of data between the BSC Systems?

Interface testing between the affected systems should be carried out.

3. Does the change impact any existing processes?

Gain assurance by regression testing existing functionality.

4. Is a Third Party developing a software change?

Conduct full-fledged Acceptance Testing of the software.

5. Does the change impact any time dependent or performance related processes?

Ensure performance of those processes or functions does not degrade. Focus on performance testing in those related processes.

3. Business Process Operator Testing Overview

After the AMD has delivered software changes to the BPO, the BPO conducts the following testing as shown. Elexon may witness some/all of BPO’s testing depending on the scope and business risk of the changes.

The BPO also provides a Participant Test Service (PTS) that allows the BSC Parties to test that their systems interact correctly with the BSC Systems and Services.

BSC Release specific testing

complex image of process

Other testing

complex image of process

complex image of process

Explanation of Test Types

The BPO conducts some/all of the following test levels and types.

BPO Testing Overview

Test Levels and Types

Purpose

Acceptance Testing

The BPO performs acceptance testing to verify functionality and operability in a live-like test environment.

Acceptance Testing may consist of Operational Acceptance Testing or End-to-End testing.

Operational Acceptance Testing (OAT)

This is the thorough testing of software to ensure that is operationally acceptable.

It tests that:

the BPO is able to install, upgrade or cutover to any new or amended system changes.

the BPO operational Service levels can be met

the functional requirements are met, some amount of change specific and regression tests will be run.

the operational performance is satisfactory, testing that systems can support theoretical data maximums of production volumes plus 40%.

The security requirements of the software and data can be met.

Parallel Run Testing (PRT)

Parallel Run Testing is inherent of any OAT. The Release build is deployed in a test production-sized environment.

During PRT, the test environment will shadow the operation of the Live environment in near real time. The BPO will compare output from the test with that from the Live systems. Any resulting differences must be explained.

PRT provides additional assurance to regression testing, in testing that unchanged functionality is not adversely impacted.

Integration Testing

Integration Testing consists of: Service Integration, Interface and End to End Testing. The purpose of Integration testing is to demonstrate that all BSC Systems and their interfaces that are affected by a change are integrated correctly. Data flows between affected interfaces must also be correct.

Participant Testing / Interface Testing

This provides assurance that the BSC Services are correctly integrated. These tests the areas where interfaces, data flows or data transfer mechanisms are affected between the BPO and other BSC Service Providers or Users. This will typically be an interface between the Service Provider and a BSC Party or BSC Party Agent.

End-to-End Testing

This tests that business processes operate correctly from beginning to end. This may involve multiple systems, interfaces and test participants that are involved in the process being tested.

Participant Test Service (PTS)

This is a service which the BPO provides to the BSC Parties. It allows Parties to test the interaction of their systems with the BSC Systems. The PTS Guide (Reference 2) provides guidance on making effective use of the Participant Test Service and on booking the service to use.

Ad Hoc Testing

Elexon may ask for ad hoc testing services to be carried out in any part of the BPO’s testing. This may be used, for example, to test particular areas not covered by the current test types. Other examples include:

Providing Test Data Flows for publication

Testing connectivity for BSC Service Users

Testing Data Changes and System Parameters

Walkthrough and Page Turn

Changes to processes, systems and documentation are discussed and considered by stepping through the changed areas. This is typically done in a workshop or meeting with appropriate subject matter experts. The purpose of Page Turning is to step through new or changed documents which affect business processes. Page Turning can also indicate whether any process Walkthroughs, which have not already been identified, are required.

Test Witnessing / Witness Testing

Test witnessing is carried out by Elexon. Witness Testing should include positive (testing system meets requirements) and negative (testing erroneous data and conditions are handled correctly) testing.

Emergency Fix and Workaround Testing

This means testing of an emergency fix or a workaround to an existing process. An emergency fix or workaround may apply to a defect in Live BSC systems software, for example. After the AMD has provided the software fix or workaround, the BPO Host will carry out elements of Acceptance Testing to gain assurance that the fix/workaround is satisfactory.

BPO Host Test Packs

The BPO maintains and uses the Operational Acceptance Test Pack, which is a collection of test materials including a standard set of test scripts, test data and expected results.

What Testing needs to be Carried Out?

The testing that is carried out is based on the change/s being made. However, the business risk and scope of the change/s being made can provide good indicators of the testing that needs to be done.

Acceptance and Integration testing are usually carried out on all changes to the BSC Systems. However, the amount of testing required depends on the change and is considered on a change by change basis. This allows the testing requirements for a change to be specified appropriately. Some example questions to determine the scope would include:

1. Does the change affect any interfaces or the flow of data between BSC Systems and other Parties?

Participant/Interface testing is necessary. Consider full integration testing as well.

2. Does the change impact any existing business processes?

Ensure the affected business processes run correctly by carrying out the appropriate Functional, Regression and Operational Acceptance Test pack scripts, or write new scripts if required.

3. Does the change impact any time dependent or performance related processes?

Focus on operational performance testing of related business functions.

4. Does the change involve a hardware or software upgrade that involves interfaces with one of more BSC Systems?

Consider all aspects of Integration Testing – Integration, Participant Testing and End-to-End Testing.

5. Is a full release of the BSC Systems occurring?

Most types of testing will be required. A full release will typically require a comprehensive OAT.

4.Terms Used

Terms Used

Term

Definition

FAT

Factory Acceptance Testing

UAT

User Acceptance Testing

OAT

Operational Acceptance Testing

PPT

Pre-Production Testing

CST

Change Specific Testing

RT

Regression Testing

IVT

Installation Verification Testing

5.References

Reference

Document

Reference 1

Test Management Procedure

Reference 2

Participant Test Service Guide

6.Appendix A – Test Results

Test Logs

Test logs are used to record the high level summary of the test results. The final decision to use (or not use) Test Logs is a decision taken by the Release/Test Manager and is based on the scope and risk of the change(s). The Release Manager should also decide the level of detail captured in the Test Logs. The test log can also provide information on where testers can find the evidence that is related to a particular test. Below is some suggested information that could be included into a Test Log:

Tester

Test Name

Test ID

Time and Date Test Started

Time and Date Test Finished

Pass/Fail indicator

Number of Defects Raised

Number of Defects Closed

List of Defect IDs

Completed Test Scripts

A recommended approach to recording test results is to ensure that the test scripts provide a means for the tester to record whether each test step passed or failed. In the case of failure, the scripts should also provide the means for the tester to record the relevant defect number and a reason for failure. The Completed Test Scripts should form part of the Test Evidence Pack.

Supporting Test Evidence

Test Evidence can be stored as electronic evidence (e.g. data files or screenshots) and/or hardcopy (e.g. printed evidence such signed forms).

Electronic test evidence should be saved in folders that follow the same logical structure as the test documentation. For example, test evidence for Test A, script step 20 should be saved in the highlighted folder:

complex image of process

Hardcopy evidence should be filed in a similar manner. In the example above, the steps in Test A may be stored in a single folder.

Need more information?

For more information please contact the BSC Service Desk, call 0370 010 6950 or email Releases@Elexon.co.uk.

Intellectual Property Rights, Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in Elexon or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make.

All other rights of the copyright owner not expressly dealt with above are reserved.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Elexon Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.