OnTerminalUI & API Test Automation
- Period
- Dec 2025 - Feb 2026
- Project type
- Group QA Training Project
- Role
- Team Lead & Automation Contributor (Group 50)
- Team
- 5-contributor Group 50
A Java and Serenity BDD suite covering 107 browser and REST scenarios across authentication, inventory, categories, sales, navigation, validation, security, and health checks for OnTerminal.
- 52 API and 55 UI
- 107Scenarios52 API and 55 UI
- Business-readable specifications
- 16Feature filesBusiness-readable specifications
Overview
The repository turns OnTerminal's browser and REST behavior into executable Gherkin specifications. UI steps delegate to page objects, API steps reuse authenticated request foundations, shared configuration controls environments and credentials, and Maven produces Serenity plus Cucumber HTML, JSON, and XML reports. The suite depends on a separately running application and does not contain its database or deployment stack.
Role & context
- Role
- Team Lead & Automation Contributor
- Team
- 5-contributor Group 50
- Type
- Group QA Training Project
- Period
- Dec 2025 - Feb 2026
A five-contributor Group 50 QA training project. As team lead and a hands-on automation contributor, I built and refactored much of the Maven and Serenity foundation, shared API authentication and request utilities, hooks, soft assertions, UI steps, and significant authentication, category, plant, sales, navigation, and security coverage. Git records 29 commits and the largest current-line share for my author alias.
Problem
A stock and sales system has stateful workflows and two privilege levels. Regressions can expose admin-only actions, leak sales data, accept invalid quantities, or leave inventory inconsistent, while manual repetition of the same positive, negative, and security paths is slow and unreliable.
Approach & architecture
Business-readable scenarios run through separate UI and API layers, sharing configuration, lifecycle hooks, diagnostics, and report generation.
Practices followed
Kept business-readable Gherkin specifications separate from page objects and API request code
Centralized base URLs, credentials, routes, timeouts, status codes, and configuration precedence
Covered admin, standard-user, unauthenticated, malformed-token, validation, and data-leakage paths
Generated unique records and discovered suitable runtime fixtures to reduce test collisions
Captured request logs, scenario metadata, screenshots, Cucumber artifacts, and Serenity aggregate reports for diagnosis
Challenges & resolutions
The application UI varied between modules and changed during the project.
FixEncapsulated prioritized CSS and XPath fallbacks inside page objects rather than spreading selectors through step definitions.
Sales tests depend on mutable inventory and valid related records.
FixDiscovered usable categories and in-stock plants at runtime, created fallback fixtures, and verified the same plant's quantity after sale.
Outcomes
Declared 107 executable specifications: 52 API and 55 UI scenarios across 16 feature files
Verified complete step binding with no undefined or ambiguous steps in a full Cucumber dry run
Compiled all 27 Java test sources successfully on JDK 21
Covered authentication, categories, plants, sales, dedicated security paths, health, and inventory navigation
Tech stack
Concepts & skills10
- Behavior-driven development
- Gherkin scenario design
- Serenity BDD
- Cucumber-JVM
- Page Object Model
- REST Assured
- Role-based security testing
- Dynamic test data
- Stateful inventory verification
- Test reporting and diagnostics