Collections & Recoveries

7 test phases in system configuration

7 test phases in system configuration

In this blog, I am sharing from my extensive experience over the last ten years of consulting on major projects in the Collections System space.

Here I take a close look at the process and preparation that goes into the testing of changes to new or existing systems.

What you will find is that testing of your developed code or configuration actually serves as much to confirm your understanding of the business requirements as it does to resolve code or configuration errors.

So, let’s explore the different phases of testing.

7 test phases

  1. Test Approach Document – and a common error

This will generally be in the form of a document that outlines:

  • What is within the scope of testing
  • Test process
  • Level of testing unit, UAT, regression etc.
  • Testing tools to be used such as HP’s Application Lifecycle Management (ALM)
  • Roles and responsibilities of the testing team
  • How defects will be logged, tracked and managed
  • Change process in terms of how any fixes are managed
  • Details of the test environments and what they will be used for
  • Testing sign off process
  • Test entry and exit criteria.

One common error to make is to write the document, get it signed off and never refer to it again. Mistake! It’s essential to keep referring back to the document as you move through the testing phases. This will ensure you adhere to the signed off approach.

  1. Test Plan

It’s important to plan out the testing phases and include in the plan the activities, dependencies and timelines required to successfully complete testing. The plan will also include the number of testing cycles that will be required.

  1. Writing of Scripts

In order to successfully test the system in both Unit and UAT phases, test scripts will need to be written that methodically take the tester through the test.

Typically, the scripts are written in Excel with steps guiding the tester to the positive or negative outcomes depending on the nature of the test.

  1. Requirement Traceability

An important element of documentation within testing is ensuring that all requirements are covered within the test scripts. The most effective way of ensuring their traceability is to link the tests back to the initial requirements using a matrix.

  1. Script Prioritisation

Sometimes due to project time pressures, or because of the vast number of test scenarios, not all tests can be covered. At this point it’s important that a risk based approach to testing is adopted and that tests that are likely to fail or could potentially cause major issues are prioritised over more cosmetic type tests.

  1. Incident Management

Tracking and logging of any testing outcome that does not match with the expected test outcome needs to be logged as an incident. These can be logged utilising a tool such as ALM or QC or even just in Excel if these tools are unavailable.

Not all incidents, however, will necessarily be turned into a defect. You may find that a particular item of functionality is meant to work that way, in which case the test script is incorrect and needs to be changed.

Incidents should be tracked from inception to conclusion, so in order to manage them successfully an incident management process and classification should be introduced including severity status.

  1. Closure Report

Importantly, testing will not find every single bug in any system. This document is key in giving confidence to key stakeholders that the testing has completed sufficient coverage for an implementation decision, as they will be ultimately responsible for ensuring the successful deployment of the application or amendments to it.

The closure report should include all the data from the completed test activities and statistics and an essential consideration is that it should confirm that all test exit criteria have been met.


Need any help?

While these are some of the main considerations of testing, this blog really just scrapes the testing surface. However, it does highlight some absolutely key elements that you must consider when entering the testing phase of any project.

Arum can provide expertise on any testing phase of a project as we have many years of working on major projects in this space and have experienced both the pitfalls and best practice first hand. If we can help you on any aspect of testing, please contact us.

Stuart King – Lead Consultant