Adem Kabayel
Selected work

Testing RFID inventory from the handheld to the cloud

At lululemon I test the workflows that keep store inventory honest: shipments and inventory counts that start with a handheld RFID scan and end up as events, files and records across a distributed system.

Company
lululemon, contract
Role
QA Automation Engineer, RFID
When
Dec 2024 to present
Where
Vancouver, BC

The system

One scan travels a long way. It starts on a handheld device in a store or distribution centre, goes through REST APIs and Spring Boot services, fans out as Kafka events, and lands in AWS S3, in databases, and in the Nedap iD Cloud platform. Almost every step is asynchronous, and several of them belong to someone else.

What makes it hard to test

  • Nothing happens in one place. A test that only checks the API response misses most of the system. The interesting failures show up later, in a topic, a file or a table.
  • Time matters. Event timestamps, inventory dispositions and dead-letter queue behaviour each need their own checks, because each can be wrong while the happy path still looks fine.
  • Failures have many owners. A bad result can come from an event producer, a consumer, our service logic, or a third-party platform, and each needs a different conversation.
  • The ground moved. The API gateway migrated from Apigee to Kong, so existing behaviour had to be proven unchanged, including security-related service changes.

What I built

  • Java BDD automation with REST Assured, Cucumber, JUnit 5, TestNG, Maven and Allure that validates API responses, Kafka messages, S3 outputs and backend data inside one scenario.
  • Automated coverage for shipment, inventory-count and EPCIS scenarios, including store and distribution-centre integrations, event timestamps, inventory dispositions and dead-letter queues.
  • Functional, regression and integration coverage for the Apigee to Kong gateway migration.
  • Suites that run in GitLab CI/CD on Kubernetes runners, which I integrate and troubleshoot.
  • Contributions to a new Playwright and TypeScript BDD framework for a UI tool, along with the Java and Kafka backend checks that make its end-to-end coverage reliable.

How I trace a failure

When a scenario goes red, I follow the event. Lenses shows me what reached the Kafka topics, Splunk shows what the services logged, SQL, MongoDB and Snowflake show what the data looks like, and AWS shows what landed in S3. The goal is to hand a developer or vendor the exact component that broke, with the evidence, instead of a screenshot of a failed test.

I wrote more about this way of testing in Testing an event you can’t see.

Working with the team

Most of the job is communication. I design and run functional, integration, regression and end-to-end testing, and I report release risk to developers, vendors and stakeholders in terms they can act on: what is covered, what isn’t, and what would break if we shipped today.

Tools

Java, REST Assured, Cucumber, JUnit 5, TestNG, Maven, Allure, Playwright, TypeScript, Apache Kafka, Lenses, Splunk, AWS S3, SQL, MongoDB, Snowflake, Apigee, Kong, GitLab CI/CD, Kubernetes.