Test Automation Case Study

This repository contains an end-to-end test automation case study covering Web UI, Mobile UI, and API layers.

📌 Scope

1. Web UI Automation
2. Mobile UI Automation
3. API Automation

Each section is implemented as an independent automation module

📁 Repository Structure

test-automation-case
├── docker-compose.yml
├── README.md
├── web-ui
├── mobile-ui
└── restful-booker-karate

---

1️⃣ Web UI Automation Project

This project is a Web UI Test Automation framework developed as part of a technical case study.

🛠 Technologies Used

• Java 21
• Selenium WebDriver
• TestNG (parallel execution)
• Cucumber BDD
• Maven
• Docker
• Selenium Grid 4
• Jenkins
• Cucumber Reports (Jenkins Plugin)

---

📁 Project Structure

web-ui
├── pom.xml
└── src
    └── test
        ├── java
        │   └── com
        │       └── vakifbank
        │           ├── hooks
        │           │   └── Hooks.java
        │           ├── pages
        │           │   ├── BasePage.java
        │           │   └── BookStorePage.java
        │           ├── runners
        │           │   └── TestRunner.java
        │           ├── stepdefinitions
        │           │   ├── AlertsSteps.java
        │           │   ├── InvalidNavigationSteps.java
        │           │   ├── PracticeFormSteps.java
        │           │   └── BookStoreSteps.java
        │           └── utils
        │               └── DriverManager.java
        └── resources
            └── features
                ├── alerts.feature
                ├── book_store.feature
                ├── invalid_navigation.feature
                └── practice_form.feature

---

✅ Implemented Test Scenarios

• Book Store list validation (row count & book details)
• Practice Form validation
  • Only mandatory fields
  • All fields filled
• Alert popup validations
• Invalid menu navigation (negative scenario)

Each scenario includes necessary validations as required by the case.

---

🧵 Parallel Execution

• Parallel execution is enabled using TestNG
• Each scenario runs with its own WebDriver instance via ThreadLocal
• Fully compatible with Selenium Grid 4

---

🌐 Selenium Grid 4 (Docker)

Selenium Grid 4 is executed using Docker containers:

• selenium/hub
• selenium/node-chrome
• selenium/node-edge

Tests are executed remotely via RemoteWebDriver.

Browser selection is controlled using a Maven parameter:

mvn verify -Dbrowser=chrome
mvn verify -Dbrowser=edge

---

🧪 Driver Management

• Centralized DriverManager
• Uses ThreadLocal for parallel safety
• Supports Chrome and Edge
• No usage of Thread.sleep() (explicit waits only)

---

📸 Screenshot on Failure

• Screenshots are captured automatically for failed scenarios
• Implemented using a Cucumber @After hook
• Screenshots are attached directly to the Cucumber scenario
• Visible inside the Cucumber HTML report in Jenkins

📍 Location in report: Scenario → Hooks → After → Embedded image (png)

---

📊 Reporting

Jenkins Cucumber Report

• Jenkins Cucumber Reports Plugin is used
• Reports are generated from cucumber-report.json
• Includes:
  • Scenario status
  • Step details
  • Charts
  • Embedded screenshots for failed scenarios

---

🚀 Jenkins Integration

• Jenkins Freestyle Job
• Pulls latest code from GitHub repository
• Runs tests using Maven (verify phase)
• Executes tests on Selenium Grid 4
• Publishes Cucumber HTML reports automatically

---

▶️ How to Run Locally

• Prerequisites:
  • Java 21
  • Maven
  • Docker & Docker Compose

Start Selenium Grid

docker-compose up -d

Run Tests

mvn verify -Dbrowser=chrome

---

📝 Notes

• All requirements defined in the case study are fully implemented
• Framework is scalable and easily extendable
• Clean architecture using Page Object Model
• CI-ready with Jenkins and Docker-based Grid

---

2️⃣ Mobile UI Automation

This module covers Mobile UI test automation for an Android application as part of the technical case requirements.

🛠 Technologies Used

• Java 21
• Appium
• UiAutomator2
• Android Emulator
• Cucumber BDD
• TestNG
• Maven
• Appium Inspector

---

📁 Project Structure

mobile-ui-automation
├── pom.xml
├── src
│   └── test
│       ├── java
│       │   └── com
│       │       └── akakce
│       │           ├── driver
│       │           │   └── DriverManager.java
│       │           ├── hooks
│       │           │   └── Hooks.java
│       │           ├── pages
│       │           │   ├── BasePage.java
│       │           │   └── AkakcePage.java
│       │           ├── runners
│       │           │   └── TestRunner.java
│       │           └── steps
│       │               └── AkakceSteps.java
│       └── resources
│           └── features
│               └── akakce.feature

---

📱 Execution Environment

• Tests were executed on an Android Emulator created via Android Studio
• Appium Server was started manually before test execution
• UI element inspection and locator validation were performed using Appium Inspector

---

✅ Implemented Scenario

• Search for a product (Laptop)
• Apply multiple filters
• Sort results by lowest price
• Select a specific product from the list
• Validate seller button visibility
• Compare listing price with detail page price (partially implemented)

---

📸 Screenshot on Failure

• Screenshots are captured automatically for failed scenarios
• Implemented via Cucumber @After hook
• Screenshots are embedded directly into the Cucumber report
• No Thread.sleep() usage (explicit waits only)

---

▶️ How to Run

Prerequisites:

• Java 21
• Maven
• Android SDK
• Android Emulator
• Appium Server

Start Appium Server

appium

Run Tests

mvn clean test

---

🧪 Appium Inspector

Appium Inspector was used extensively to:

• Inspect dynamic UI hierarchies
• Identify transient UI containers
• Analyze scroll behavior and overlay components
• Validate locator strategies before implementation

---

⚠️ Known Limitation (Transparent Disclosure)

Due to dynamic UI rendering and price components being split into multiple TextView elements in the product detail screen, a fully reliable price extraction from the detail page could not be finalized within the given time frame.

• Price digits are rendered across multiple TextViews
• No unique or stable resource-id available for full price value
• Multiple similar TextViews exist across the page This limitation is documented intentionally to demonstrate real-world mobile UI automation challenges and decision-making.

---

🧵 Parallel Execution

• Parallel execution is supported via TestNG
• Thread-safe driver management using ThreadLocal
• Each scenario runs with an isolated Appium session

---

📝 Notes

• Project follows clean architecture principles
• No hard waits (Thread.sleep) are used
• Explicit waits and robust locators are preferred
• Known limitations are documented transparently

---

3️⃣ API Automation

This module covers API Test Automation using the Karate Framework and is designed to validate RESTful services as part of an end-to-end automation strategy.

The project focuses on functional correctness, data integrity, and CI/CD readiness rather than UI-driven validations.

---

🛠 Technologies Used

• Java 17
• Karate DSL
• JUnit 5
• Maven
• Docker
• Jenkins
• RESTful Booker API (public test API)

---

📁 Project Structure

restful-booker-karate
└── karate-api
    ├── Dockerfile
    ├── Jenkinsfile
    ├── pom.xml
    └── src
        └── test
            ├── java
            │   └── com
            │       └── booking
            │           └── KarateTest.java
            └── resources
                └── features
                    ├── create-booking.feature
                    ├── get-booking-by-id.feature
                    ├── update-booking.feature
                    ├── partial-update-booking.feature
                    ├── delete-booking.feature
                    └── ping.feature

---

✅ Implemented Scenario

• Health check (/ping)
• Create booking
• Get booking by ID
• Update booking (PUT)
• Partial update booking (PATCH)
• Delete booking
• Response body & schema validations
• Status code validations
• Dynamic ID handling between scenarios

Each endpoint is tested independently to ensure statelessness and repeatable execution in CI environments.

---

🧪 Test Design Approach

• API tests are written using Karate’s declarative DSL
• No external test data dependencies
• Assertions cover:
• HTTP status codes
• Response payload structure
• Field-level data validation
• Tests are designed to be idempotent and CI-safe

---

📊 Reporting (Karate Native Report)

• Karate generates its own HTML test report
• Reports are located under:

target/karate-reports/karate-summary.html

• The report includes:
  • Feature-level and scenario-level results
  • Execution duration
  • Step-by-step request/response visibility

⚠️ Jenkins Cucumber plugin is not used for this module, as Karate does not produce standard cucumber-jvm JSON outputs. Karate native reporting is the recommended and supported approach.

---

🚀 Jenkins Integration

• Implemented using Jenkins Pipeline
• Pipeline stages:
  • Checkout source code
  • Build Docker image
  • Execute API tests inside Docker container
  • Publish Karate HTML report
  • Jenkins build result reflects actual test execution status

---

🐳 Docker Execution

• Tests are executed inside a Docker container
• Maven dependencies are resolved during image build
• Ensures:
  • Environment consistency
  • CI/CD portability
  • Zero local setup dependency

---

▶️ How to Run Locally

Prerequisites:

• Java 17+
• Maven
• Docker

Run tests using Maven:

mvn clean test

Or using Docker:

docker build -t karate-api-tests .
docker run --rm -v target:/app/target karate-api-tests

---

📝 Notes

• API tests are fully CI/CD ready -= Framework is lightweight and highly maintainable
• Clear separation from UI and Mobile automation layers
• Designed to demonstrate real-world API automation practices
• Reporting strategy intentionally differs from UI/Mobile modules to align with Karate best practices

---

👤 Author

Kerem Sarısen