Stephen Fice, SQS CEO (Northern Europe, India & South Africa), spoke to Justin Richards about the state of the software quality management industry, security, outsourcing, cloud and professionalism in IT.

What is it that SQS do?

What we’re all about is quality management. In the past you’d have testing as part of the traditional development cycle; you had your usual V model with standard business requirements: detailed analysis, specification, system build, unit, system, integration and user acceptance testing - the test team only really got involved during those latter stages. So what SQS is doing now is improving that process all the way through, so that quality management and testing is involved right from the initial requirements stage.

Now we’re engaged at a much earlier level of the requirements process, so it’s all about making sure that all the different integration points work. Being engaged with and integrated into the project for longer enables us to create a feedback loop that links business requirements and design to the build and testing stage - and testing then starts to really drive the whole iterative cycle of multi-phase releasing.

Testing has an impact in that you’re starting to look at the requirements analysis not just from what the business needs, but also on a detailed enough level to allow the developer to ensure their testing doesn’t become too costly.

What’s your own background?

Well I’ve been at SQS for over three years. My role was initially as MD of the UK business, which expanded out into the COO of the English-speaking part of SQS’s business and then I became CEO of these regions in 2011. Prior to that I spent thirteen years with DST where I was responsible for the process management and imaging system called AWD across the UK, Europe and South Africa.

My role was centred on software, but it was all about business process and implementing software for business process improvement. Hence the rule I’d make to clients was that, if you simply automated a bad business process onto the system, it will still be a bad business process, and all of the flaws you had originally will still be there.

There used to be a lot of hype around an idea called business process reengineering (BPR), which was a buzz phrase about 15 - 20 years ago. BPR is actually about improving the process, making sure the process is right and then implementing that into a system and ensuring that the system delivers.

Today, process management has become embedded in all sorts of applications such as SAP, which has embedded, in-built process management enabling it to sit above legacy systems, such as those used in large financial services organisations.

Around the time of the BPR trend, I was used to dealing with consultancy practices as well as software development teams, so I built up a broad IT perspective. Prior to that, I spent a large number of years working in insurance and finance sectors.

What’s the current state of the software quality management industry and what are the current trends? Where is the industry at the moment compared with, say, five years ago and where do you think we’re going?

The buzz at the moment is around agile; everyone’s talking about it, but very few people are embracing it from a purist perspective. Agile to me is the biggest trend we’re seeing across our client bases. Every organisation is talking about how they can adopt a more agile approach to their development.

In fact we’ve got a conference workshop coming up discussing the differences between pure agile and what we’re calling ‘wagile’, which is waterfall and agile merged, where you’re breaking down the waterfall cycle and doing it in smaller waterfalls rather than one big waterfall.

You’re adopting the more traditional waterfall system, but at the same time adopting some of the agile techniques, but not going down the pure agile route.

How do agile approaches contrast with the waterfall model?

What I mean by ‘waterfall’ is the traditional approach - so if someone says ‘we need a new accounting system’ you go back to them and say ‘well, what do you need the accounting system to do’ and the business comes up with a long list of requirements and from that list of requirements a design specification is produced at a business level. Once the specification is signed off, a high-level technical design, and programs specification are written.

Programs are written based upon the specifications and linked together. Each of the programs is first tested independently and then you prove that they can be integrated together. The final step is proving that the whole system works.

Typically that’s a very extended process and that’s why many IT projects don’t deliver what the business needs - by the time the first deliveries come out, the business will have moved on and what they wanted two or three years ago when they first engaged with the program, isn’t want they want today!.

The whole point of agile is that you’re adopting an approach which is not just giving you deliverables more quickly, but one where you aren’t burdened with the all the traditional, formal specifications.

I’ve worked on projects where there was a wall of specification notes. Agile is all about is having more of a living, breathing project, hence it’s more dynamic. There are daily meetings to discuss progress, as opposed to the more traditional approach whereby a program is developed and the business only sees it on completion.

With agile it’s about adopting a prototyping approach, i.e. from an initial prototype, which may be: ‘does the screen look like it will have all the inputs and outputs needed’. From there, functionality is built up around the initial prototype. 

Within a two to three week period, the agile team agrees the goals, which the business, testers and developers are all involved in, and at the end of that three week ‘sprint’, the outcome may be a fully-fledged working unit of the underlying system.

So why do you think more organisations aren’t going agile?

Well, with the purist approach, the room we’re in now would become the main ‘scrum’ room, information would be plastered over the walls and everybody involved would come in to present what they’d done that day. But, of course, that doesn’t always work in practice, because a lot of people in business have day jobs!

So it’s a case of seeing how we can adopt some of those agile principles, which help business and IT to work more effectively together. Hence a team may adopt some daily or weekly meetings, making them short and sharp, stand-up meetings ensuring that participants don’t get too comfortable and spend six hours discussing a project. I think there is a case for creating more dynamic projects; that’s where I see the agile involvement. 

Some organisations, particularly the smaller, up-and-coming organisations, are adopting pure agile approaches. With our larger business clients, we’re witnessing their adoption of certain parts of the agile approach, depending on the fit within their organisation.

Do you find that security is an issue that software developers don’t take seriously enough?

The teams working at the web-based front end are more security-aware, and ensure that security is a key consideration when developing code for websites.

What we’re seeing though is a trend where more systems are being opened up, hence more back office areas are being opened up to the outside world, whether it be to the public or through a supplier-vendor relationship. So, internal systems are being exposed to the outside world and therefore need additional security.

Penetration testing has been around for a very long time, which is quite a specialist skill, using ethical hackers, but that’s not a service that we’re looking to provide. The service that we provide and concentrate on concerns the broader security aspects: making sure that developers working on the back end develop code with security consciousness in mind.

So, simplistically, that can be from the way they integrate with middleware, (making sure they take into account the security aspects, and consider how they can best protect their code) to how they consider open source and when it is appropriate to use open source.

Are there differences in security within open source and proprietary software and do larger organisations avoid open source because of security issues?

Large organisations don’t actually preclude the use of open source, but the use of open source is becoming more regulated. There have been cases reported in the media where one company has bought another and acquired its software, but found that some of the applications acquired were built mainly using open source code, and so nearly all of the code had to be made available to the open source community, with all the security ramifications that entails.

The buyer needs to understand whether open source code is embedded within the application they are buying, with a value of millions or potentially billions of pounds, and they need to think clearly about the potential repercussions.

So where we’ve seen the change, is away from a scan which says ‘how are we doing’, ‘yeah, we’re doing fine, the open source we’ve got in there is all acceptable’ to making it a part of an embedded code quality process and the system build that occurs regularly, whether it’s daily, every few days or weekly.

What are your thoughts on the whole outsourcing and offshoring trend that peaked a few years ago?

 I would say that about three or four years ago there was a major trend towards outsourcing for cost savings - ‘let’s ship it out of the organisation, let’s offshore it, let’s save some money by throwing lots of cheap bodies at it’. There were organisations that actually spotted that this caused degradation in quality.

I’m not saying that this is the rule, just that there are examples of where it occurred; where money was saved but overall quality dropped and the timeliness extended. Now there’s a move towards what I’d call intelligent outsourcing, which asks ‘when is it right to do that?’

When we look at an organisation, we conduct an offshoring readiness assessment; we’re looking at the application level and the organisational level, so if an organisation isn’t mature enough there’s no point in saying that we’ll offshore your testing. Unless the testing process is clearly defined, there’s little point in offshoring it.

We have been very successful in offshoring large volumes of work for bigger organisations and have done this in several ways. For example, we spoke about agile earlier - so if agile means that testers, developers and the business come together, how is that possible in offshore testing?

If a company offshores testing with SQS India in Pune and offshore development is with another Indian firm in Bangalore, how do these groups work together?

There are ways this can be done with video conferencing and so on, but a business has to have a particular knowledge transfer process that works effectively. A good business process is necessary from the offset - a bad business process which is automated, is still a bad process, but now automated. And the same happens with offshoring.

If offshoring isn’t currently right for a business, we would suggest looking at the process, get the process right, look at how to transition to an offshore organisation, make sure that the knowledge transfer happens at the first point and also that this is a continuous knowledge transfer.

Continual knowledge transfer process between the business and the offshore team is essential. The only way that works effectively is to have ongoing staff rotation, with onshore staff going to the offshore centres and offshore staff visiting the onshore centres.

In our offshore centres, we conduct manual and performance testing overnight so that offshore specialists can work on analysis in the morning. Additionally, there are certain testing capabilities that we can move in their entirety across to an offshore centre. We’ve also introduced the concept of a test automation factory - where a client has a defined set of test cases.

By investing up front during the knowledge transfer phase we can build automation templates and skills that enable us to conduct complex testing efficiently throughout the life of the contract, ultimately leading to more re-use and a lower average cost per test case.

If you were going to give advice to a would-be project manager what would it be?

At the end of the day it’s about making sure that IT has to deliver business benefit. IT projects for IT’s sake ordinarily don’t deliver anything in the long run. There are clearly exceptions to that in the R&D world - you only have to look at the iPhone.

When people first talked about touch screens - how realistic was that? Today, when you look at Microsoft with the Kinect games - how long is it going to be until we stop using touch screens and we just wave at the screens to move to the next slide?

The key thing is asking ‘what’s the business benefit of this, is it improving business?’ whether that’s improving the actual business process, the overall profitability of the organisation or improving the quality of what’s delivered. There has to be a tangible business benefit.

To use an analogy: when I started out, which is thirty years ago, if there had been a 12-story building, the lift would have gone to the tenth floor because initially it would have been a ten-storey building and then penthouses were built on top, but the building owners may have forgotten that the lift didn’t go up to the extra floors.

And that’s kind of the analogy I use for project management because when I started out IT was a little bit hit-and-miss in terms of what it delivered, as I think we didn’t have the focus on delivering the business benefit and the understanding that we’re actually a service to the end business.

I noticed that SQS actually do some R&D - what sort of R&D is that?

SQS is an asset based company. Some companies may ask why they should use SQS as opposed to another provider. We would argue because of the value we add, our specialism and experience which is all available in our own methodology, called ‘practising quality’ - ‘PractiQ’.

This is our own best practice approach, which supports our belief that one size doesn’t fit all. We ensure that our software quality engineers work smart and learn from experience on other projects by referring to our methodology. Hence we build up our asset base, which covers core services such as test analysis and design.

Tools exist which testing teams use to manage, log and process test cases. However, a tester needs to ensure that test cases provide full coverage. You might design a test case that focuses on taking an order through to delivering a product, but what about when you’re looking at the exception to that process, where you’re actually changing a component that’s an input to that process - has that component’s behaviour changed?

In this situation, a tester might then find that the test case is unaffected, but if a component half-way through the process is changed, we then have to look at our own R&D (based around our own product set) in order to ensure that the test case is properly optimised. Is it as complete as it could be, is it giving the right coverage?

We take the techniques that are taught to the testing community, e.g. looking at the tree structure and how many potential different routes there are around a particular sequence of code and adopt a risk-based approach. Therefore our testers think, well, I’m not going to test all one thousand permutations of the path through this process, but I will identify the most appropriate test by looking at what is the best way of doing risk-based testing.

Hence our R & D is focused on understanding the risks and factors such as ‘what does testing mean now that there is a trend towards applications in the cloud?’ So rather than buying software, storing and implementing it on premise, a business is actually buying a cloud based service which a third party provider is responsible for testing?

There’s a different approach to testing cloud services, since more focus is put on understanding how cloud applications will integrate with existing in-house applications.

Businesses need to consider different types of security since data, which was stored in a company’s data centre, is now in the cloud in another company’s data centre. The questions businesses are asking are: ‘how do you know that my data is protected, and how do we work with a cloud provider to be confident in the security levels it is offering?’

How has the modern trend for moving data onto the cloud affected SQS?

We’re working with companies at various stages of cloud adoption, for instance, some of our customers are using software as a service, such as Salesforce, and then it becomes a matter of understanding where the SaaS service (such as Salesforce) integrates with the customer’s business system.

For example, when an order is placed it goes from Salesforce into the underlying business application, so there are still those interface links that are required to be tested. Some of the work that we do, like performance testing, might look at when an application is running at a certain level of load and how it will perform for a certain level of users, with a certain amount of throughputs.

For cloud implementations to succeed, a business needs to work collaboratively with the cloud service provider because we need to know if our element within the cloud is under stress at particular times. In other words, if a business is running at peak, that may be fine if all the other companies within that environment are running at a low level, but if they are also running at high levels what does that mean?

We work with our clients to ensure that they get the level of service that they want from the cloud. Within a cloud engagement, we are more likely to work with multiple vendors. Take for example, in an SAP environment, we’ll not only work with a client to provide testing, but there may also be a systems integrator. In the utilities world, there are multiple layers including smart metering, a messaging, CRM and data mining.

All of those elements have to be brought together in a single integrated end business solution. These situations make our teams think slightly differently, so our consultants don’t have to think about the software that they’re testing; instead they have to think about the environment they’re operating in and the different providers that come into that.

What’s your opinion on professionalism in IT - do you think the industry should self-regulate or do you think the government should step in?

Well, SQS is helping to support the introduction of more standards into the IT industry. We run graduate induction courses for staff who all need to attain the ISTQB at foundation level. We actually provided the training courses for ISEB and ISTQB before they merged. We provide training both externally and to our own staff, so from that perspective our staff are equipped with a basic grounding.

With our own methodology, ‘PractiQ’, we have a certification practice and our employees have to gain that certification and also take part in continual professional development, including re-certification every two years.

As we’re quality-focused, we have to be able to look our clients in the eye and say ‘yes, we’re quality-focused’ and our own internal QA team carries out delivery assurance on our own project teams working for clients – and again that comes back to the independent view.

We strongly believe that independence is important in IT engagements. Whether you could take that down the route of external certifications, such as ISO standards, I’m not sure. Our remote test centres are all certified to ISO270001 for security reasons and to ensure that the build is performed in a secure environment allowing only those people who have permission to enter.

The challenge you always have with IT is the fast moving environment. For instance, how does a company assure that an iPhone app has gone through a quality assurance process?

Apple has its own certification so they’ll only put apps up onto the iTunes store if they’ve passed Apple’s test. But if you look at other sites and check out reviews of other app stores you don’t want to buy from them because often their apps are full of bugs and they’ll only load one in three times.

Overall we need to improve standards and move more toward a more disciplined and professional engineering practice as an industry.

Whether or not I believe the government should step in and do that, I’m not sure. I think it’s more about introducing standards within the industry that we can all agree to adopt.

What would you say has been the technology or trend that has arrived within the last few years that’s had the greatest effect on the industry?

In terms of trend I think it’s the continuing evolution of the internet. When I look back to the days when I was first dealing with process management systems we didn’t have any external client access, so the business process just involved the service centres where the customer interface was receiving a letter in the post. Compare that with now, where you have so much online self-service.

I think the challenge facing the industry today is that it’s possible for me to access the same account from home, an iPad or iPhone etc, so I can have that account open three times simultaneously and that creates an instant challenge to the industry. I don’t think all the industry has wised up to and fully understands the potential impact of that.

When I started out, my granddad used to say to me, when I was coding, ‘what exactly is a computer?’ His conception was of something off of one of the BBC’s old science programmes. But now the microprocessor is part of so much of what we all do.

I recently took a circuit board, which had failed in my boiler, to be recycled, and the man at the centre asked ‘what it is - a PCB from a computer?’ It just goes to show that there are so many different components on a circuit board - it’s the intelligence that goes into almost any device these days that’s astounding. It’s ubiquitous.

In my previous company, the R&D section used to look at trends and there are always two ideas that really make me laugh because we’re there now. There was a toaster that would print a picture of what the weather would be like on your toast, so you could see if the weather was going to be cloudy.

Gimmicky, I know, but today you can look at your phone to check on the weather for the next few hours. The other one was a toilet that would test what was going through for diseases, which appears fairly far-fetched, but now there’s so much technology in medical processes that it’s actually not all that far-fetched. I doubt if every home will have one, but it’s an interesting and now fairly believable concept.

When mobile first came along, you had to have a SIM card, you had to pay for a SIM card and you had to pay for every single piece of data that went through it, but now operators are offering devices for life. If you look at the Kindle, you’re not paying for the usage on that - there’s a limit to how much you’re going to download, as there’s a limit to what anyone’s going to read.

This is an interesting change for the mobile providers: there’s a move away from a pay-as-you-use basis to a let’s-look-at-that-and-make-an-assessment-then-charge-on-that basis. There are so many devices and objects nowadays which you wouldn’t realise contain a SIM card.

Can you tell us more about your training programme and why you think it’s important to encourage young people through their learning and development?

 For us it’s a way of getting bright, capable people working for SQS. They don’t have to be graduates, but typically today they are. We ordinarily, but not always, take people with computer science degrees, so we’re looking for those with a technical bias and also those with a business bias because we run the concept of innovation groups amongst our consultants. Those innovation groups are all about getting people together who have a special interest and some of those may be business-related.

We need people who can test and understand a swap trade, for instance, and see how that will integrate into a settlement in the same way that we need people who understand how code is put together and would then understand how that system would perform from a technical perspective.

We need to have both business and technical skills. So it’s not just about teaching our new recruits how to test, so they don’t only know how to run a test process, but they need to be actually thinking like a bug hunter - thinking, where might there be an error in this code?

I was talking about games testing yesterday and in that context you’re always looking at the barrier on the game space and looking for holes in the wall where you can get through and find shortcuts, where the coder has left a gap. When our teams are given the code, we give them the ability to make a risk assessment in their own head and think about where there might be issues.

This is something that, with experience, you learn - so we teach them that on our internal course and they finish it not just as capable testers, but also capable of identifying problems and thinking for themselves in the approach that they take.

A lot of people had a strange image of IT. My family used to love Jasper Carrot as he did this sketch where, when he was a character in a night club, he’d say: ‘Hi, I’m a computer programmer’ and my family used to find that hilarious because that was what I was! But you don’t hear that so much these days. Now people in IT are often viewed as being a bit of a nerd.

I look at America and they still pride themselves on having that real IT drive, but to some extent the UK economy has lost that and I think we need to get that pride back because it’s so important. At SQS we use companies such as ARM, the chip designer, and Formula One as examples of improvements in quality.

Twenty five years ago the last driver that died in a race was Ayrton Senna. Before that, a racing driver had a one-in-four chance of dying during a season and a fifty per cent chance of surviving through a sensible driving career. That’s crazy. But if you look at what’s happened in Formula One today, you can see how technology has made it so much safer.

In general, in IT, (and not necessarily in the specialist areas like F1), we’ve just assumed IT will happen and let the offshore providers get on with it and we’ve been fine with that, but how many British software companies are there, of any real value? There aren’t all that many.

How do you think we can get away from the geeky concept of working in IT and do you think changes should be made to the way IT is taught in schools?

My nephew did an IT course in college and, based on my knowledge of that, I’d personally say that too much of what we teach in school and at college is based around the core applications - we teach school children to be competent in using Microsoft products, we don’t teach them to understand how technology actually works. We don’t create that excitement.

I’ve talked to my daughter’s headmistress about generating that excitement in IT. I’d like to see school children being taught how to actually develop programs and apps.

Going back to my nephew, who was 18 when he started the course, I said to him one day, ‘do you know how data’s stored?’ and he didn’t know the difference between a bit and a byte or that everything we do is, simplistically, down to a switch being on and off. He didn’t even have that basic understanding.

Going back to a previous life, in insurance, one of the things I did there was to give a training course to the business so they understood what IT was and how it worked. I think there isn’t enough of that anymore and people don’t understand how all the whizzy technology they use every day actually works.

I suspect very few people realise that in their Sky Plus box there’s actually a hard drive; there needs to be a way of explaining IT so that people can relate to it. For example, I was trying to explain to my parents about an iPad and how it worked and they didn’t get it at all, but when I started relating it to using a digital camera, storing photographs and memory cards they started to understand.

There was an engineering day where students were taught how a robot works, but those same students are not told how their own computer works!

Did you have a role model who got you into the IT side of things?

The person who gave me an interest in technology and set me in that direction was my father-in-law. I married my childhood sweetheart and my father-in-law was an ex classics teacher and he decided you can never make any real money doing that so he went off to do IT and he ended up working in Zambia, in the early sixties, working for ICL and when he came back he showed me all kinds of things, so I guess he was who gave me that sort of direction and career guidance.

I didn’t go to university, which is something that is a huge regret to me now, and when I stop working I will take that degree I’ve always said I would, in geology, which is what I wanted to do originally. But my parents used to say ‘what on earth are you going to do with a geology degree anyway?’

When I look back on it I kind of think they were right because, as a geologist, you end up being sent to far-flung places to do stuff and that’s not really the kind of guy that I am, although I’ve still ended up travelling the world with SQS and also in my previous roles.

What I actually found was that I had a natural aptitude to IT - I remember programming on a calculator - I had a calculator that would programme up to 160 steps and I could programme it to do all kinds of things. I would take a quadratic equation and put it into this calculator and it would come up with the result. This is predating the early computers, so I’ve had that interest since when they were just simplistic devices.

Is there anything, looking back, that you’d do differently now?

Going through my career, for what I’ve done with that technical background I had, I think all I’d like to do more of today is be a bit more hands-on technically than I currently am.

I am still the network engineer for my house, which involves three computers, and I can still help my wife out with her access database when she has problems with that (she’s a historian). But it’s a long time since I wrote some genuinely raw code, which I regret.

When you get to senior management roles you don’t have the time to do that. It’s important to stay close to the technology that your clients are working with, I think. I learnt how to write in BASIC on my own and then I was taught how to write in COBOL, but there’s no COBOL of any significance being written today.

For upcoming graduates and students looking to get into the IT industry what advice would you give them?

I would say don’t be frightened of it. There is that fear that all IT must be difficult to do, but actually, when it comes down to it, everything is relatively simple underneath; it’s just the veneer that makes it look very complicated.

Quick questions

Open source or proprietary?
Five years ago I’d have said proprietary, but nowadays I’d have to say open source.

Apple or PC?
I’m an Apple fan. It works! 

I have to admit that today the Microsoft operating system is much better, but looking back, the process management system that I did, we originally had to use OS 2 because the Windows Microsoft operating system wasn’t capable or reliable enough to do the job. The original release of Windows was so full of memory leaks, so I guess I was slightly biased against it.

The Mac that sits on my desk is a single bit of kit with a plug and a network cable, but the computer I’ve got at home has I don’t know how many different cables coming out the back of it, from a big box to a screen, and I just think the Mac is how it should look!

Wii, Xbox or Playstation?
I love the Wii.

Blackberry or Smartphone?

Geek or nerd?
I’m a bit of a nerd! I’m not too sure about the difference though.