Forem: Pradip Baskota

Building a Test Strategy from the Ground Up: The ParaBank Example

Pradip Baskota — Mon, 21 Jul 2025 02:54:44 +0000

Series Recap: How We Got Here

In Part 1, I introduced the goals of this series: to transparently document the end-to-end QA process for a real-world application, ParaBank, and to share both technical and strategic insights as a QA Lead. We discussed the importance of strong test artifacts, risk management, and learning in public.

In Part 2, I walked through my approach to understanding a new application from scratch. We explored ParaBank's business context, performed hands-on exploratory testing, and began documenting features, user journeys, and initial test scenarios. This groundwork ensures that our test strategy is rooted in real observations and business needs—not just theory.

Introduction

A great test strategy is the foundation of every successful QA project. It's the high-level blueprint that defines how testing will be conducted, what tools and methods will be used, and how quality will be measured. In this post, I'll show you how to create a robust test strategy, why it's the first artifact you should prepare, and walk you through a real-world example for the ParaBank web application.

What is a Test Strategy?

A Test Strategy is a static, high-level document that defines the overall approach to testing for a project or organization. It covers methodologies, tools, scope, responsibilities, and quality metrics. Once created, it rarely changes and guides all future test planning and execution.

Why is the Test Strategy the First Artifact?

Establishes standards and consistency
Aligns all QA team members and stakeholders
Prevents ad-hoc or inconsistent testing practices
Supports risk-based planning and resource forecasting

Structure of a Test Strategy Document

Here's a breakdown of the key sections you should include:

Section	Description
1. Scope & Objectives	What will be tested and the purpose of testing.
2. Testing Types/Levels	Unit, integration, system, UAT, performance, security, etc.
3. Testing Approach	Manual vs automation, black-box, white-box, exploratory, risk-based testing.
4. Test Environment Setup	Hardware, software, tools, staging configuration.
5. Test Deliverables	List of expected artifacts: test plan, cases, RTM, reports, etc.
6. Entry & Exit Criteria	When to start or stop testing activities.
7. Test Tools	Defect tracking (e.g. Jira), test management (e.g. TestRail), automation (e.g. Selenium, JUnit).
8. Roles and Responsibilities	Who does what: Testers, Leads, Devs, PMs.
9. Risk Management	Potential risks and how to mitigate them (e.g. delay in test environment setup).
10. Communication Plan	Status meeting frequency, stakeholder reporting, defect triage process.
11. Metrics & KPIs	Defect density, test coverage, pass rate, etc.
12. Automation Strategy	What will be automated, tools used, when to execute.

Sample Test Strategy: ParaBank Web Application

Below is a real-world test strategy for the ParaBank demo site. This document is tailored to the project's needs and can serve as a template for your own work.

📋 Test Strategy Document – ParaBank Web Application

1. Scope & Objectives

Scope: Functional and non-functional testing of the ParaBank web application, focusing on core banking modules: login, registration, account management, transactions, and customer service.

Objectives:

✅ Validate all critical business and technical requirements
✅ Ensure stability, usability, and security of ParaBank's features
✅ Enable repeatable, scalable, and maintainable testing through automation and best practices

2. Testing Types/Levels

Testing Type	Description	Priority
Unit Testing	Out of scope for QA (assumed covered by development)	N/A
Integration Testing	Validate integration points (login, account, transactions)	High
System Testing	End-to-end validation of all user flows	Critical
User Acceptance Testing (UAT)	Simulate real user scenarios for business sign-off	High
Regression Testing	Ensure new changes don't break existing functionality	Critical
Smoke Testing	Quick checks of critical paths after deployments	Critical
UI/UX Testing	Validate layout, responsiveness, and usability	Medium
Security Testing	Basic checks (session timeout, error messages, no sensitive data in logs)	High
Cross-Browser Testing	Chrome, Firefox, Edge (latest versions)	Medium

3. Testing Approach

Manual Testing: For UI, exploratory, and new features
Automation Testing: Java + Selenium WebDriver for regression, smoke, and high-value functional tests
Test Design: Black-box, risk-based, and data-driven techniques
Agile Iterations: Iterative testing aligned with sprints (if applicable)

4. Test Environment Setup

Component	Details
Application	ParaBank demo site (public)
Browsers	Chrome, Firefox, Edge (latest)
OS	Windows, macOS
Test Data	Managed by QA, anonymized where needed
Staging/QA Environment	Use public demo; monitor for downtime

5. Test Deliverables

📄 Test Plan
📋 Test Cases (manual and automated)
🔗 Traceability Matrix (RTM)
🐛 Defect Logs
📊 Daily/Weekly Status Reports
📈 Test Execution and Summary Reports
📊 Automation Reports (Allure/Extent)

6. Entry & Exit Criteria

Entry Criteria:

✅ Requirements reviewed and approved
✅ Test environment ready
✅ Test data available

Exit Criteria:

✅ 95% test case execution
✅ All critical/high bugs closed or deferred with approval
✅ Test Summary Report submitted

7. Test Tools

Category	Tools
Test Management	Google Sheets, Excel, or test management tool
Automation	Java, Selenium WebDriver, TestNG/JUnit, Maven/Gradle
Defect Tracking	GitHub Issues or spreadsheet
Reporting	Allure, Extent Reports
CI/CD	GitHub Actions
Collaboration	GitHub, Slack/Teams (if available)

8. Roles and Responsibilities

Role	Responsibilities
Test Lead	Strategy, planning, review, reporting
QA Engineers	Test case design, execution, automation
Dev Lead	Support for environment, defect resolution
Product Owner	Requirement clarifications, UAT sign-off

9. Risk Management

Risk	Mitigation Strategy
Demo site instability	Monitor site status, retry failed tests, communicate outages
Test data volatility	Use unique or resettable data where possible
Tool learning curve	Document learning process, leverage community resources
General Mitigation	Early risk identification, regular status updates, backup plans

10. Communication Plan

Activity	Frequency
Daily Standup	Daily - Quick sync on progress and blockers
Defect Triage	Twice weekly or as needed
Status Reports	Weekly summary to stakeholders
Sprint Demo/Test Report	At the end of each iteration

11. Metrics & KPIs

Metric	Target
Test coverage target	90%+
Defect leakage rate	< 5%
Automation coverage goal	70% for regression
Test case execution	Track pass/fail/block
Defect density and status	Monitor trends
Test cycle duration	Optimize for efficiency

12. Automation Strategy

Scope: Automate regression, smoke, and high-value functional tests
Framework: Page Object Model, data-driven, modular design
Tools: Java, Selenium WebDriver, TestNG/JUnit, Maven/Gradle
Reporting: Allure or Extent Reports
CI/CD: GitHub Actions for automated execution
Execution: Automated suite runs on every code push or nightly

💡 Note: Once this document is reviewed and approved, it becomes the foundation for the Test Plan and execution phases.

Key Takeaways for Your Test Strategy

1. Start with Business Context

Your test strategy should reflect the business domain. For ParaBank, we focused on banking-specific concerns like security, data integrity, and regulatory compliance.

2. Define Clear Scope Boundaries

Be explicit about what's in and out of scope. This prevents scope creep and helps manage stakeholder expectations.

3. Balance Manual and Automation

Not everything needs to be automated. Manual testing is still valuable for exploratory testing, UI validation, and new features.

4. Plan for Real-World Constraints

Consider practical limitations like demo site availability, test data management, and tool learning curves.

5. Establish Measurable Success Criteria

Define clear metrics and KPIs that stakeholders can understand and track.

Common Pitfalls to Avoid

❌ Over-Engineering

Don't create a strategy that's too complex for your team or project size. Keep it practical and achievable.

❌ Copy-Paste Approach

Every project is unique. Customize your strategy based on the specific application, team, and business context.

❌ Static Thinking

While the strategy document is static, be prepared to adapt your approach based on learnings and changing requirements.

❌ Tool-First Approach

Don't start with tools. Begin with objectives, then select tools that support your goals.

Next Steps: From Strategy to Execution

With your test strategy in place, you're ready to move to the next phase: Test Planning. The strategy provides the framework; the test plan will detail the specific activities, timelines, and resources needed.

In the next post, I'll show you how to create a detailed test plan that transforms this high-level strategy into actionable testing activities. We'll cover:

Detailed test case design
Resource allocation and timelines
Risk mitigation strategies
Test execution planning

Conclusion

A well-crafted test strategy is your roadmap to quality. It brings clarity, consistency, and confidence to your testing process. Use the structure and sample above to guide your own projects, and remember: a strong strategy is the first step to successful, scalable QA.

Ready to dive deeper? In the next post, we'll transform this strategy into a detailed test plan and start designing our first test cases. Follow along as we continue building quality from the ground up!

What aspects of test strategy creation do you find most challenging? Share your experiences in the comments below, and let's continue the conversation about building robust QA processes.

How to Approach QA Testing for an Application You Know Nothing About

Pradip Baskota — Sun, 06 Jul 2025 08:32:22 +0000

Introduction

Starting QA testing on a completely new application can be overwhelming, especially when you have no prior knowledge of the system. This guide walks through my systematic approach to understanding and testing an unfamiliar application from scratch. Whether you're a junior QA engineer or transitioning to a new project, these steps will help you build a solid foundation for effective testing.

My Experience Context

I've worked as a QA engineer for insurance applications and have used various banking applications as a user. However, when I encountered Parabank (a banking application), I had zero prior knowledge of its specific functionality. This document captures my thinking process and methodology for approaching a project from scratch.

Step 1: Understand the Purpose of the Software

Objective

Get a high-level understanding of what the software does, who uses it, and why it exists.

Why This Matters

Without understanding the purpose, you'll test blindly without context. Understanding the business goals helps you identify what's truly important to test.

Actions to Take

1.1 Gather Available Documentation

Ask for product documentation, user manuals, or functional specifications (if available)
Review any existing technical documentation
Look for API documentation or database schemas
Check for user stories or requirements documents

1.2 Identify Key Stakeholders

Primary users - Who uses this software daily?
Secondary users - Who uses it occasionally?
Administrators - Who manages the system?
Business stakeholders - Who benefits from the software?

1.3 Understand Business Context

What problem does this software solve?
What are the primary business use cases?
What are the critical workflows?
What would cause business impact if broken?

Documentation to Create

Software overview - High-level description in your own words
Key stakeholders and contacts - Who to ask questions
Primary goals and business use cases - Why the software exists
Data flow diagram - How information moves through the system

Sample Documentation Based on Parabank Exploration

Software Overview

Parabank is an online banking application that allows customers to manage their personal banking needs through a web-based interface. The system provides core banking functionalities including account management, fund transfers, bill payments, transaction history, and loan applications.

Primary Users: Individual banking customers who need to manage their personal finances online.

Core Purpose: Provide secure, convenient access to banking services without visiting a physical branch.

Key Stakeholders and Contacts

Primary Users: Individual banking customers
Secondary Users: Banking staff (for support)
System Administrators: IT team managing the banking platform
Business Stakeholders: Banking management team

Primary Goals and Business Use Cases

Account Management: Customers can view and manage their bank accounts
Fund Transfers: Customers can transfer money between accounts
Bill Payments: Customers can pay bills through the banking system
Transaction History: Customers can search and view their transaction history
Loan Applications: Customers can apply for loans online
Profile Management: Customers can update their contact information

Pro Tip

Create this documentation in simple terms that you can explain to someone unfamiliar with the system. This becomes valuable onboarding material for future team members.

Step 2: Explore the Software (Exploratory Testing)

Objective

Familiarize yourself with the interface, workflows, and system behavior through hands-on exploration.

Why This Matters

You can't test what you don't understand. Exploratory testing helps you build mental models of how the system works.

Actions to Take

2.1 Get Access and Basic Setup

Obtain login credentials and access to the system
Understand the basic navigation structure
Identify the main entry points (login, registration, etc.)

2.2 Systematic Exploration

Navigate through each major section of the application
Try both valid and invalid actions to understand error handling
Document the user journey step by step
Note any confusing or unexpected behaviors

2.3 Document Your Findings

Navigation flows (screen-by-screen progression)
Basic features and expected behavior
Any anomalies or bugs (early observations)
Screenshots with annotations for future reference

Example: My Parabank Exploration

When I explored Parabank, I documented:

Login Module - Created credentials and accessed the system
Account Management - Opened new checking accounts from "Open New Account" page
Account Overview - Checked account details from "Accounts Overview" page
Bill Pay - Used "Bill Payment Service" page for bill payment
Fund Transfers - Used "Transfer Funds" page for money transfers
Transaction Search - Explored "Find Transactions" with various search criteria:
- Transaction ID search
- Date-based search (MM-DD-YYYY format)
- Date range search
- Amount-based search
Profile Management - Updated contact information via "Update Contact Info"
Loan Applications - Applied for loans through "Request Loan" page
Logout Functionality - Verified proper session termination

Navigation Structure Discovered:

Sidebar with main sections:
- Account Services
- Open New Account
- Accounts Overview
- Transfer Funds
- Bill Pay
- Find Transactions
- Update Contact Info
- Request Loan
- Log Out

Step 3: Create Comprehensive Documentation

Objective

Build a knowledge base that you and others can reference for effective testing.

Documentation Types to Create

3.1 Feature Inventory / Mind Map

What to document:

All modules, features, and screens
What each feature does
How features relate to each other
User personas for each feature

Format suggestions:

Mind map with main features as branches
Feature matrix with descriptions
User journey maps

3.2 Test Scenarios (High-Level)

For each feature, document scenarios like:

Login Feature:
- Valid credentials login
- Invalid credentials login
- Blank field validation
- Password reset functionality
- Session timeout behavior
Account Creation:
- Successful account opening
- Invalid data submission
- Duplicate account prevention
- Required field validation

3.3 Detailed Test Cases

Create step-by-step test cases for critical areas:

Prerequisites - What needs to be set up first
Test Steps - Exact actions to perform
Expected Results - What should happen
Test Data - What data to use
Environment - Where to run the test

Step 4: Create a Basic RTM (Requirement Traceability Matrix)

Objective

Since formal requirements may not exist, reverse-engineer them based on observed behavior.

Note

RTM creation is a complex topic that deserves its own dedicated blog post. We'll cover the detailed process of creating and maintaining a comprehensive Requirement Traceability Matrix in a separate article, as it involves specific methodologies, tools, and best practices that go beyond the scope of this introductory guide.

Basic Understanding

For now, understand that an RTM is a living document that:

Maps requirements to test cases
Tracks test coverage
Evolves as your understanding of the system matures
Helps ensure no critical functionality is left untested

What to Do Now

Document observed behaviors as you explore the application
Note any gaps where functionality exists but isn't covered by tests
Keep track of critical features that need thorough testing
Prepare for detailed RTM work in the dedicated blog post

Step 5: Check for Tools & Environments

Objective

Understand the technical ecosystem and available resources for testing.

Actions to Take

5.1 Environment Assessment

Ask about test/staging environments - Is there a separate environment for testing?
Learn the tech stack - Backend, frontend, APIs, database
Understand deployment flow - How does code get to production?

5.2 Tool Evaluation

Version control - How is code managed?
CI/CD pipelines - How is testing integrated?
Bug tracking - Where do you report issues?
Test case management - How do you organize test cases?

5.3 Documentation

Access URLs and credentials for all environments
Tooling ecosystem used by the team
Deployment flow documentation

Note

If you only have access to a public environment (like I did with Parabank), document that limitation and its impact on testing scope.

Step 6: Identify Risk Areas & Create Smoke Tests

Objective

Focus testing efforts on high-risk, high-impact areas first.

Risk Assessment Process

6.1 Identify High-Risk Areas

Critical business workflows - What would break the business?
High-usage features - What do users do most often?
Data-sensitive operations - Money transfers, personal information
Integration points - Where systems connect
Known unstable areas - Features with previous issues

6.2 Create Smoke Test Suite

Smoke tests should verify core functionality quickly:

Login/logout functionality
Critical user journeys (e.g., account creation, money transfer)
Basic navigation through main sections
Essential error handling (invalid inputs, network issues)

Smoke test characteristics:

Quick to execute (5-15 minutes)
High-level functionality
Critical for business operations
Should run before detailed testing

Step 7: Gradually Build a Test Strategy

Objective

Develop a comprehensive testing approach that evolves with your understanding.

Strategy Components

7.1 Define Test Types

Based on your exploration, decide which test types to apply:

Functional Testing - Does each feature work as expected?
Regression Testing - Do new changes break existing functionality?
Integration Testing - Do different parts work together?
Performance Testing - Does the system handle expected load?
Security Testing - Are there vulnerabilities?
Usability Testing - Is the interface user-friendly?
Accessibility Testing - Can users with disabilities use it?

7.2 Set Priorities

Prioritize based on:

Business impact - What would cost the most if broken?
User frequency - What do users do most often?
Complexity - What's most likely to have bugs?
Recent changes - What was recently modified?

7.3 Decide on Manual vs Automation Scope

Consider automation for:

Repetitive tests - Login, basic navigation
Regression tests - Features that rarely change
Data-driven tests - Same logic, different data
Smoke tests - Quick verification of core functionality

Keep manual for:

Exploratory testing - Finding unexpected issues
Usability testing - User experience evaluation
Complex scenarios - Hard to automate workflows
One-time tests - Not worth automating

Step 8: Continuous Improvement

Objective

Refine your approach based on findings and feedback.

Improvement Areas

Update documentation as you learn more
Refine test cases based on actual behavior
Adjust priorities based on bug patterns
Expand test coverage in high-risk areas
Share knowledge with team members

Conclusion

Approaching a new application for QA testing doesn't have to be overwhelming. By following this systematic approach, you can build a solid foundation of understanding and create effective test strategies. Remember that this is an iterative process - your understanding and testing approach will evolve as you learn more about the system.

The key is to start with exploration, document everything, and gradually build a comprehensive testing strategy that aligns with business goals and user needs.

Key Takeaways

Start with understanding - Know what the software does before testing it
Explore systematically - Document your journey through the application
Create reusable documentation - Help yourself and future team members
Focus on high-risk areas - Prioritize what matters most
Build incrementally - Don't try to test everything at once
Adapt and improve - Refine your approach based on findings

This approach has helped me successfully test applications I knew nothing about, and I hope it helps you do the same!

Building Quality from Scratch: A QA Lead’s Complete Guide to Test Automation with Java & Selenium

Pradip Baskota — Fri, 04 Jul 2025 05:36:54 +0000

Introduction

Welcome to my QA project series! As a passionate QA Lead, I’ve embarked on a journey to demonstrate the full spectrum of quality assurance practices—right from requirements analysis and test planning, through manual and automated testing, to reporting, risk management, and open-source community engagement. This series is not just a technical walkthrough, but a real-world showcase of how a QA Lead approaches, structures, and delivers quality in software projects.

What Are We Doing in This Series?

This series is a hands-on, transparent look at how to:

Create, review, and manage all key test artifacts (test plans, strategies, cases, data, reports, and more)
Design and execute both manual and automated tests for a real-world demo application (ParaBank)
Implement best practices in traceability, risk management, and communication
Open source the entire framework and documentation for the benefit of the QA community
Leverage Java and Selenium for test automation—with a special note: Selenium with Java is a new tool for me, and I will be documenting my learning process, challenges, and discoveries as I go. This adds an extra layer of authenticity and relatability for anyone else learning new tools on the job.

My Experience and Motivation

In my 5-year career as a QA Lead, I have:

Worked extensively with Python and Selenium for UI testing
Used Python for API testing
Employed Docker for containerization of test environments
Utilized Allure for test reporting
Integrated automated tests into CI pipelines
Designed and implemented test automation frameworks from scratch

Now, I want to bring together everything I have learned and demonstrate how to approach a new tool—Java with Selenium—from the ground up. My goal is to show how a strong QA mindset, technical skills, and best practices can transfer across tools and languages. I’ll be sharing not only the technical steps, but also the thought process, decision-making, and lessons learned along the way. This series will also serve as a guide for anyone starting from scratch, showing how to build a robust QA process and framework regardless of the technology stack.

The goal is to provide a practical, end-to-end reference for QA professionals, aspiring leads, and anyone interested in structured, professional software testing.

How Are We Doing It?

Step-by-step documentation: Every phase, artifact, and decision will be documented and explained, with templates and real examples.
Real application: We’ll use the ParaBank demo site to ground our work in realistic scenarios.
Balanced approach: Both manual and automation testing will be covered, showing how they complement each other.
Open source mindset: All templates, code, and reports will be shared in a public repository for learning and collaboration.
Continuous reflection: Each phase will include lessons learned, challenges faced, and improvements made.
Learning in public: As I learn Selenium and deepen my Java automation skills, I’ll share not just the successes, but also the hurdles, resources, and tips that help me along the way.

Things to Keep in Mind

Quality is a process, not a checkbox. It’s about building confidence in the product through repeatable, transparent practices.
Communication is key. Clear documentation, regular status updates, and stakeholder engagement are as important as the tests themselves.
Traceability ensures coverage. Mapping requirements to test cases and defects helps prevent gaps and supports impact analysis.
Adaptability matters. Requirements change, environments shift, and new risks emerge—being flexible and proactive is essential.
Learning never stops. Every project, even a hobby one, is an opportunity to refine skills and share knowledge.

Managing Risks

Risk management is woven into every phase of this project:

Early identification: Risks are logged and reviewed from the outset, not just when issues arise.
Mitigation planning: For each risk, we define clear mitigation strategies—whether it’s ambiguous requirements, environment instability, or tight timelines.
Transparent reporting: Risks and their statuses are communicated in status reports and closure summaries.
Lessons learned: After each phase, we reflect on what worked, what didn’t, and how to improve risk management going forward.

Increasing the Chance of Project Success

Thorough planning: Investing time in requirements analysis, test planning, and environment setup pays off throughout the project.
Prioritization: Focusing on business-critical flows and high-impact areas ensures that the most important risks are addressed first.
Automation where it counts: Automating regression and smoke tests accelerates feedback and reduces manual effort.
Collaboration: Engaging with stakeholders, developers, and the QA community brings diverse perspectives and uncovers blind spots.
Documentation: Well-maintained artifacts make onboarding, maintenance, and audits easier for everyone.

What Do We Expect from This Journey?

A living reference: By the end, we’ll have a complete, open-source set of QA artifacts, templates, and automation code that anyone can use or adapt.
Community value: Sharing not just the successes, but also the challenges and lessons learned, will help others avoid common pitfalls.
Personal growth: This project is a chance to deepen my own expertise, experiment with new tools and techniques, and give back to the QA field.
Inspiration: I hope this series inspires others to approach QA with curiosity, rigor, and a spirit of continuous improvement.

Conclusion

Whether you’re a seasoned QA professional or just starting out, I invite you to follow along, contribute, and share your own experiences. Quality is a journey, and together we can raise the bar for what great testing looks like.

Stay tuned for the next post, where we’ll dive into the first set of test artifacts and how to create them from scratch!

Introducing My Python Selenium Framework: A Solid Foundation for UI Testing

Pradip Baskota — Tue, 24 Jun 2025 04:48:56 +0000

Let's be honest: UI test automation can feel like herding cats. You write a test, it passes. You run it again, it fails. You run it a third time, and it passes—just to keep you guessing. If you've ever wanted to throw your laptop out the window after a flaky test run, you're not alone. (Don't worry, your secret's safe with me.)

After years of wrestling with this chaos, I decided to build something that would bring order to the madness—a UI test automation framework that's not just reliable, but actually fun to use. (Yes, really!) Today, I'm excited to introduce this open-source framework, built with Python, Selenium, and Pytest. It's like a Swiss Army knife for UI testing, minus the risk of poking yourself.

This post kicks off a series where I'll dissect every part of this framework, sharing the design choices, the code, and the lessons learned (sometimes the hard way). My goal? To help you, dear reader, and to level up my own skills along the way.

You can view and clone the complete project on GitHub here: View the Framework on GitHub

The Philosophy: Stability, Maintainability, and Readability

This framework is built on three core principles:

Stability Over Speed: A fast but flaky test is useless. This framework prioritizes stability above all else by embedding best practices like explicit waits and robust error handling into its very core.
Maintainability is a Feature: Test code is production code. It must be clean, modular, and easy to refactor. A test that's hard to maintain will eventually be abandoned.
Readability is Non-Negotiable: A good test should read like a manual test case. A non-technical stakeholder should be able to look at a test script and understand what it's trying to achieve.

An Architectural Tour

To achieve these goals, the framework is organized into a clean, layered architecture. This separation of concerns is crucial for maintainability.

ui-test-automation/
├── base/         # Core components: Selenium wrappers, WebDriver factory
├── pages/        # Page Object Model: Locators and actions for each page
├── tests/        # The actual Pytest test scripts
├── testdata/     # Configuration files and test data
└── utils/        # Helper utilities: logging, reporting, etc.

base/: The engine of the framework. It handles the low-level browser interactions.
pages/: Implements the Page Object Model (POM), abstracting page details away from the tests.
tests/: Contains the high-level test logic. These files describe what to test, not how to test it.
testdata/: Manages configuration, separating sensitive data and environment-specific settings from the code.
utils/: A collection of tools that support the framework, like a custom logger and assertion tracker.

The Three Pillars of the Framework

Three key patterns form the foundation of this project:

1. The Page Object Model (POM)

The Page Object Model is a design pattern that organizes your test code by giving each page (or component) its own class. This class contains all the locators and actions for that page, making your tests easier to read, maintain, and scale.

# pages/demoqa/elements_page.py

class ElementsPage(DemoQABase):
    # --- Locators (strategy, value, description) ---
    HEADER_LINK = ("css", "div#app a[href='https://demoqa.com']", "Header Link")
    TEXT_BOX_MENU = ("xpath", "//span[contains(text(), 'Text Box')]", "Elements Card")

    def __init__(self, driver):
        super().__init__(driver)
        self.url = f'{self.base_url}elements'

    def is_at(self):
        """Verifies we are on the correct page."""
        return self.is_element_present(self.TEXT_BOX_MENU)

If a UI locator changes, you only need to update it in one place. Your future self will thank you.

2. The Selenium Wrapper

Instead of calling Selenium commands directly, our Page Objects inherit from a powerful SeleniumWrapper class. This wrapper enhances basic commands with built-in explicit waits, detailed logging, and smart error handling.

Consider the click() method. It doesn't just click; it waits for the element to be clickable, logs the action, and handles multiple types of exceptions gracefully.

# base/selenium_wrapper.py

def click(self, locator_full, timeout=None):
    """Clicks an element after ensuring it's clickable."""
    timeout = timeout if timeout is not None else self.timeout
    self.log.debug(f"Attempting to click element: {locator_full[2]}")

    element = self.explicitly_wait(locator_full, timeout) # Wait first!
    if not element:
        self.log.error(f"Cannot proceed with click - element not available: {locator_full[2]}")
        return
    try:
        element.click()
        self.log.info(f"Successfully clicked element: {locator_full[2]}")
    except StaleElementReferenceException:
        self.log.error(f"Element became stale before clicking: {locator_full[2]}")
    # ... other exceptions

3. Smart Configuration Management

A framework needs to run on a developer's machine and in a CI/CD pipeline without code changes. Our configuration system handles this by using a layered approach, merging a base config, a local config, and a secrets file.

A simple boolean flag, TEST_RUN_ON_SERVER, determines whether to load settings from local files or from a secure cloud service like AWS Parameter Store, making it perfect for any environment.

Bringing It All Together: A Sample Test

So what does a test look like? Thanks to the architecture, it's clean and readable.

# tests/test_demoqa/test_elements_page.py

@allure.description("validates whether Text Box Page is Working")
@pytest.mark.smoke
def test_text_box_input(self, navigate_to_elements):
    self.log.info("::: test_text_box_input")
    elements_page = navigate_to_elements # Fixture handles navigation

    with allure.step('Navigating to the TextBox Page'):
        text_box_page = elements_page.open_text_box()
        self.status_tracker.assert_true(text_box_page.is_at(), "Navigation to Text Box Page Check")

    with allure.step('Entering Details to the textbox and Submitting'):
        text_box_page.submit_text(
            fullname="Testing Full Name",
            email="testing@email.com",
            current_address="Testing Current Address",
            permanent_address="Testing Permanent Address"
        )

    with allure.step('Verifying the inputs are correctly displayed'):
        self.status_tracker.assert_true(
            text_box_page.check_output(...), "Output Verification"
        )

Notice how the test describes the user's journey. It uses plain English methods from the Page Objects and delegates all the messy implementation details to the framework.

What's Next?

This framework is a solid starting point, but it's just the beginning. It's a living project that I plan to improve continuously.

In my next post, I'll do a deep dive into the Page Object Model, exploring why it's such a critical pattern for writing maintainable tests and sharing more advanced techniques.

Check out the GitHub repository, clone it, run it, and see it for yourself. Leave a comment below with your thoughts, questions, or favorite automation memes. Let's build better automation, together!