Article | Platform Defects

AHEAD | Talking the same “defect currency” when it comes to Platforms

Andy Ewell explains how managing defects in the platform space requires special consideration to ensure effective delivery.

Websites, blogs and journals are awash with commentary about the problems of poorly constructed approaches to defect management.

Statements that projects are won or lost on the ability to manage defects are far from original, however with large scale programmes increasingly delivering solutions based on the products of multiple external vendors it’s hard to disagree with the sentiment.

Solid defect management during the testing of a financial platform, where change is frequent and the product and proposition is so visible to the end client is an absolute must.

The Platform Landscape

Platform developments share the following characteristics which need to be considered when dealing with defect management;

  • A number of large external suppliers providing the client with a configured or customised COTS products encompassing applications and interfaces;
  • Suppliers with disparate defect tool/process which they are reluctant to deviate from;
  • Limited integration environments where configuration, data and code including change is aligned;
  • Frequent deployments through test and production where completion of testing is often the critical path;
  • Production deliveries accompanied by a residue of outstanding defects which need to be addressed in parallel with ongoing change;
  • Defect numbers for a release typically in the hundreds;
  • Change impacting multiple functions increasing the likelihood of functional blockers in end to end processes;
  • Business units keen to engage in new project change but held back due to Business as Usual commitments.

For Programmes of work involving local development, delivery dates for the solution can be aligned and managed internally with resources being committed as required to hold the plans. Here testing becomes a determining factor in the overall end date.

In the testing of platforms it is necessary to factor in the suppliers defect lifecycle and the availability of supplier deliverables to establish the true timeline, taking into account supplier resources will be committed to supporting a number of customer requirements in parallel.

These commitments cross new development and business as usual support and production Service Level Agreements routinely divert resources from Programme and project delivery. This conflict of interest coupled with the different demands placed on each supplier makes aligning product deliverables difficult.

A further complication in the platform space is establishing agreement as to responsibility for change and understanding the suppliers release cycle.

Revisiting existing defect management practices for a Platform environment

Existing defect management practices present issues in a platform environment and often only manifesting themselves late on in an IT Programme;

  • Without robust upfront design, defect management information is ineffective and doesn’t provide stakeholders with a focused group of defects to ‘zoom in on’;
  • Time and energy is wasted reconciling numbers between internal and supplier tools, rather than presenting a single view of the truth and collaborating to resolve the defects in the shortest time possible;
  • The Business are often forced into accepting defects into live as a Programme runs out of road because of a failure of the Programme to engage early enough and so understand which defects need focus and which can be lived with;
  • Existing processes put pressure on the suppliers to circumvent their internal test process to and ship defect fixes earlier, leading to increased quality issues.
Addressing the challenge

When designing a platform defect management approach there are a number of critical success factors to consider, here are my top 3;

1. Understand how the project will accept the software into production before the defect management tool is configured

  • By understanding acceptance criteria upfront, it is easier to identify the data items required to configure so that effective defect management information is available

2. Take time to understand in detail suppliers internal defect methodology and terminology

  • Forcing a supplier to change their internal approach to fit around your defect management process can often lead to issues so be prepared to compromise
  • Everyone must be able to talk in the same currency and agree defect numbers
  • Understand the supplier identifier for an accepted functional defect. Once its accepted and through the triage processes, you don’t need to worry about it until it lands back into test
  • Establish and agree code cut off points and factor these into the timeline

3. Create an acceptance process for signing off into production unresolved defects and configure the Defect Management tool to allow you to operate it from outset

  • Identify core, empowered individuals who can accept defects (and put their names in the tool for all to see)
  • Once defects are fully analysed, get in the rhythm of regular walkthrough with the acceptance group of medium and low priority defects with the aim of getting them accepted. If there is time to get them resolved great, but if not, you already have approval and can therefore focus your time on other more pressing defects
  • Conduct interactive demos of the defects to the acceptance group as this not only improves the upfront defect analysis (if they know they have to present them) but it also provides the acceptance group with the context
How can we assist?

AheadMG has experience in testing large scale programme change within the financial platform space for many years. This experience has allowed us to develop considerable understanding in test and defect management with particular emphasis on platforms.

Our offerings provide tangible, positive and long lasting benefits to our customers, carefully balancing cost factors with the need to continually improve. Let AheadMG help develop your test organisation and at the same time provide assurance that the systems you and your customers rely on meet the needs of a modern and more expectant user base.