Detailed CV

I led significant system stabilisation, delivery acceleration and quality improvement on a large, deeply challenged programme, inherited from a previous supplier. Over ~20 months, I was deployed to teams with greatest need. 

The scope of the programme was BA's CRM system (actually multiple subsystems), handling many customer cases and integrating with dozens of other systems around the organisation. I initially led the programme's platform team, before initiating a restructuring. I then worked on two key subsystems, one API integration system in AWS and another data processing system, migrated from Heroku to AWS during our time.

The challenges we faced upon joining were the most significant that I or any of my colleagues had ever experienced. I am refraining from writing a full list of issues here, but they reached into every aspect of the product and project, were daunting in their scale and kept us very, very busy. The team did (and continues to do) an excellent job in facing up to those challenges and driving positive change in a difficult environment.

Key to my role was winning the trust of client stakeholders, to gain their support for the significant change that was needed.

Although this project was quite a way off reaching the high DORA metric scores that I would aim for, the progress that we made in a short space of time cannot be overstated. It appears that the way has been paved for a significant, long-lasting partnership with the client.

Key achievements: 

• Restructured programme teams to become more cross-functional, allow more DevOps efficiency and self-sufficiency.

• Overhauled a complex, programme-wide release process to halve the time-to-live. 

• Brought reliability and observability to a severely unstable DB system, ending business disruption.

• De-risked and delivered a regulated decision-making engine in a short timescale for faster customer service. 

• Drove initiatives to fix engineering fundamentals and quality assurance practices across multiple suppliers. 

Tech: 

• Many familiar AWS services, like Lambda, SQS, API Gateway, CloudWatch, Step Functions.

• Introduced to Kafka, used as a queuing mechanism for data updates.

• AWS Aurora

• Splunk

Teams:

Although it would be nice to settle into a team for the long term, this programme required rather a lot of change across various teams in a short space of time. There were different strengths among the delivery managers, so we were occasionally reshuffled. I was deployed where problems existed that I was well-placed to help fix, as described below.

• Platform team, first 3 months, then structural changes. 

The concept of a platform team can work in certain scenarios, but the structure that we had inherited was not such a scenario. There was major overreliance on this central team, unnecessarily and with many detrimental effects. 

I spent the first three months supporting this team in the very difficult situation we had inherited, bringing more order and efficiency to a highly manual, varied workload. The volume of tech debt was such that it was difficult to find time to address any of it. It quickly became clear that there were fundamental structural flaws that would need to be solved at a programme level, so I initiated some changes. Rather than having almost all of the platform engineering expertise, for three separate systems, siloed in one team (and too busy fighting fires to do much engineering), we needed to distribute that expertise and make existing 'dev' teams into more cross-functional DevOps teams. For two of the subsystems, whose teams were under BJSS leadership, this was straightforward and immediately successful. 

The original 'platform team' then evolved to mainly provide support for one subsystem (Salesforce), which had multiple dev teams from other suppliers and was a reasonable candidate for the 'platform team' pattern. They also retained some programme-wide oversight and influence, but now had a much more manageable and sensible scope, with other key teams empowered to be largely self-sufficient.

• CPM team, 9 months. 

Following the decentralisation of the original 'platform team', I moved to a newly cross-functional team working on one of the programme's major subsystems, which involved a large DB and various interfaces, constantly receiving, processing and pushing data between other systems. Due to design flaws (very complex, poorly-performing SQL jobs) and a lack of modern guardrails (CI/CD, monitoring, tests), the system was highly unstable, needing constant manual intervention, which was not sustainable. At the time I joined, outages were happening most days, with real business impacts. The first few weeks were spent getting a grip on the situation and tracing the causes of the problems. We restored relative stability and stopped the frequent outages, but in the process we had uncovered a huge volume of tech debt and flawed design, which we shared with stakeholders - these findings later informed business decisions about reforming the wider system. 

One of my early contributions was to produce system monitoring dashboards, without which we would have been flying blind. Over a few months, we also improved our team's agile ways of working, started introducing better DevOps practices and optimised the team composition further. After about 6 months, we had become a very stable, productive team on a great trajectory, able to deliver much-needed system improvements at a steadily increasing pace. I was sorry to leave the team after nine months, but I had been set a challenge elsewhere...

• EU261 Compensation MVP delivery, ~2 months. 

The other major subsystem under BJSS/CGI leadership was the 'Integration Platform'. A team had been working (before I joined them) for a few months on a new service within that system, which would make automated decisions on compensation eligibility. To do that, it would need to consume data from various sources (e.g. weather, flight timings and disruption) and apply logic rules. The logic is governed by regulations that protect customers in certain situations. This new service would give real-time decisions for customers, replacing previous mechanisms that were not so well joined-up, often being slow and needing some human input. As is often the case with such things, confirming the rather complicated logic requirements had proven tricky and MVP delivery was somewhat at risk - there was quite a lot to do in quite a short space of time. The urgency stemmed from the planned decommissioning of another system in the organisation's estate. 

I joined the team about one month away from the target date, to help derisk the MVP delivery and communicate closely with client stakeholders along the way, so that there would be no surprises. We did deliver the MVP on time, having made a few changes. Firstly, there were a few immediate efficiency gains to be made, ranging from meeting schedules to slow CI/CD pipeline steps - these time costs all add up. I introduced better observability to the product, as this is critical for enabling efficient dev-test iterations, as well as giving us and stakeholders the confidence that comes with actually being able to see a new solution in action. Clients appreciated seeing charts of the compensation decisions that our engine was making. I helped the team to streamline ways of working and to stay focused on the MVP priorities. Having already built trust with key stakeholders from previous work, I was well-placed to give them a clear and honest picture of how things were going, including the risks and difficulties. The successful delivery was well received and we spent a few more weeks supporting the live service and further developing it, until we merged this team into the core 'Integration Platform' team.

• Integration Platform team, remaining  ~6 months. 

This was a fairly big system that joined up the other CRM subsystems and many others around the organisation. It did this mainly with a vast array of Lambda functions (and a few other components, like queues) that consumed or exposed APIs. Although it was quite big, it had not been architected in a way that allowed for parallel teams to work on modular sections of it without heavily treading on each others' toes, so I was always keen for a one-team approach in the short term and a gradual modularisation of the system in the longer term, which was happening slowly. When the EU261 MVP team wrapped up, we merged with the core IP team and I took on the leadership of it. At that time, there was another parallel team doing some large-scale refactoring work, in close collaboration with our core team - not an ideal situation, but a pragmatic solution to some large problems at the time. That team later merged with us too, so the goal of 'one system, one team' was mostly achieved, but for a few lingering services under the care of completely separate teams, waiting to be shifted out into other AWS accounts.

This IP system probably carried the largest tech debt. Hundreds of small features had been developed in hundreds of separate Git repos (prototype style) without any feasible strategy for long term production support, maintenance and future development. DevOps capabilities and safeguards (tests, pipelines, monitoring) were largely absent, so any change was both very slow and very risky. Widespread maintenance, such as security patching, was almost impossible. Fixing this situation was the task of the parallel team that later merged with us, once the bulk of their work was done. They were grouping these disparate code projects into a smaller set of sensibly themed repos with basic CI/CD pipelines, adding a minimal amount of unit testing along the way. Their work did not fix all the problems, but it made it possible for the core IP team to begin fixing things.

Our team's work was a mixture of business-driven new feature delivery and engineering-driven investments to make that delivery easier, faster and safer. Continuing on a theme, I introduced new monitoring capabilities for the Integration Platform, demonstrating a pattern for API monitoring that the team could later extend over the hundreds of endpoints. Being able to see more clearly what the system was doing and where it was failing, in any environment, was (as always) extremely valuable. I also helped the team to become more efficient in their agile ways of working and to improve their assurance practices and audit trails - not extra overhead, but efficiency gains, in a situation where disorder and disruption desperately needed to be avoided.

• Release process overhaul

Alongside my work with the Integration Platform team, I was working with clients and other managers at a programme level to overhaul the inherited release process, which involved a four-week lead time, a waterfall-style testing period and a two-week release cadence, meaning multiple overlapping release candidates in existence and a great deal of complexity and risk associated with the inevitable release fixes and hotfixes.  For example, if a hotfix were required, it might need to be compatible with four target branches (the live version plus future release versions), which can be very complex and very risky. 

The goal, which was achieved, was a two-week lead time, avoiding the overlaps. This sounds simple on the surface, but in this complex programme environment it was a huge challenge, which made good use of my existing trust amongst stakeholders, my assurance specialism and my detailed, hands-on knowledge of the existing release processes. Making the shift without business disruption required a careful plan to gradually compress the timings of key events over several weeks, working within various constraints and avoiding clashes. I presented this plan visually and sold it to stakeholders. A complexity was that parts of the programme (mainly those involving other suppliers) were still relying on a pre-agile, siloed, manual testing team, which conducted a full, manual regression test before every release. The problems with this pattern are well understood and don't need to be described here, but needless to say the costs and risks outweighed any value. I set out guidance for a step-by-step modernisation of assurance practices across the whole programme, starting with the basics that would allow testing (and testers) to shift left, into the dev teams and the earlier stages of the SDLC. The CPM and IP teams that I had already worked with were capable of handling their own assurance in an agile way already, so although they needed some guidance still, the bigger changes would be in the other teams. As predicted, things did get better and easier as we moved through the plan - a big success. 

I left the programme to go on a planned sabbatical at the end of February, 2026.

We delivered a gen-AI chatbot for the BJSS website: a virtual advisor on software delivery topics, rooted in the BJSS book 'Enterprise Agile'. It was a 'Retrieval Augmented Generation' (RAG) bot, produced with Microsoft Copilot Studio - still very new at that time and under rapid development by MS. This was an exciting project at a very interesting time for the industry.

I joined a team that was already exploring options, but was undecided and needed a path to delivery. I set the focus on an initial MVP using Copilot Studio - the simplest available option with likely viability and lowest risk. The MVP was successful in around 2 months and went live on the public website shortly after.

The bot's purpose was to signal our interest in new AI capabilities to prospective clients, as well as raising awareness of 'Enterprise Agile'. We also demonstrated its practical uses as a virtual consultant and advisor. Although the product was primarily a fun marketing tool, LLMs bring risk, so mitigation and governance was key in this project.

Part of the value of this project was in experimenting with emerging AI technology and building our own experience, to better serve clients. I shared the lessons we were learning along the way through blog posts and made a demo bot available to the whole company well before public go-live, to crowd-source testing.

I was heavily involved in tuning the bot's behaviour, which required much experimentation and iteration of its instructions (prompt engineering). We achieved behaviour that was on-topic, positive about BJSS and avoided controversial or sensitive subjects. Our instruction tweaks even suppressed some recurring hallucinations that MS Copilot was suffering at the time.

Reporting to the very top of the company, I documented and presented the benefits, risks and mitigations associated with the product, considering, for example, the OWASP top 10 for LLMs. AI governance was a new concept at the time, so this was a learning experience. I obtained MD approval and worked with our marketing team to integrate the bot into the live website (HubSpot). 

I managed an 8-week discovery exercise ahead of a proposed replacement of a legacy system handling a highly complex legal process. 

The discovery resulted in the successful initiation of a delivery project (by which time I was on the BA project). 

I led significant remediation and new feature delivery for a critical payment system project, which was previously troubled, but became an exemplary success story within the client organisation.

The quality and pace of delivery was transformed by modernising the whole project, resulting in the capability to develop the system rapidly and safely while achieving top scores in all DORA metrics. We demonstrated continuously accelerating delivery over the three years.

The payment system handled ~4 million payments per year with 200k API requests per day, serving 5 client systems with various outward-facing governmental roles.

I drove major fixes, performance improvements and cloud cost optimisations, as well as major new features, such as a data retention (deletion) mechanism that handled complex data scenarios, regulatory requirements and database performance considerations.

Year one: Set the course towards effective quality assurance, CI/CD and other missing DevOps practices. Personally developed a much-needed new API test suite. Streamlined ways of working, began reshaping the team. Fixes and improvements began to stabilise the system.

Year two: Refined CI/CD and test automation further, so the path to live became much more efficient and safe. Careful selection of new joiners led to a high-performing, close-knit and successful team. Introduced sophisticated monitoring capabilities with highly valuable results. System improvements continued and more interesting new development began.

Year three: Delivered major new features at pace. The pace of delivery continued to accelerate, thanks to ongoing DevOps practices (CI/CD, monitoring, test automation, leveraging serverless cloud capabilities, etc). Welcomed client staff into the team for a smooth and successful 9-month handover and coaching period.

Our engagement then completed as a major success, leaving a vastly improved product and a slick delivery project machine in the hands of our well-prepared client colleagues. 

Tech: 

As we inherited it, the system was hosted in AWS with an RDS PostgreSQL instance and the main API application written in PHP, hosted in EC2. Standard AWS services like API Gateway, VPC, WAF, load balancers, etc, were used. There were also some SQS queues used, although not very well designed. A few Lambda functions were used to manage those queues. AWS config was managed in Terraform.

The existing automated API test framework was written in Ruby, but had been poorly maintained by various iterations of the team from various suppliers and was sadly unfit for purpose. It took 90 minutes to run, almost always reported false failures and did not provide very good test coverage anyway, meaning significant manual effort before every release, no useful feedback at the time of development and inevitably high risks. 

I immediately started replacing the API test suite based on a pattern that I had used successfully in the past: Java, with TestNG as the runner and RestAssured handling the API requests and basic assertions on responses. I wrote a wrapper around RestAssured so that I could conduct more sophisticated tests involving several requests in succession, replicating user journeys (which would be messy in pure RestAssured syntax, which is suited to much simpler tests). The pattern could be described as an 'endpoint object model', taking inspiration from the 'page object model' used in web UI testing. Tests ran in parallel and their ordering was tuned to minimise overall runtime. Typically, they took around 5 minutes, sometimes a few minutes longer - we considered this to be very good considering the quality of the coverage. We always looked to make the feedback as fast as possible, but the bottleneck wasn't so much the tests themselves, rather some poorly performing asynchronous mechanisms that we had inherited in the product itself, some of which we did have the opportunity to improve during our time.

In the latter half of the project, when we were developing new features, these sometimes involved new (micro)services written in TypeScript, running on Lambda functions or Step Functions (state machines). The move to serverless, managed infra was highly desirable, as portability was of little concern, whereas maintenance overheads were an existing problem that was a priority to avoid in future. A good use of step functions was in improving the reporting mechanisms, including adding a new 'scheduled reports' feature. Internal financial ops staff needed to extract data at certain times, but the previous mechanism had been slow with limitations - big reports, or too many parallel reports, could crash the system. We identified and removed the major performance problems, then managed report generation via an asynchronous queuing mechanism that was reliable. Reports could be requested on demand or scheduled according the organisation's needs. When scheduled reports were produced, automated emails were sent to the relevant people, with a secure download link.

The existing tool for workflow automation was Jenkins and I became very familiar with it, developing CI/CD pipelines as well as automating other operational jobs like patching. It wasn't the most modern tool on the market, but it was already hooked up and had plenty of capability and flexibility to do anything we needed. Later on in the project, we created new services with their code and CI/CD pipelines both in GitHub (automated workflows in Actions). A simple but valuable addition to the pipelines was automated Slack messages when pipelines needed human approval, or when notable events were occurring that needed the team's awareness (e.g. something is being done to prod).

It was during this project that I first started making major contributions to system observability (AWS CloudWatch), which proved highly valuable (for many reasons, which I intend to write about elsewhere!) Although observability is important in any system, it's particularly important for an entirely back-end system, where there isn't much else to look at. Once you have a few nice dashboards, you can show your system improvements (performance, error rates, new functionality) to clients, for whom your work would otherwise be entirely abstract. With hindsight, improving observability was so valuable that there would have been a case for doing it before the much-needed automated tests. This was a lesson I took into later projects.

This project delivered a modern solution for aviation route planning with a tight deadline in a strict regulatory environment. With a responsibility for assurance, I led initiatives that improved quality and the pace of delivery, enabling a successful product launch. 

When I joined, this running project already had a strong product design, but challenges and risks around the quality and pace of development. Improvements in assurance were urgently needed to derisk delivery, as well as to meet formal regulatory requirements for aviation software (ED109). I made assurance a whole-team concern, guiding and coaching engineers with less formal test experience. I changed ways of working so that testing was considered upfront and executed more thoroughly, catching issues earlier. I raised the standards of documentation and reporting. 

Throughout, I and other test engineers worked on expanding automated test coverage, remediating past tech debt to reduce risks and manual effort. 

BJSS (later CGI) continued to expand and evolve the product with subsequent contracts over several years. Much of the assurance practice and guidance that I had put in place lived on, helping future incarnations of the team to handle the formal assurance requirements in this industry.

Tech: The back end, front end and automated high-level tests were all written in Node.js with Flow typing - a choice that was made before my time and was regretted by most engineers by the time I joined, at least for the back end and the tests. The front end was a React web app.

There were two high-level test suites: a UI test suite involving WedriverIO, running against BrowerStack, and an API test suite. Both needed a lot of work. One of the improvements I made was test parallelisation, which was valuable in speeding up the feedback loop, but involved considerable refactoring, to avoid parallel tests from sharing state and clashing.

The product was hosted in AWS, using Lambda functions to serve API requests, with a PostgreSQL DB underneath it all - my first experience of these specific tooling choices and good preparation for future projects where similar things were in place. My existing (T-)SQL experience was transferable and proved useful - one of my first tasks on the project was to help improve query performance.

Domain: This project was certainly in an interesting domain. Its scope was military aviation in British airspace. The app showed a map of the country, with layers of information that pilots needed to know about. Pilots use the app to create and view route plans.

There was a feed of information from an existing system and a big part of our product's job was to ingest, parse and display that information.

One of the key pieces of information is a 'NOTAM' (Notice to Airmen), which represents a hazard that pilots need to be aware of. It has coordinates, a radius, a start time and end time, plus other information. These would be displayed as circles on a map and routes could be planned around them.

NOTAMs indicate all kinds of hazards: tall cranes, hot air balloon flights, firework displays, to name but a few. There are some special types, like SNOTAM (snow), ASHTAM (volcanic ash) and BIRDTAM (flocks of birds).

There are other types of information that need to be shown too, including weather, airfields and waypoints.

The information that the app deals with comes in very legacy data formats, which predate modern IT by a long way. Their structures are miles from anything you would design today -  often rather difficult to parse either by machine or by hand. Accurately parsing and displaying the information was, of course, a source of complexity in the development and testing of this system.

Planning a route involved joining up existing waypoints or adding custom coordinates. The app could highlight relevant NOTAMs along the way.

A deep, rounded understanding of how projects should run comes from seeing both good ones and bad ones. Having seen questionable practices for a few years, the timing was ideal to be part of this really good project, which answered the questions and set the course for the next several years of my career.

Background

NHS Digital required a new solution for gathering data for the Directory of Services, which is the data source for NHS 111. The focus was on pharmacies for two main reasons: Firstly, there was a financial incentive for pharmacies to regularly update their DoS records, costing several million pounds each year. Previous low-tech solutions had resulted in very little good data ever reaching the DoS, effectively wasting most of that money.  Secondly, pharmacies offer a surprisingly wide range of patient services and are capable of taking pressure off other NHS services (GPs, etc.), saving extra costs, but only if patients can be appropriately directed to those pharmacy services, which requires complete and accurate data in the DoS.

So, an efficient and effective data-gathering mechanism would improve care for patients and alleviate pressure on core NHS services, returning the desired value from the multi-million annual investment.

Project

BJSS provided a small, highly talented, cross-functional team to develop an MVP at pace, going live in 3 months. We were the first BJSS team to work with the NHS Digital Exeter office - a relationship that soon grew considerably. 

DevOps practices were applied with great effect from the outset -  Azure cloud, CI/CD, test automation - in an organisation that was generally unfamiliar with them, even sceptical. At the time, the client was accustomed to on-prem deployments and had forecast 6 months to provide us with a server - not a suitable timescale. Attitudes were gradually changing and it wasn't long until NHS Digital started its own major DevOps and agility drive, including project Texas and agile coaching, also fulfilled by BJSS. Our Profile Updater project was ahead of the curve and served as an example.

This was my first BJSS project and a highly formative one, setting a bar that plenty of projects still struggle to reach in 2026. At the start, my role was as a test engineer, so I was required to quickly learn Java (plus Selenium, Cucumber, Git, Docker, and more!)  and immediately contribute to test automation, applying my existing skills in general test design. I was guided by more experienced colleagues who set very high standards and encouraged all the behaviours of the modern, adaptable, delivery-focused engineer, such as self-teaching, experimentation and contribution beyond arbitrary role boundaries - things I have advocated ever since.

The MVP was a web app that pharmacists would access, first verifying their identity, then reviewing and updating information about their pharmacy's services. We developed thorough automated tests in parallel to the product and ran them in CI/CD, which provided fast feedback and a reliable guardrail, so we had the confidence to move quickly.  Meeting the ambitious 3-month target proved that investments in such enablers can deliver huge value very quickly and should never be an afterthought.

After a few months, my primary mentor was reassigned elsewhere, so I became the assurance lead and the new team lead from a BJSS perspective. We had light management oversight from both the client and BJSS, but I was the bridge between the team and those stakeholders, coordinating my teammates, reporting on our progress and managing occasional leavers and joiners,  for example. This was my first step into project leadership.

We went on to make the product more sophisticated and automatically send data updates to the Directory of Services in real time, meaning more value for patients and the NHS, with less lag. 

A big area of focus was UX. The easier it was for any pharmacist to understand and use the tool, the more complete and accurate (and therefore valuable) the gathered data would be. The challenge was that the data structures our users needed to review and edit were not inherently intuitive, so thoughtful presentation, instruction and validation feedback were needed. I and other engineers participated in user research with real pharmacists, opening our eyes to issues around IT literacy and the tech confidence that we engineers sometimes take for granted. The value of upfront and continuous user research over belated UAT was abundantly clear. I was interested in UI design and contributed to it considerably, as well as iterating the on-screen instructions to be as plain, clear and concise as possible. 

I carried out additional analysis of real user behaviour and product usage. Although I was playing catch-up on many tech skills, my SQL was already quite a long way ahead, thanks to previous work. I could extract statistical insights from the plentiful metadata our system gathered, such as how long users spent on each step of the flow, or where they got stuck and gave up.

Over the course of the project, I had contributed to every aspect of engineering to some extent, as had my colleagues, but mainly I had developed my specialism in assurance, including both UI and API test automation, performance testing, security testing, design scrutiny and close collaboration with developers at the very early SDLC stages. 

After two years of development, the product was well-established and highly effective, so our team was able to entirely hand it over the client. By this time, other BJSS Bristol teams had started other projects with NHS Digital in Exeter and that engagement continued for many years. A BJSS Exeter office was opened with NHS Digital being one of the main clients, reflecting the growth that our initial success had triggered.

---

After our time, the tool gradually evolved and was later renamed 'Profile Manager'. Few relics of the original Profile Updater remain publicly available online, but one example, surprisingly, is the 2018 user guide that I wrote! Profile Updater Guidance 2018-19 

Why is there a user guide? Although a written manual seems very old-fashioned and we had designed the tool to be intuitive without one, user research revealed a lack of IT confidence among a notable minority of pharmacists, who barely used computers in their day-to-day and were hesitant to trust any new software or believe they were using it correctly, perhaps scarred by past experiences. Some found it reassuring to have a source of explicit instruction outside the software product itself. Most users wouldn't need it, but quite a few would probably be in touch with the helpdesk without it!

Head-hunted by a former test manager, I worked as a contract test analyst for Bibby Financial Services in Banbury. I was involved in several projects for more than 2 years, covering:

• Platform migration and upgrades 

• Performance & stability

• Financial reporting

• Digital marketing

These projects mainly related to a new invoice financing management system that Bibby was introducing, but did branch out into some other areas, such as a new mobile-friendly website (it was a different time!).

The pre-agile, pre-DevOps world

The experience was valuable in many ways, but was highly influencial on my outlook in that it had demonstrated all the disadvantages of the pre-agile, pre-DevOps world. The vast inefficiencies, timescales and costs of siloed, waterfall, low-tech delivery raised many questions, which were promptly answered when I joined a fantastically modern team in my next job. Agility, cloud tooling, cross-functional teams, modern test engineering, CI/CD - these are all solutions, whose logic and value is plainly obvious when you have experienced the very problems that necessitated them. We really understand and appreciate the good once we've seen the not-so-good.

Nevertheless, the projects were broadly successful in their goals, albeit inefficient by modern industry standards. I still gained valuable experience in several areas, including traditional software testing methodology, technical testing, (T-)SQL, data analysis and technical writing. 

Shift to technical test engineering

Despite the project being a fairly low-tech, pre-agile environment, I was inclined towards a more technical, test 'engineering' approach - I was reading and writing code, making suggestions to developers and using whatever technical tools were available (not many, beyond SQL and Excel!) to make my testing more effective and efficient. This was somewhat unusual and even controversial among some on the project, so it was a welcome revelation when I moved to BJSS to find that I was indeed on the right track.

A key achievement was my development of sophisticated methods for testing complex, data-based financial reports, which were customer-facing. These reports were powered by large, complex SQL queries - hundreds of lines, many source tables, CTEs, logic rules, aggregation, mathematical calculations, no unit tests. This is not how one would engineer a solution today. The reports were notoriously high-risk for bugs, given the vast permutations that were possible in the data. I introduced new methods involving manipulation of the underlying SQL to cover much larger time ranges and customer/transaction sets than would normally be used in a report, allowing for thorough 'before and after' analysis with broad representation of customer scenarios, achieving high confidence (or finding many bugs) in code changes with minimal effort. 

I extended this approach to performance testing. Sometimes it was appropriate to measure query runtimes in isolation of the surrounding (unchanging) application. Sometimes, a good option was to run the full reporting mechanism and parse its logs using my own custom tools, to extract performance information from event timings.

Additional responsibilities

I was often able to help management figures by creating tools for planning or tracking work and visualising data. That included release management, test management, defect management and project planning. Admittedly, these were mainly in Excel, but I found I could make surprisingly sophisticated dashboards, anaylse data deeply, hook Excel up to databases - quite advanced usage. Excel has a bad reputation among engineers, which is understandable, as it is often used badly and there are often more powerful, flexible options available. However, if used well in the right context, it's not bad as an introduction to concepts around data management and data visualisation. Every org (pretty much) has a license for it and there is still the odd case where it's the right tool for a small, one-off data task, quicker than writing a custom app and cheaper than buying in a third-party one.

Since traditional, formal software testing methodologies were still very present in this environment, there were quite a lot of test plans and reports to write. I was happy to do much of the heavy lifting there and the test manager or test leads were very happy to delegate it. Technical writing, experiment design and analysis of results were very important in my science degree, which was still fresh in my mind. The way academic scientists are trained to write is highly compatible with formal testing documentation, but is frankly above and beyond what is required on an IT project. So, meeting the standard was no problem at all, but I did need to learn to tone it down, make things concise and use a lot more bullet points.

In my introduction to the industry, I worked as a contractor on a large IT delivery project, quickly learning about software testing theory, test planning and design, test result analysis and reporting, defect management.

I collaborated with many experienced engineers, analysts and managers, gaining valuable experience, advice and insights into the industry. I supported project operations in a wide range of ways: release management support, procedure documentation, automated dashboard production, BAU handover, proof-reading and improving customer-facing financial documents.

Although this was a fairly low-tech, old-fashioned project, I was introduced to some areas of tech, including VBA, SQL, XML and UNIX. I developed an advanced knowledge of MS Excel (as the best tool available in that environment at that time) and applied it to support test operations and project management. 

The first project involved introducing a new auto-enrolment pension system. I was on this project until it wrapped up in April 2014.

Very shortly afterwards, I was asked to return to help with another project - an upgrade to the general insurance system. By the time this short-term contract came to a close, the test manager from the first project had moved to Bibby Financial Services and had recruited me to join him there.

• Research carried out in the field of computational chemistry.

• Technical writing on highly complex subjects.

• Design, execution and analysis of scientific experiments, formal reporting on results.

• Application of mathematics in problem solving. 

• Third year spent studying in Munich, Germany.

Surprisingly, the formal scientific training offered useful, transferable skills that later served me well in the world of software testing.

Ich kann immer noch ziemlich gut Deutsch verstehen, besonders beim Lesen. Sprechen ist natürlich ein bisschen schwieriger und langsamer, aber ich versuche es, wenn ich nach Deutschland oder Österreich reise.