Video summary

Session 48 - Selenium with Java | Hybrid Automation Framework Project | POM

Main summary

Key takeaways

Educational

Main Ideas / Concepts Covered

Purpose of an Automation Framework

  • An automation framework organizes automation project files/folders into a structured manner so the project is easier to maintain, modify, and reuse components.
  • It helps avoid the anti-pattern of placing everything in one folder (mixing unrelated file types), which makes searching and changes harder.

Core Objectives (3 Key Pillars)

  1. Reusability

    • Write components (e.g., utility code, data providers) once and reuse them across multiple test cases.
    • Avoid duplication (no copy-paste of the same code in multiple places).
    • Aim for independent and reusable test components.

  2. Maintainability

    • Add new test cases or modify existing ones without breaking unrelated parts.
    • New teammates should be able to understand the structure and contribute.
    • Keep the automation suite usable long-term as the product evolves.

  3. Readability

    • Code should be understandable by everyone on the team.
    • Avoid unnecessarily complex Java features (e.g., streams/lambdas/advanced constructs) when simpler Java works—because testers may not need deep programming knowledge.

Types of Automation Frameworks

Built-in Frameworks

  • Pre-built libraries/tools available in the market.
  • Examples mentioned:
    • TestNG (Java): parallel testing, parameterization, data providers, grouping, etc.
    • JUnit (Java): similar features; TestNG considered to include extra features like parallel execution and report generation.
    • Cucumber (Java + BDD support): for behavior-driven development (BDD).
    • Robot Framework: keyword-driven style; especially popular with Python.
  • Note: different BDD tools exist for different languages (e.g., JBehave for Java mentioned indirectly; Serenity for C#).

Customized Frameworks

  • User-defined frameworks built to meet project-specific needs.
  • A common customized approach is the Hybrid framework:
    • Combines multiple techniques (e.g., modular + data-driven, keyword-driven + data-driven, etc.).
    • Often used with open-source tools to integrate missing features via third-party libraries.

Why Built-in Frameworks Are Necessary but Not Sufficient

  • The lecture emphasizes:
    • You must use built-in frameworks as a foundation.
    • You cannot build a fully-fledged framework using only built-in tools—you still need additional layers like reports, custom behavior, and third-party integrations.
  • That top layer becomes the customized/hybrid framework.

Methodology: Steps to Design and Develop an Automation Framework (Phased Approach)

The process is described in five phases/stages before execution and long-term use.

1) Analyze the Application Under Test (AUT)

  • Goal: understand what exists in the application so the team can plan automation.

  • Key activities:

    • Identify how many pages/screens the application has.
    • For each page, determine what types of elements exist (custom elements vs built-in).
    • Identify which parts can be automated vs must remain manual.
    • Perform the analysis from the application perspective (not from test cases yet).

  • Practical planning outcomes:

    • Knowing page count helps estimate number of Page Object classes and team effort.
    • Knowing element types helps plan how to automate tricky/custom UI elements.
    • Acknowledges that automation is not 100% in the absolute sense—some checks (visual/cosmetic, image comparison, etc.) may remain manual.

2) Choose Test Cases for Automation

  • Prerequisite: manual test cases and test planning should be ready.

  • Timing/build stability constraint:

    • Start automation only after the build becomes stable (the instructor suggests manual rounds first, e.g., “3 to 4 cycles” until sanity/basic functional checks pass).

  • Meaning of “100% automation” (interview clarification):

    • It does not mean automating everything (including non-automatable items).
    • It means automating all test cases that are automatable.
    • Example:
      • If 100 test cases exist and 90 are automatable, then automating those 90 corresponds to “100% automation” in the intended sense.

  • Prioritization criteria (P1–P4):

    1. P1: Sanity test cases (basic functionality)
      • Must pass; otherwise stop further execution.
    2. P2: Data-driven and/or re-test cases
      • Tests requiring data sets or repeated execution.
    3. P3: Regression test cases
      • Regression depends on fixes/bugs and impacted areas.
      • Once bugs are fixed, regression must confirm behavior and surrounding impacts.
      • Emphasis: regression should strongly prefer automation.
    4. Remaining test cases (optional depending on time)
      • Automate additional cases only if time permits after P1–P3.

3) Design the Framework (Blueprint)

  • Design output: a blueprint including folder structure and mapping components.

  • Design includes:

    • Organizing where page objects, test cases, utilities, test data, etc. live.
    • Ensuring the team follows the same structure so different test cases integrate smoothly.

  • Team roles:

    • Often designed primarily by senior/experienced members (3–5+ years) with prior framework experience.
    • Interview note:
      • If you claim you fully designed it, be ready for deep questions.
      • Otherwise describe contributions (e.g., created page objects/utilities/test cases or helped in regressions).

4) Development (Build the Framework Components)

  • What happens in development:

    • Create utility files
    • Implement/add Page Object classes
    • Write and integrate test cases
    • Add supporting configuration and structure (as part of the overall architecture)

  • Outcome: the framework becomes ready for execution.

5) Execution

  • Execution can run in different modes:

    • Local execution: run tests from the IDE/local environment.
    • Remote execution: run tests on remote machines/environments.

  • Technologies mentioned:

    • Selenium Grid for cross-browser/remote execution.
    • Jenkins for CI-driven remote runs:
      • Jenkins pulls code from repositories and runs in remote environments.

6) Maintenance (Long-term Integration and Repository Workflow)

  • Why maintenance is crucial:

    • Multiple people add page objects/tests/utilities over time.
    • Everything must be integrated and centrally stored.

  • Repository concepts:

    • Local repository: individual developer’s local work.
    • Remote/global repository: shared repository where team integrations happen.
    • Jenkins pulls updated code from remote repos and runs automatically.

  • This is described as the day-to-day process to keep the framework stable and usable over time.

Application Focus: What They Plan to Automate and How They Set It Up for Practice

Why E-commerce Is Used for Practice

  • E-commerce apps are widely available as demo/open-source systems.
  • Other domains like banking/healthcare are more sensitive and harder to access publicly.
  • Lecture emphasis: e-commerce workflows are similar across vendors:
    • search → cart → registration/login → checkout → order tracking → reviews, etc.
  • Domain knowledge differences:
    • Banking/healthcare terminology can be harder without real exposure.
    • E-commerce offers transferable workflow experience.

Front-end vs Back-end Operations (Conceptual Split)

Front-end (User-facing)

Includes:

  • register, login
  • product search, add to cart, watch list
  • checkout, payment
  • order tracking, reviews/comments
  • modify/remove cart items

Back-end (Admin-facing)

Includes:

  • manage products/categories, orders, customers/customers groups
  • approvals, returns, subscriptions
  • stock/inventory, shipping statuses, reports, etc.

Testing Scope in This Project

  • This automation series focuses mainly on front-end.
  • Back-end may be tested manually (database-centric), not automated in the primary plan.

Specific Application Referenced: OpenCart

  • OpenCart is introduced as an online store management system (PHP-based, using a MySQL/PostgreSQL-style database, with HTML components).
  • Provided two interfaces:
    • Front-end demo for customer/user flows.
    • Back-end admin demo (demo/demo credentials referenced).
  • Also discussed:
    • limitations of online demos (e.g., restricted database access/automation limitations).
  • For practice, they suggest installing and running OpenCart locally to access:
    • admin pages
    • database tables
    • APIs (for API testing needs, though API automation isn’t the focus here)

Local Setup Approach (for Practice)

  • Suggested tool: XAMPP

    • Advantage: installs Apache + MySQL + PHP together.

  • High-level setup overview:

    • Install XAMPP.
    • Start required components (Apache and MySQL; Tomcat mentioned but optional).
    • Install OpenCart and access it via localhost.
    • Access:
      • front-end site
      • admin panel
      • database tables (to enable deeper validation such as end-to-end checks)

Test Case Documentation and Selection for Automation

Excel Test Repository Described

  • The instructor uses a large Excel document (hundreds of test cases, described as ~300–500 test cases and 38–41 scenario sheets).
  • Structure described:
    • Scenario sheets: list test scenarios (e.g., register account, login, logout, forgot password).
    • Test case sheets/templates: include test case IDs, titles, prerequisites, steps, test data, expected results, actual results, and priority.
  • Includes positive/negative/UI-focused scenarios.
  • Clarification: not everything can/should be automated—select key end-to-end coverage.

End-to-end Testing Explanation

  • End-to-end = validating multiple layers within one workflow:
    • Front-end action (e.g., register a user)
    • Validate in admin interface (customer/user appears)
    • Validate in database tables (record exists in the DB)
  • Synchronization across systems is emphasized as a key quality goal.

What Will Be Automated in This Project Series

  • From the large document, they will not automate everything.
  • They plan to demonstrate automation using a small number of representative end-to-end tests (about 4–5 test cases), such as:
    • registration
    • login (including a data-driven login example with multiple credential combinations)
    • search
    • product compare
    • add to cart + ordering flow (end-to-end)

Planned Framework Implementation / Architecture (Near the End)

  • The session previews a framework structure (folders/layers) including:

    • Page object classes
    • Test cases
    • Execution via XML files
    • Execution via Maven / pom.xml (and related run options)
    • Utility files
    • Test data files
    • Resources/config files
    • Reports and logs generation

  • CI/CD workflow preview:

    • Push code to GitHub (from local/git)
    • Jenkins pulls from GitHub and runs in remote environments
    • Selenium Grid integrated for multi-browser/OS type execution

Speakers / Sources Featured

  • Speaker: The video instructor (name not provided in subtitles).
  • Tools / sources referenced:
    • TestNG
    • JUnit
    • Cucumber
    • Robot Framework
    • Selenium Grid
    • Jenkins
    • GitHub / Git / repositories
    • OpenCart
    • XAMPP
    • Maven (pom.xml)
    • OpenCart-related tech terms: PHP, MySQL/PostgreSQL, HTML components

Original video