Zelqa Technologies
Project Portfolio

Enterprise Projects We've Built & Tested

Real enterprise QA projects — proof that our training and consulting are grounded in actual engineering work, not theory alone.

A note on confidentiality

The case studies below are illustrative and representative — built from the kinds of architecture, workflows, and testing challenges we work with on real enterprise QA engagements, using generalized project names rather than any specific client's name, logo, or proprietary details. Most screenshots are labeled "Illustrative UI mockup"; where a project instead shows screenshots labeled "Real project screenshot," those are genuine captures from an internal demo/practice build — never from a live client system or containing any client's data. Where we do reference actual client work elsewhere, client identities are withheld or anonymized in line with the confidentiality terms of that engagement.

Order Management · Fulfillment · Reporting

OMS-360 — Enterprise Order Management System

Business problem

A mid-size retail operation needed to replace spreadsheet-driven order tracking with a real system — one where an order's status, inventory impact, and fulfillment state stayed consistent no matter which team touched it.

Architecture

Client App
API Gateway
Order Service
Inventory Service
PostgreSQL
Grafana

Workflow

Order CapturedInventory CheckedPayment ConfirmedFulfillment TriggeredStatus UpdatedReport Generated

Testing strategy

  • Functional testing of order states
  • Regression on every release
  • API contract testing (Postman/Newman)
  • SQL-level data integrity checks
  • End-to-end business workflow validation

Challenges & solutions

Challenge — Order status could drift out of sync with inventory when two updates landed close together.

Solution — Built targeted concurrency test scenarios and traced the fix through to a database constraint, then locked it into the regression suite so it can't silently reappear.

Challenge — Refund flows touched three services, making manual testing slow and error-prone.

Solution — Automated the full refund path in an end-to-end test, cutting a 20-minute manual check down to a repeatable script.

Placeholder — Replace with actual project screenshot

Tech stack

REST APIPostgreSQLPostman / NewmanJenkins CIGrafana

Database design

ordersOrder header, status, totals
order_itemsLine items linked to inventory
inventoryStock levels per SKU
transactionsPayment & refund records

Business benefits

  • Order-to-fulfillment status is trustworthy across every team
  • Release regression time dropped once critical paths were automated
  • Clear audit trail for every order state change

Outcome — Now used as the reference project for our Automation & CI/CD and Enterprise Tooling training modules.

Vendor Management · Ordering · Delivery Tracking

Food Supply Platform

Business problem

A supply-chain platform needed to connect food vendors with business buyers reliably — vendor onboarding, order placement, and delivery status all had to stay accurate under real-world conditions like partial fulfillment and last-minute cancellations.

Architecture

Vendor App
Buyer App
API Layer
Order/Delivery Svc
Database

Workflow

Vendor OnboardedCatalog ListedOrder PlacedVendor ConfirmsDelivery DispatchedDelivery Confirmed

Testing strategy

  • Manual walkthroughs of vendor and buyer flows
  • Smoke & sanity testing per release
  • End-to-end workflow testing (order → delivery)
  • API testing of onboarding & order endpoints

Challenges & solutions

Challenge — Orders could be placed against items a vendor had just marked out of stock.

Solution — Added a race-condition test scenario and worked with the dev team to add a stock re-check at order confirmation, not just at cart-add.

Challenge — Delivery status sometimes froze at "preparing" and never updated.

Solution — Traced this to a missing webhook handler for one delivery partner integration, reproduced it reliably, and verified the fix end-to-end.

Real project screenshotOMS-360 Enterprise Operations Center showing the Order → Payment → Inventory → Kitchen → Ready → Delivery → Delivered lifecycle and a live orders table with 21 real orders

Live OMS-360 Operations Center — real order lifecycle counts and live order data, from the running production-style service.

Tech stack

REST APISwaggerSQLPostman

Database design

vendorsVendor profile & onboarding status
catalog_itemsProducts per vendor
ordersBuyer orders linked to vendor
deliveriesDispatch & confirmation tracking

Business benefits

  • Vendors and buyers see delivery status that actually reflects reality
  • Onboarding flow tested against real edge cases before vendor rollout
  • Fewer support escalations tied to stuck order statuses

Outcome — Used as the primary case study in our End-to-End Business Workflow Testing service and our Manual Testing training module.

Robotics API · Event Streaming · Monitoring

Warehouse Robotics — API Automation & Monitoring

Business problem

A warehouse robotics client needed confidence that their fleet-control API and monitoring layer would behave correctly under load — including the failure cases that only show up when multiple robots compete for the same task.

Architecture

Robot Fleet
Control API
Kafka Stream
Monitoring Svc
Grafana

Workflow

Task AssignedRobot AcknowledgesEvent PublishedStatus ConsumedDashboard UpdatedAlert If Failed

Testing strategy

  • Automated API test suites for control endpoints
  • Load-condition scenario testing for task assignment
  • Kafka event-flow validation
  • Grafana-based monitoring verification
  • Regression testing per firmware/API release

Challenges & solutions

Challenge — Under high load, two robots could occasionally be assigned the same pick task.

Solution — Reproduced the race condition with a scripted concurrent-request test, confirmed the fix (task locking), and kept the scenario in permanent regression.

Challenge — Failure alerts were sometimes delayed enough to matter operationally.

Solution — Measured actual event-to-alert latency under test load and worked with the team to tighten the monitoring service's polling interval.

Real project screenshotFleet Ops Console 2D dashboard showing 6 robots, live status counts, battery alerts, and the warehouse floor map with robot positions

Live Fleet Ops Console — real-time robot status, battery alerts, and active missions, polling the same Flask API that feeds Prometheus and Grafana.

Tech stack

REST APIKafkaGrafanaPostman / NewmanJenkins CI

Database design

tasksAssigned pick/move tasks
robot_eventsEvent log from Kafka stream
alertsFailure & anomaly records

Business benefits

  • Task-assignment conflicts caught before fleet-wide rollout
  • Monitoring dashboards verified to reflect real robot state, not stale data
  • Faster, more reliable failure alerting

Outcome — Referenced in our Enterprise QA Tooling training module for Kafka and Grafana-based testing scenarios.