Projects

In-House Projects & Engineering Platforms

ZelQA Technologies builds and validates its own in-house products and engineering platforms while also supporting confidential software quality and security engagements.

ZelQA AeroSecure QA Automation & Intelligence AI-Assisted QA Engineering ZelQA Learning & Meeting Platform Security Testing Labs OMS-360 Food Supply Platform Warehouse Robotics

Platforms, Products & Labs

Products, platforms and labs developed by ZelQA Technologies. Every capability carries an explicit status — Active, Implemented, Pilot, In Development or Planned — so planned work is never presented as finished.

PROJECT-10PlannedIn-House

ZelQA AeroSecure

Airport Cybersecurity, Quality Engineering & AI Security Platform

A ZelQA-developed engineering platform for airport-domain quality engineering, security testing and AI security testing. It is an in-house project built on synthetic data only — not a customer implementation — and uses no real airline or airport branding, systems or data. The requirements, architecture, database design and traceability baseline are documented; the capabilities below are the planned scope and are not yet built.

Current stage — Architecture & requirements baseline — implementation not yet started

Airport-domain quality engineering (flight → passenger → booking → check-in → boarding → baggage → security workflows)Planned
Manual and automated testing (Playwright, pytest)Planned
API testing (Postman / Newman)Planned
Security & vulnerability testing (isolated vulnerable vs. hardened modes)Planned
AI-assisted testingPlanned
AI / LLM security testingPlanned
Audit trail & test evidencePlanned
Kafka / event testing (transactional outbox → Kafka)Planned
SOC / security monitoringPlanned
QA intelligence & release-readiness dashboardsPlanned
CI/CD security and quality engineeringPlanned

ActiveIn-House

QA Automation & Intelligence

Automated testing, reporting and CI for ZelQA’s own platforms

The automation layer we use to validate our own products: Playwright suites across desktop and Android/iOS-class mobile viewports, Allure reporting with run history, and a Jenkins build pipeline — each with recorded run evidence in the repository.

Current stage — In use on the ZelQA platform today

Playwright end-to-end suite (desktop + mobile viewports)Active
Mobile responsive automationActive
Allure reporting with environment & historyActive
Jenkins CI build pipeline (install → Prisma generate → production build)Active
Automated test stages inside the CI pipelinePlanned

In DevelopmentIn-House

AI-Assisted QA Engineering

Applying AI to test design and analysis — in honestly labeled stages

Our in-house programme for AI-assisted testing — a QA engineering workspace, not a chatbot. The review workspace (requirement → test scenarios → human review → approved export) is built and tested, and currently runs in deterministic, non-AI mode. Live AI generation, test case generation, and failure/defect analysis are planned. The full status matrix is on the Services page.

Current stage — Review workspace running in deterministic (non-AI) mode — live AI generation planned

Ask ZelQA site assistant (secure server-side AI proxy)Implemented
QA review workspace — scenario templates, human review & approved export (non-AI mode)Implemented
AI-generated test scenarios (live AI model)Planned
AI-assisted test case & API/UI test generationPlanned
AI-assisted failure & defect analysisPlanned

See the full capability status matrix

ActiveIn-House

ZelQA Learning & Meeting Platform

This website, student and staff portals, and credential-gated rooms

Built and tested in-house: the public website, student registration and dashboards, staff administration, and role-based, credential-gated classroom, guest, client-review and interview rooms. It is also the first system our own automation and security testing runs against.

Current stage — Built and running — real-time audio/video still in development

Public website & business enquiry workflowActive
Student & staff portals with session managementActive
Credential-gated classroom, guest & interview roomsActive
Real-time audio/video in rooms (LiveKit)In Development

PilotIn-House

Security Testing Labs

Security testing practice on our own platforms

Security testing of the ZelQA platform itself: server-side input validation and sanitization, rate limiting and credential-gated meeting rooms are implemented in the application; a dedicated meeting-credential security test suite has been written and is being executed. A full vulnerability-testing lab is planned as part of ZelQA AeroSecure.

Current stage — Pilot — controls implemented, security test runs in progress

Input validation, sanitization & rate-limiting controls (ZelQA platform)Implemented
Meeting-credential security & concurrency test suiteIn Development
Vulnerability testing lab (vulnerable vs. hardened modes)Planned

In-House

Engineering Practice Projects

Systems we built and tested in-house to practice enterprise QA end to end. Screenshots are genuine captures from our own builds — they contain no customer systems or data.

Order Management · Fulfillment · Reporting

OMS-360 — Enterprise Order Management System

Problem addressed

Built in-house to model how a mid-size retail operation replaces 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

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.

Real project screenshot

OMS-360 Enterprise Monitoring Center showing order monitoring, Kafka, database health, duplicate orders, DLQ and critical alerts.

Live OMS-360 Enterprise Monitoring Center — backend/database/Kafka health, failed orders, duplicate orders, DLQ, and critical alerts from the running service.

Tech stack

REST APIMySQLKafkaDockerPostman / 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

Problem addressed

Built in-house to model a supply-chain platform that connects 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

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 added 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 screenshot OMS-360 Enterprise Operations Center showing the Order → Payment → Inventory → Kitchen → Ready → Delivery → Delivered lifecycle and a live orders table with 21 real orders

OMS-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 Simulation · Flask · Monitoring

Warehouse Robotics — API Automation & Monitoring

Problem addressed

Built in-house as a Flask-based REST API simulation of a warehouse robotics fleet, to validate that the fleet-control API and monitoring layer behave correctly under load — including the failure cases that only show up when multiple robots compete for the same task.

Architecture

Workflow

Task AssignedRobot AcknowledgesStatus Updated via APIStatus LoggedDashboard UpdatedAlert If Failed

Testing strategy

✔Automated API test suites for control endpoints
✔Load-condition scenario testing for task assignment
✔Robot status/event-flow validation through the API
✔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 tightened the monitoring service's polling interval.

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

Fleet 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

Flask REST APIPostman / NewmanAllureGrafana

Database design

tasksAssigned pick/move tasks

robot_eventsRobot status & event log

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 API automation (Postman/Newman/Allure) and Grafana-based monitoring scenarios.

Confidential

Confidential Projects & Engagements

Alongside our in-house work, ZelQA Technologies supports software quality and security engagements whose details are not published. Selected project details are confidential and cannot be publicly disclosed due to contractual, security, privacy, or confidentiality requirements.

For that reason this page does not show customer names, logos, case studies or results from those engagements. To discuss how we could support your project, please get in touch.