WooCommerce Automation Testing

An end-to-end software testing project for a WooCommerce storefront, covering UI automation, API testing, performance testing, CI execution, and test reporting.

The project was created as part of a university software analysis and design assignment. Although the assignment was submitted by a two-person team, all automation code, test implementation, CI configuration, execution, debugging, and technical reporting in this repository were completed by Nguyễn Phước Sang.

---

Project Goals

The project explores how automated testing can improve the reliability of an e-commerce system by:

• automating critical user flows;
• detecting regression issues earlier;
• validating WooCommerce REST APIs;
• evaluating behavior under concurrent traffic;
• running tests automatically in CI;
• producing readable test reports for debugging and review.

The tested system is a WooCommerce-based online store, with emphasis on high-value flows such as authentication, product browsing, cart operations, checkout, and order-related behavior.

---

Testing Scope

UI Testing

The UI test suite covers core customer flows, including:

• valid and invalid login;
• product search and browsing;
• adding products to the cart;
• removing products from the cart;
• updating cart contents;
• checkout flow;
• validation of expected page state and UI behavior.

The tests were designed around the following principles:

• each test should have a clear purpose;
• tests should remain as independent as possible;
• critical user journeys should receive priority;
• assertions should validate actual behavior rather than only page navigation;
• reusable page actions and selectors should reduce duplication.

API Testing

WooCommerce API scenarios were created and executed using Postman and Newman.

The API scope includes:

• authentication-related requests;
• retrieving product data;
• validating response status and structure;
• creating order-related requests;
• checking expected and invalid inputs;
• executing collections automatically through the command line.

Performance Testing

JMeter was used to model concurrent traffic and observe system behavior under load.

The performance scenarios were designed around:

• multiple concurrent virtual users;
• response time;
• throughput;
• error rate;
• system behavior as load increases.

The original report proposed scenarios at approximately 100, 500, and 1,000 concurrent users, depending on the available local environment and test configuration.

---

Technology Stack

UI Automation

• Java 23
• Selenide 7.6
• Selenium WebDriver
• TestNG
• AssertJ
• Maven

API Testing

• Postman
• Newman

Performance Testing

• Apache JMeter

Reporting and CI

• Allure Report
• GitHub Actions
• Maven Surefire
• AspectJ Weaver

---

Test Architecture

The UI automation layer uses Selenide on top of Selenium WebDriver.

A typical test follows this structure:

1. prepare the test environment;
2. open the target page;
3. perform user actions;
4. wait for the expected application state;
5. assert the result;
6. attach execution information to the report;
7. clean up test state when necessary.

Selenide was selected because it provides:

• concise browser interaction APIs;
• built-in waiting behavior;
• readable selectors and assertions;
• simpler test code than lower-level WebDriver usage;
• integration with TestNG and Allure.

---

Continuous Integration

The repository includes a GitHub Actions workflow that runs on pushes and pull requests targeting master.

The CI pipeline:

1. checks out the repository;
2. installs Temurin JDK 23;
3. runs mvn clean test;
4. collects Allure result files;
5. uploads them as a workflow artifact even when tests fail.

- name: Build and Run Tests
  run: mvn clean test

- name: Upload Allure Results
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: allure-results
    path: target/allure-results/

Keeping report artifacts when a test fails is useful because the report, screenshots, stack traces, and execution steps are most valuable during failure investigation.

---

Running the UI Test Suite

Requirements

• JDK 23
• Maven
• Google Chrome
• a reachable WooCommerce test environment

Install dependencies

mvn clean install -DskipTests

Run all tests

mvn clean test

Run a specific test class

mvn -Dtest=YourTestClass test

Replace YourTestClass with the actual class name.

---

Allure Reporting

Test results are written to:

target/allure-results

Generate and open the report with:

allure serve target/allure-results

Or generate a static report:

allure generate target/allure-results --clean -o target/allure-report

Allure is used to make failures easier to understand through structured test steps, result status, timing information, and attached evidence.

---

Running API Tests

Install Newman:

npm install -g newman

Run a collection:

newman run path/to/collection.json

Run with an environment file:

newman run path/to/collection.json \
  -e path/to/environment.json

Generate a report when the required reporter is installed:

newman run path/to/collection.json \
  -r cli,html

---

Running Performance Tests

Open the JMeter test plan in the JMeter GUI while developing or debugging:

jmeter

For an actual load run, prefer non-GUI mode:

jmeter -n \
  -t path/to/test-plan.jmx \
  -l results.jtl \
  -e \
  -o report

The HTML report can then be opened from the generated report directory.

---

Test Design Techniques

The project applies common black-box test design techniques.

Equivalence Partitioning

Inputs are divided into groups that should behave similarly.

For example, login input can be divided into:

• valid credentials;
• invalid password;
• unknown account;
• missing username;
• missing password.

This reduces unnecessary duplication while preserving meaningful coverage.

Boundary Value Analysis

Values near validation limits are tested because defects frequently occur at boundaries.

Examples include:

• minimum and maximum quantity;
• empty cart versus one item;
• valid and invalid field lengths;
• zero, one, and values just above an allowed limit.

Given–When–Then

Scenarios can be described as:

Given a customer is viewing an available product
When the customer adds the product to the cart
Then the cart should contain that product with the expected quantity

This makes the intended behavior easier to understand for both technical and non-technical readers.

---

What This Project Demonstrates

This repository demonstrates practical experience with:

• designing automated test cases;
• browser automation;
• synchronization and waiting in UI tests;
• assertion design;
• API verification;
• command-line test execution;
• basic load-test design;
• CI automation;
• test result reporting;
• reproducing and debugging failures;
• evaluating the strengths and limitations of automated testing.

It also demonstrates that automated testing does not replace all manual testing. Automation is especially valuable for repeatable regression checks, while exploratory testing and human judgment remain important for new or ambiguous behavior.

---

Limitations

• The project targets a test WooCommerce environment rather than a production store.
• UI tests may require selector updates when the storefront theme or page structure changes.
• Performance numbers depend heavily on hardware, network, WordPress configuration, plugins, and test data.
• Load tests executed from one local machine do not represent a distributed production workload.
• Credentials, base URLs, and environment-specific values should be configured outside the source code.

---

Future Improvements

• use environment-based configuration for all URLs and accounts;
• improve test-data setup and cleanup;
• add cross-browser execution;
• run Postman/Newman and JMeter checks in CI;
• publish Allure reports automatically;
• add retry only for known infrastructure instability;
• add screenshots and browser logs on every UI failure;
• organize the UI suite using a consistent Page Object or component abstraction;
• separate smoke, regression, and end-to-end suites;
• add Docker-based reproducible test environments.

---

Author

Nguyễn Phước Sang

Responsible for the automation implementation, test execution, CI setup, debugging, and technical documentation contained in this repository.