Case Study

ERPNext QA Automation & Engineering

Independent QA automation portfolio project demonstrating Playwright-based UI testing across selected ERPNext workflows using Page Object Model architecture and GitHub Actions CI.

Test Suite
6 Tests
Application Areas
3
Latest Status
6/6 Passed
Technology
Playwright

Project Overview

This is an independent QA automation portfolio project — not client work. It demonstrates practical QA automation engineering against a real ERP application.

The project focuses on validating critical business workflows through automated UI testing, using industry-standard practices: Page Object Model architecture, repeatable test scenarios, and CI/CD integration.

Application Tested

ERPNext — an open-source Enterprise Resource Planning (ERP) system. The application provides business management workflows including materials management, quotations, sales orders, and financial processes.

Testing ERPNext provides realistic scenarios: complex workflows, data dependencies, business rule validation, and multi-step user interactions.

Test Scope

The automation suite covers three critical workflow areas:

Workflow Scenarios Coverage
Material Request Creation, item selection, quantity, amount calculation, save Business rule validation
Quotation Creation, customer, items, rates, validation, save Required field validation
Sales Order Creation, customer, items, rates, save Order workflow validation

Automation Suite Facts

Current Scope:
  • 6 active automated test scenarios
  • 3 application workflows tested
  • Playwright UI automation framework
  • Page Object Model architecture
  • GitHub Actions CI/CD execution
  • Latest verified suite: 6 passed / 0 failed / 0 flaky

Important: This result refers to the current automation suite only. It does not represent full ERPNext coverage, production validation, or zero-defect status.

Automation Architecture

The project uses industry-standard QA automation practices to ensure maintainability, scalability, and reliability.

Technology Stack

Playwright (UI Automation) Page Object Model JavaScript / Node.js GitHub Actions (CI/CD) Environment Configuration

Pattern: Page Object Model

Each application page/workflow is represented as a reusable Page Object class. This separates test logic from UI element selectors, making tests:

  • Maintainable: UI changes require updates in one place (the Page Object)
  • Readable: Tests describe business actions, not technical element interactions
  • Scalable: New tests reuse existing Page Objects without duplication

CI/CD Integration

Tests execute automatically through GitHub Actions on every repository update. This ensures:

  • Consistency: Tests run in a standardized environment
  • Visibility: Build status is visible to all team members
  • Early Detection: Test failures are caught immediately

Automation Reliability Investigation

During test development, autocomplete field interactions showed intermittent failures. This investigation demonstrates QA engineering thinking: identifying root cause and improving test reliability through evidence-based problem solving.

The Problem: Intermittent Test Failures

Tests would fail randomly when automating autocomplete field interactions (e.g., selecting a customer from a dropdown). The same test would pass on one run and fail on the next, with no obvious reason.

Investigation Process

  • Step 1 — Reproduce: Capture the failure in a controlled test scenario
  • Step 2 — Observe: Run the test multiple times to identify patterns
  • Step 3 — Analyze: Compare successful vs failed attempts; identify timing differences
  • Step 4 — Hypothesis: ERPNext/Frappe autocomplete has asynchronous behavior (API call + render delay)
  • Step 5 — Evidence: Browser DevTools showed autocomplete dropdown rendering after interaction was already attempted
  • Step 6 — Root Cause: Playwright's default interaction timing didn't account for ERPNext's autocomplete async behavior

Solution: Synchronization Fix

The fix addressed the underlying engineering principle: the test interacted with the autocomplete before the expected UI state was available.

The solution synchronized the test interaction with the dropdown's rendered state by:

  • Detecting when the dropdown options are visible in the DOM
  • Waiting for the asynchronous API response to complete
  • Only then selecting from the populated dropdown

This approach treats synchronization as an engineering problem: align test execution with application behavior, not as a generic "best practice" but as a practical response to how ERPNext's Frappe framework handles autocomplete rendering.

Outcome: Improved Reliability

After implementing the keyboard-driven approach, test failures disappeared. The automation suite became reliable and repeatable.

Key Takeaway:

Automation reliability is not just about writing test code. It requires understanding the application's behavior, recognizing when the standard approach fails, investigating the root cause, and adapting the test strategy accordingly.

Evidence & Verification

All project artifacts are publicly available for inspection and verification.

What You Can Inspect

Source Code

Complete Playwright automation framework with Page Objects, fixtures, and test specifications.

View Repository →
CI/CD Execution

GitHub Actions workflow showing automated test execution, results, and build history.

View CI/CD Logs →
Architecture Documentation

README with test structure, workflow descriptions, and setup instructions.

View Documentation →

View the Project

Explore the complete source code, test suite, and CI/CD configuration on GitHub.