Daniel Casey

Senior Quality Engineer

📧 dcasey1596@gmail.com 📱 07940338870
GitHub LinkedIn
I believe Quality starts at architecture and is propagated through every decision and way of working. I have led intents, domains, teams, and teams of teams, through the entire SDLC.

Core Stack

  • Gatling
  • Rest Assured
  • Cucumber
  • WireMock
  • Java
  • AWS

Extra

  • Scala
  • Kotlin
  • RSpec

Career Journey

View as traditional CV PDF

  • Led testing strategy for Edge migration — created the plan and kick‑started the technical setup, kept stakeholders updated throughout, while supporting engineers across teams. The scale of testing reflected the complexity and size of the project — all traffic was moved in a big‑bang migration 40k requests per minute.
  • Owner of Core Testing (Acceptance & Performance) — set a single strategy for where tests live, when they’re made, and how they’re written across tech.
    Acceptance
    • Where: shared libraries with clear ownership and reuse.
    • When: boundaries and scope defined at unit, service, and integration layers.
    • How: consistent frameworks and patterns to keep tests readable and stable.
    Performance
    • Built thread‑based tests and workload models to mirror real usage.
    • Focusing on what we are testing - different testing for Fargate v Lambda.
    • Involved Product in setting performance requirements and SLAs.
  • Integrated testing libraries — created shared acceptance testing libraries that reduce duplicated setup and tests across services, centralise ownership, and speed up onboarding.
  • Expanded test types — added nearest‑neighbour testing for contract validation and mutation testing to improve unit coverage and test strength, both for the mobile applications.
  • Architected and led Tier‑2 migrations — defined the high‑level strategy for AWS migrations, dived into legacy on‑premises systems to reverse‑engineer intent, and created the technical design for each feature.
    • Features: Activate Card, Personal Details, Temporary Card Lock, Replacement Card.
    • Handover to tech leads after design; stepped back in to build the Card Lock service when timelines were at risk.
  • Led Eligibilities feature migration — defined the high‑level architecture and led delivery within team. Focused on implementation with regard to account state conflicts and discussing future path of token scoping (privilege vs customer).
  • Role design: QE + SDET — worked with Directors to define responsibilities, competencies and expectations for testing roles operating in UK Tech.
  • Fargate‑hosted WireMock for Lambda testing — created a simple way to host WireMock on a Fargate container to enable stubbed Lambda testing. Set the UK Tech strategy to one container per BA to cut costs and reduce duplication.
  • Orchestration generator (Python → Java EC2 APIs) — built a Python CLI to scaffold EC2 APIs from a few inputs (project name, owner, etc.), applying them to package and folder names plus build/pipeline files. Removed boilerplate: folders, libraries, and classes ready so teams could focus on the actual API code; saved ~3 weeks per API.
  • Led testing strategy for Edge migration

    Utilised Rest Assured and Kotlin to create a headless client to test the reverse proxy component; designed tests for reusability. After packaging the client as a library, reused the same base tests in both the WAF and Gateway pipelines, providing coverage to components that previously didn’t exist without needing to duplicate or maintain more tests.

    Utilised a WireMock proxy to allow both stubbed and integrated testing in pre‑production. Enabled full performance and acceptance testing of the Edge layer without risking service instability or account conditioning problems.

    Utilised the same WireMock stack creation to enable nearest‑neighbour testing from the mobile apps. Contract validation through the live Edge layer became available for all endpoints utilising XCUITest and Espresso native frameworks, expanding app test suites and moving contract checks away from full end‑to‑end tests.

  • Owner of Core Testing (Acceptance & Performance)
    Acceptance

    Defined integrated acceptance testing libraries at BA level (see Integrated Testing libraries).

    Defined with other senior and mid level engineers the testing scope for each test, 3rd party integration vs stubbing, the concept of 1 test for a system proves each component of that system vs layer stacking of tests. Reviewed what tests are required at each scope and what can be moved left.

    Defined with a mid level engineer the framework standards as well as libraries. e.g. Cucumber, PicoContainer, Java, etc.

    Aim to create standardisation of all aspects for services testing as well as to prevent library conflicts with the move to library suites.

    Performance

    Repositioned the conversation from completing testing types with Gatling to questioning what we need to prove about our performance. Defined different strategies and used different tools dependent on compute resource.

    With Edge performance was paramount; used deeper tools like JMeter to discover thread, memory, and CPU usage. General Gatling was sufficient for system level testing.

  • Integrated testing libraries

    Utilised native Maven publish to package repos as libraries, taking careful consideration of dependencies used to prevent conflicts.

    Created one repo per BA for organisation with Cucumber and Rest Assured frameworks.

    Libraries are consumed in API repos via the Gradle files with only a simple task creation required; specific tests of the library are run using tags on the tests.

    All aspects of certificates, tokens, integrations and boilerplate are completed once in the library repo, abstracting the complexity from the API spaces.

  • Expanded test types - Mobile Apps

    With the introduction of the Reverse Proxy WireMock we were able to complete App integrated tests without the need for live accounts. By utilising the existing local UI tests (Espresso and XCUITest) but pointing them to a different entry point we achieve nearest neighbour testing and validation of the app to Edge contracts and data handling.

    Implemented PI Test into the Android app and an equivalent into the iOS app to provide unit test strength metrics and identify any gaps in our coverage.

  • Architected and led Tier‑2 migrations

    Created the Technical Design Documents for Tier‑2 features, considering trade‑offs between AWS Fargate and AWS Lambda for Layer‑1 services, and assessing the impact upstream services may have on these decisions (see argument against synchronous Lambdas).

    Reviewed existing on‑premises Java services and configuration files to determine business logic and reconstruct data flows.

    Wrote the Card Lock service using a standard layered architecture (controller → service) with javax annotations for construction; dependency injection implemented via Spring beans. Kept clear separation of concerns and straightforward unit/integration testing.

  • Led Eligibilities feature migration

    Owned the Tier‑1 Eligibilities feature: defined the technical design and worked closely with stakeholders to align requirements, timelines, and risk.

    Placed strong emphasis on the authorisation token strategy: the widely‑used but deprecated privilege token versus the new, unproven customer token. For a Tier‑1 service, selecting the right token type and setting a safe migration path were key considerations.

  • Fargate‑hosted WireMock for Lambda testing

    To be added.

  • Orchestration generator (Python → Java EC2 APIs)

    To be added.

Creating a Neural Network - Just the math

Back in 2024 I wanted to see how possible it was to beat Tetris by Machine Learning. But the extra stipulation I put on this, was that AI had to also produce all the elements.
It had to create the game of Tetris, and also create the script to play it, learn from it, and beat it.
Although a nice enclosed view of the capabilities of GPT 4, it wouldn't really help me.
So I decided a nice challenge for myself was to learn how a neural network actually worked. Look at the layers, the nodes, how they interact with each other.
This took me down a relatively long path of learning about bias, cost, gradients, and the most challenging both in terms of concept and coding, backwards propagation.
There will eventually be a blog post going over all the math and my findings, but till then, check out Neural Network Git

BSc 2:1 - Astrophysics ISTQB