• Platform
    Arrow
  • Industries
    Arrow
  • Resources
    Arrow
  • Company
    Arrow
Make an enquiry
Back
Back

Platform

Interact Application Suite

A suite of pre-built pre integrated easy to configure services that work alongside your system.

Back
Back
Industries

We provide financial services providers, including banks and building societies with the option to greatly enhance their customer-facing digital platforms in an efficient, cost-effective manner.

Back
Back
Resource Centre

Stay in touch with news, views and articles across industry with a technical perspective on digital transformation 

Back
Back
About us

Discover the story behind delivering solutions for the biggest names in financial services for 25 years.

Search the site

Search

Close

Beyond fitness for use – quality and the value chain

Francis Norton on how quality is about the corporate value chain, and how effectively our work and arrangements fit in to this value chain.

Francis Norton on how quality is about the corporate value chain, and how effectively our work and arrangements fit in to this value chain.

fitness for use

Archive

Date

4th October 2018

Francis Norton


It can be useful to think of quality as ‘fitness for use’, and to measure this with quality criteria for bug reports, code and user stories. But I’m going to take a different angle in this post, and look at how a wider picture of quality influences not just the execution, but also the direction of work with regards to the ieDigital Banking Platform.

I’ve been in the business long enough to remember corporate cultures that suffered from ‘silo syndrome’. I still cringe at the memory of one particular company Christmas party, where R&D sat at one table, consultancy at another, and everyone else at a third. You can imagine – if you have a suitably twisted imagination, or have suffered suitably traumatic experiences – how much sand this threw into our day-to-day work. I think that while quality is certainly about ‘fitness for use’ and applicable criteria at one level, at another level, quality is also about the corporate value chain, the streams of product, vision and communication that enable us to deliver something to our clients, which in turn makes it worth them paying our salaries. And it’s about how effectively our work and arrangements fit in to this value chain.

One striking example of something that gives no direct benefit to our clients is time spent configuring machines, whether by developers, QA or operations. In fact, this is a classic source of friction, especially as different departments evolve different configurations to suit their disparate needs, making it ever more difficult to pass software up the line. So, when I was given the task of automating tests for Interact’s Go services and consumers, we agreed to include a requirement that this should require zero (or near zero) configuration.

Let’s see how our Go test automation project contributes to quality in both the ‘fitness for use’ and the ‘value chain’ senses.

Version control

Firstly, Go test automation contributes to quality in the fitness for use sense by allowing comprehensible test definitions like:

Go test automation contributes to quality in the 'fitness for use' sense by allowing comprehensible test definitions such as this example. Image by Francis Norton of ieDigital.

And running the tests automatically in TeamCity, and reporting the results graphically, like:

Reporting results graphically. Image by Francis Norton of ieDigital.

Secondly, it contributes to quality in the ‘value chain’ sense by exploiting Docker to minimize server configuration requirements, and by using a Make file so that any task that has to be executed both by developers and by our CI tool, TeamCity (such as building Docker images from the system under test, importing Docker images of other needed Interact components, and then running them all together as a local test and development environment) are automated in just one way, in just one place (in the Make file, to be exact).

What’s nice about this compared to the traditional approach of hard-coding these steps in TeamCity, is that all this code is now in version control alongside the components themselves.

So while the test side of this task addresses (as it must) quality as ‘fitness for use’, I hope that the work we’ve put into making this build/test/deploy automation portable to all stages of the development/QA /Ops cycle will improve quality in the value chain sense, too.

Related Content

You might be interested in...