Bloggo back to the blog
Community Spotlight Presents James Christie-->
The Community Spotlight is a feature on the EuroSTAR Blog which brings to focus those who matter in software testing industry in Europe – you, the members of the EuroSTAR Community!
We want to give you the chance to get to know more about your peers throughout Europe and share your own experiences, career highlights and some fun facts with the testing community by taking our Community Spotlight interview.
This Community Spotlight features James Christie, James will be presenting a tutorial at this years EuroSTAR Conference titled Questioning Auditors Questioning Testing.. this tutorial is aimed for people who work in regulated environments such as in medicine and pharma, aerospace, banking, finance, and insurance. Check out a video preview of the tutorial here.
2. Where are you from?
I live in Perth, in Scotland. I was born in Dunfermline in Scotland and brought up in Stirling, London and Yorkshire as my parents moved around.
3. Where do you work?
I am self-employed, trying to find work as a consultant. I try to work in Scotland, or on short assignments elsewhere.
4. Can you tell us how you got involved in testing?
I was working for IBM and I got roped in to work as a test manager at the start of Y2K. I knew the client and the applications. In fact I’d worked on developing and testing some of them so IBM thought I’d be a good fit. I hope it doesn’t sound too big headed, but I was a better choice than they realised because they had badly misjudged the size and difficulty of the job. See question 12.
5. How many times have you been to EuroSTAR?
None I’m afraid. I’ve wanted to go for ages, so this is quite exciting.
6. What’s your favourite hobby?
My wife and I are heavily involved in our local church, but I’m not sure that counts as a hobby. I write match reports for Dundee FC (a Scottish professional football team), for their website and match programme. I love that. It’s a great distraction from normal life. It’s great doing something that is so instant. I’m reporting on a match this evening. I’ve no idea what I’ll have to write, but before I go to bed my report will be published and feedback will be coming in. I think it’s quite a useful discipline learning to communicate to very short timescales, but still getting the right story across to the people who want to know what happened.
7. What would you have been if you weren’t a tester?
I’d like to have been an academic so I could write, research and teach. I love all these things. However, I didn’t work hard enough as a student, and I probably chose the wrong subject (economics). If I wasn’t a tester I would be an internal auditor. I enjoyed that for the same reasons I enjoy testing. It’s a huge challenge going into an area that is new to you and building an understanding of what is going on and making constructive comments.
8. Have you any advice to give to a young tester or someone just starting their testing career?
I’ve always been glad I had the chance to work in many different areas of IT before settling into testing. I’m not sure that’s the best way to build a career though. However, it has given me a good understanding of other people’s problems and the wider issues affecting IT. I’ve worked as a developer, business analyst, IT auditor, project manager and information security manager.
I suppose the point I’d really want to get across to young testers is that they shouldn’t think of themselves as just testers. They are communicators and reporters, digging out knowledge to help the right people make better decisions. That requires analytical, interpersonal and communication skills that are invaluable in all sorts of roles. Apart from technical skills I’d strongly urge testers to get to know the business and the people for whom the applications are being developed. You’ll never learn nearly enough from the formal specifications and plans. You need to understand all the surrounding issues that affect the project, the context of the project. Things will go wrong. They always do. When that happens what you really need is an understanding of the business and the people, what makes things happen, why people behave as they do, what buttons to press to get the right response, what not to do. You don’t get that from the specs. I don’t mean testers should become Machiavellian office politicians, but they need to understand how the world works.
9. If you could do a project with one tester who would it be?
There are so many to choose from, but right now the name that comes to mind is Griffin Jones. I’ve been very impressed by the way he’s managed to show how the Context Driven School and the tough demands of regulators like the US Food and Drugs Administration are compatible.
10. If you were stranded on a desert island what 3 things would you like to have with you?
Does my wife count? Apart from anything else she is far more skilled at chilling out than I am. That would be a crucial skill. She’s also had a scientific training in botany and is very knowledgeable about wildlife, so she would be able (at last) to educate me properly about my surroundings. If she’s banned then I’d go for a pair of binoculars (to spot passing ships and wildlife), a big book about the flora and fauna on the island, and a hammock. I’ve always fancied a hammock.
11. What is your favourite motivational quote?
I’m not a big fan of motivational quotes, but I do like this set from CS Lewis, which all fit together.
“Crying is all right in its way while it lasts. But you have to stop sooner or later, and then you still have to decide what to do.”
“Failures are finger posts on the road to achievement”
“There are far, far better things ahead than any we leave behind”
12. What has been your biggest software testing challenge so far?
Nothing has matched the pressure and stress of Y2K. I was appointed as the test manager for a major insurance company’s personal insurance and management information (MI) applications. IBM thought that there were four MI applications, none of which were business critical, and had planned the project on that basis. I knew the client and the applications, so I knew that this was a serious underestimate. I insisted on a thorough inventory, which I led.
It’s probably hard for people to grasp the invisible complexity that had built up in large mainframe installations by the late 1990s. These inventory exercises were enormously complex and painstaking because often there was no documentation defining the extent of applications and the links between them. The only information available was in the code and the JCL (job control language that allowed the operating systems to run the programs). The job was far too big to do manually. I therefore wrote a suite of programs, using SAS, which crawled through the program libraries and production schedules tracking and matching all the input files, table/database lookups, calls, links and outputs.
This established that there were 20 distinct applications with separate roles, deliverables and owners. Some of these were either closely integrated with the company accounts and reserving (a huge issue for insurance companies) or they were required in order to set premiums. These applications were crucial to the business. Others were minor applications which would cause no great problems if they failed.
It took a few months to identify the applications, agree ownership and responsibilities, then plan the testing. So four months after coming into what I had been told would be a tough job with rigid target dates I had demonstrated that the job was far bigger and tougher than I’d been warned, but the target dates weren’t going to shift.
We got through it in the end, on schedule. We had to come up with imaginative ways to test the applications in future timeframes, or rather innovative ways to give the users sufficient confidence and knowledge about how the most important applications would behave. If we’d thought of it as simply a conventional testing exercise we’d have failed. If we’d tried to test everything to normal, reasonable standards we’d have failed. It required some difficult decisions. The sensitive parts of the mission critical applications got hammered in testing. The trivial stuff was basically just fixed then ignored, with a scale of testing effort in between the extremes. The word we kept on using was “triage” and we had to continually reassess and change our plans in the light of the outstanding work and available time. The key elements were; experience with these applications (and understanding of their business role), good judgement and careful handling of the users (who were spooked by Y2K).
Actually, It wasn’t just a matter of good judgement. The job also required confident judgement. There were no guaranteed good outcomes. It was a matter of being able to assess the risk, select the least bad option and then try our hardest to make that work. Some people had great difficulty dealing with that reality. I noticed a tendency to fix on a favoured option, ignore all the reasons it might not work and then insist it was the only possible option that could be considered. I thought that mindset reflected a lack of confidence. If reality is too scary to deal with, pretend that it’s not really that bad, and then you’ve got a situation you feel comfortable with. I thought some people were more or less paralysed in their decision making and became passive victims of events.
Connect with James