Stop building your automation framework.Start automating your application.
Most automation teams don’t spend their first few months writing tests.
They spend them building the same basic foundation that every good framework needs.
Authentication
Page objects
Reporting
Locator handling
Environment management
CI/CD pipelines
Months of infrastructure before the first real test.
Traditional framework
Month 1Authentication
Month 2Page objects
Month 3Reporting
Month 4CI/CD
Month 5Utilities
Month 6Finally writing tests
PrideForge
Day 1Clone the repository
Day 1Run sample tests
Day 2Customize for your apps
Week 1Ship automation
PrideForge starts where most frameworks end.
Start from runnable tests and a production-shaped foundation — reporting, environments, auth
patterns, and CI — then adapt PrideForge for your applications.
You keep the automation you build.
After your subscription ends, your downloaded version, customizations, and tests remain yours.
See the EULA
·
PrideForge Academy provides structured onboarding for framework engineers and test authors,
so every role learns only what it needs.
Built on Playwright, Reqnroll, NUnit, and axe-core.
Overview
PrideForge is a licensed automation solution plus PrideForge Academy
for QA and SDET teams. You receive production-ready software to run in your environment — not a generic
tutorial on building a framework from scratch, personal coaching, or slide-deck-only training.
Your team skips months of foundational architecture and starts from runnable features, steps, page objects,
configs, fixtures, and reporting — then focuses on test coverage and customization for your applications.
Powered by proven open-source tooling
PrideForge brings together modern open-source technologies into one cohesive automation
solution — not a closed platform or a from-scratch tutorial on framework design. You keep
standard tools your team can hire for and maintain; PrideForge is the integration layer,
conventions, and reference implementation.
Reqnroll
Playwright
NUnit
axe-core
The goal is simple: help teams spend less time fighting automation infrastructure
and more time improving software quality.
Solution + course — not course aloneYou are buying software, not just training.
PrideForge Academy does not teach generic “how to write a framework.” It explains a specific,
production-shaped automation solution you already have access to. If you only wanted a video
course on framework theory, this is the wrong product.
Your framework, your choiceYou do not have to adopt PrideForge wholesale.
Many teams purchase a license to study a reference implementation and take away proven patterns:
shared BDD steps instead of per-control boilerplate, named locators, environment configs,
field-handler dispatch, session reuse, table helpers, and reporting discipline. Use PrideForge
as a starting point, cherry-pick patterns into your repo, or simply apply the lessons to refactor
Selenium, Playwright, Cypress, or in-house code — the course explains why each pattern exists
so you can map it to your tools and conventions.
Your real alternative is DIYPrideForge is not competing with a tutorial or a YouTube playlist.
The real comparison is months your team would spend building framework infrastructure —
environments, auth, locators, reporting, and team conventions — before meaningful test coverage.
PrideForge gives you that foundation on day one, structured onboarding for every licensed user,
and unlimited CI so effort shifts to writing tests for your applications. Teams work in readable
Gherkin, not a pile of one-off scripts — so you can start customizing and adding coverage
quickly. See
for how each problem is addressed.
Who is the audience?
QA engineers, automation developers, and tech leads who are building a new framework,
modernizing an existing one, or evaluating PrideForge against what they
already run. Early adopters are often a QA lead, solo SDET, or consultant with budget authority — teams who
need structure now, not after another quarter of framework rework. You might adopt the reference solution
end-to-end, port selected patterns into Selenium or Playwright code you own, or use the lessons as an
architecture guide for your next refactor. Basic C# and Gherkin familiarity helps; we teach the reasoning
behind each pattern, not only PrideForge syntax.
From license to shipping tests
Buy licenseCore Engineer + Academy seats for your team
Assign seatsManagers grant repo and Academy access
Clone repoPrivate PrideForge Core on day one
Run samplesFeatures, fixtures, and reports offline
CustomizeYour customizations stay separate from core
Ship testsUnlimited CI on your infrastructure
How it works
The same open-source tools your team knows — organized so your team writes tests instead of reinventing plumbing.
Integrated automation solution
Open-source stack integrated into a cohesive framework.
From Gherkin to browser
Readable Gherkin wired to shared steps and page objects. Drive the automation with
human-readable instructions.
Handler priority
Handler priority allows PrideForge to find the right behavior for each control automatically.
Built-in handlers cover common HTML, widgets, and compounds. Add your own in the
customization layer and choose where they sit in the order — earlier slots run first, so you
can override a generic default or add support for controls unique to your application.
Targeted runs with tags
Tag features and scenarios with @env, @smoke, or your own labels —
then filter what executes locally or in CI without rewriting scenarios.
Licensing
PrideForge is licensed by named user, not by test volume.
Each site license has two seat types.
Core Engineer includes the private PrideForge Core repository, framework
updates, and PrideForge Academy.
Academy is for team members who need training and documentation only — no
repository access.
Seats cover people, not runners or pipelines. Run unlimited internal automation on your own
infrastructure with no per-run metering.
While your subscription is active, you receive repo access, updates, and Academy.
If you do not renew, you keep the version and customizations you built during the active term.
Repository access, Academy, and future updates require renewal.
Cost comparison
Most teams spend months building authentication, reporting, environments, and CI before real test
coverage. A starter license is often less than 2–4 weeks of one engineer's loaded
cost — for production-shaped software on day one.
DIY: 4–6 months and roughly $50k–$90k loaded labor (one SDET) before meaningful tests
PrideForge: about $3.5k–$8k/year plus weeks to customize for your apps
After subscription: you keep what you built — the license buys speed and a proven foundation
Core Engineers pull PrideForge Core into your company's repository and apply
framework updates as they are released. Updates change the core only — your customizations stay
separate and are not overwritten.
Academy users learn how to write and maintain tests against your company's copy —
full course, documentation, and learning paths; no private repo access.
Seat counts do not meter runners, pipelines, or CI — only named users need a seat.
How it works
A typical company license
CompanyPurchases site licenses
License managerAssigns seats — does not require a seat themselves
2 Core EngineersPrivate repo + Academy + updates
6 Academy AuthorsCourse and docs only
Unlimited CINamed users are licensed — not test volume
License managers — the buyer can manage seats and purchases without requiring a seat unless they assign one to themselves.
Named users — seats are assigned to individuals, not shared accounts or runners.
Reassign licenses — when people leave or roles change, move seats to current team members without buying again.
Add anytime — purchase more Core Engineer or Academy seats mid-term; new seats are prorated for the remainder of your subscription.
You keep what you build — your customizations remain yours for internal use after your subscription ends. See the EULA.
Volume discounts
PrideForge includes built-in volume pricing for growing teams. Use the license builder to
calculate pricing for your organization.
Full FAQ, worked examples, and checkout are on the
Purchase page.
Why PrideForge
Automation teams should spend their time testing software — not rebuilding automation infrastructure.
Every section below answers how PrideForge helps you get there. When you are ready to license,
build your license on the Purchase page.
The problem
Every automation project begins the same way. Before anyone writes meaningful tests, someone has
to build authentication, reporting, environment management, page objects, CI pipelines, locator
strategies, configuration, and onboarding documentation. None of this is unique to your
application — yet every team rebuilds it.
Who can write tests
With most automation stacks — Playwright, Selenium, Cypress, and similar tools — meaningful
test authoring usually stays with engineers. They are code-first, and easy to get wrong
without programming skills, async patterns, and project structure.
Record-and-playback looks easier, but the tests it produces are usually brittle, hard to
maintain, and weak at expressing what behavior matters. They rarely scale for a team
maintaining coverage over years.
PrideForge adds readable Gherkin, reusable steps, and Academy training so product owners,
manual testers, business analysts, and domain experts can write and review scenarios.
Engineers maintain the framework underneath — step definitions, page objects, and handlers —
so your team is not waiting on one specialist for every new test.
Why teams choose PrideForge
Start writing tests sooner
Runnable software on day one — skip months of plumbing and begin with production-shaped patterns your team can run immediately, not an empty tutorial repository.
Built on tools you know
Reqnroll, Playwright, NUnit, and axe-core — familiar open-source tools wired together by PrideForge.
Onboard the whole team
Managers buy faster onboarding, not slide decks. PrideForge Academy teaches shared standards mapped to the solution you license — Gherkin and shared steps widen who can author tests while engineers maintain how scenarios run.
Readable specs, readable reports
Gherkin scenarios describe behavior in plain language; reports show which steps ran and failed, not opaque method calls.
Keep customizations separate
Your modifications stay separate from the framework core — extend PrideForge without forking so upgrades stay predictable.
Reduce framework maintenance
Named locators, shared steps, and consistent patterns mean less rework when applications change.
Keep what you build
Your features, page objects, and configs remain yours for internal automation after your subscription ends.
Architecture
PrideForge separates your customizations from the framework so upgrades remain predictable and
your automation stays maintainable.
Private Core repository — framework infrastructure plus a separate layer for your apps and modifications.
The business case
Managers approve tools when the math is clear. PrideForge is not competing with free
open-source automation tools — it replaces months of cost and effort building a framework.
Illustrative cost and time comparison
Typical DIY build
PrideForge
Calendar time to coverage
4–6 months
Days to weeks
Year 1 loaded labor*
$50k–$90k (1 engineer)
License + customization time
Starter license (example)
—
~$3,500/year (1 Core + 3 Academy)
*Illustrative ranges only. Assumes one SDET at $125k–$175k fully loaded, with a quarter to half
a year on infrastructure. See the full table on
Purchase.
Test writing
Describe behavior in readable Gherkin while shared steps handle browser automation once — so new tests
focus on your application, not repeated setup. The same language works as living documentation for
reviewers and in run reports: stakeholders see which business steps passed or failed, not source lines.
Login scenario
Imperative test code on the left; a few lines of Gherkin on the right — same behavior, less boilerplate per test.
login.spec.ts — code-first test
Standard code-first test
Every test repeats navigation, locators, and assertions.
Shared steps and named page objects — selectors stay out of the scenario.
1Feature: Local login
2 3Scenario: Successful login with local admin user
4Given I am logged in as "admin" 5Then The "LocalLoginHandler.AuthStatus" field
6 should contain "Authenticated as admin"
Both use the same browser automation stack under the hood. PrideForge organizes it — Gherkin scenarios stay short and self-describing;
engineers maintain step definitions and page objects once. Deeper examples ship with the licensed solution and Academy.
Locator resolution
Named locators centralize element lookup on page objects instead of repeating selectors across tests
and scenarios.
Locator resolve
Named PageName.Member locators with an ordered fallback chain so tests survive label and markup churn.
Element type handling
Field handlers route set, get, and click to the right interaction for each control type — without per-field test code.
Page object handling
Add page classes to your solution; the framework discovers and registers them — no manual wiring list to maintain.
Table handling
Search, select, paginate, and validate grids with shared steps — not a one-off helper per table in your app.
Custom widgets
Handlers for Mud, MUI, Quill, comboboxes, and menu buttons — register new types when your UI needs them.
Multiple applications
Lets your team run the same framework against multiple products, servers, and URLs — configuration
drives where tests execute and how login and navigation behave per target, without forking your step library.
Environments
Multi-server configuration, app vs server scoping, and guards so tests do not run unauthenticated by accident.
Auth handling
Smart vs forced login, saved sessions, and parallel-safe storage — spend less time re-authenticating every scenario.
Simplified login
One login step in Gherkin; application-specific UI stays behind a login registry you configure per product.
Simplified navigation
Sitemap-driven routes: jump by URL or walk menus using shared navigation steps tied to your environment config.
Data handling
Runtime tokens resolve test data from files, tables, and stores — keeping values out of step code
instead of hardcoded in every scenario.
Dynamic value resolving
Dates, variables, data-file paths, and values captured from the UI — resolved when steps run, not hardcoded in every test.
Data files & tables
JSON/CSV test data, persistent stores, Gherkin tables, and scenario outlines for data-heavy flows.
Reporting
Reports show pass/fail with scenario steps, screenshots, and diagnostics — so failures triage without
raw logs alone. Gherkin carries the same language into reports: stakeholders see which business steps
passed or failed, not source lines.
test runner / CLI
12 passed
1 failed
login.spec.ts:45
Timeout 30000ms waiting for locator('#submit')
at login.spec.ts:45:12
Counts and stack traces · no scenario steps · screenshots not automatic
Passing feature · failing step in the scenario timeline · screenshot attached for triage
Accessibility
Accessibility testing is built in, supported, and configurable. Lets your team run axe-core scans from
Gherkin scenarios and produce reviewable pass-or-fail artifacts for release gates — not console dumps alone.
Console output only · no gate policy · no scenario context or screenshots
PrideForge accessibility report
Checkout — accessibility scanGate: FAILED
Critical0
Serious1
Moderate2
Known issues1 suppressed
Impact summary · release gate · known-issue list · HTML + JSON + screenshots
PrideForge Academy
The Academy is a hands-on course included with licensed seats — built entirely around
the solution you license. It teaches your team how to run, configure, and extend PrideForge, not generic
“how to build a framework” theory or slide-only training. Academy is how new team members learn the same
patterns your CI runs — so knowledge is not trapped with whoever built the framework first.
Each class maps to runnable Gherkin in the licensed repository. You read a lesson,
run the matching scenarios in your IDE, and experiment with the same patterns your team uses in CI.
Samples are there to test and understand capabilities — handlers, locators, tables,
reporting, accessibility, and configuration — before you wire in your production applications.
Academy dashboard — learning paths and progressLesson page — navigation plus the mapped sample featureLocal teaching fixture — practice without a live applicationRunning samples — pass, fail, and screenshot on failure
Learn by running samplesEvery major capability has examples you can execute.
Offline teaching fixtures run without a live app — start locally from your IDE, then move to your
environments when you are ready. Intentional-failure demos show how reports and accessibility
gates look when something breaks.
Local teaching fixtures
Deterministic sample pages for primitives, widgets, tables, validation, and more — paired with
runnable scenarios so you can modify and learn each pattern hands-on.
Lesson ↔ sample mapping
Academy classes point at specific features and page objects in the licensed solution. Read the
concept, run the sample, then apply the same steps to your application’s pages and configs.
Offline and reference runs
Samples pass deterministically without network access. Optional reference features show
live-app patterns; local fixtures keep onboarding fast and repeatable for every Academy seat.
Configuration & extension guides
Walkthroughs for servers, login, sitemaps, handlers, and adding your own applications —
so learners know when to extend the framework versus reuse existing steps.
Five learning paths
45 guided classes organized into paths that mirror how teams adopt PrideForge —
from first scenarios through configuration, task checklists, and CI/CD.
PrideForge was created because I kept seeing the same pattern repeat itself.
Every new automation project started with months of framework work before anyone could write
meaningful tests. Teams rebuilt authentication, reporting, environment management, page objects,
locator strategies, CI pipelines, and onboarding documentation — again and again. The work was
important, but it was rarely unique.
I've spent more than twenty years designing and building automation frameworks across different
organizations. Before moving into QA automation, I came from a software development background,
and the object-oriented design principles I learned through my engineering education have influenced
every framework I've built. Good architecture should reduce complexity, encourage code reuse, and
make systems easier to understand as they grow.
Those principles became the foundation of PrideForge.
I believe automation frameworks should disappear into the background. They should provide structure
without getting in the way, remain flexible without becoming complicated, and help teams spend their
time testing applications instead of maintaining infrastructure.
Every design decision in PrideForge is guided by a few simple principles:
Keep it maintainable. Clear architecture and consistent patterns are more valuable than clever solutions.
Design for reuse. Common problems should be solved once and reused everywhere.
Stay flexible. Every application is different, so the framework should adapt without requiring teams to rewrite its foundation.
Reduce friction. The faster a team can move from a requirement to proof that it works on a real system, the more valuable automation becomes.
PrideForge isn't intended to replace the tools your team already knows. It's built on proven
open-source technologies and established engineering practices, packaged into a production-shaped
solution that gives your team a strong starting point while leaving you in control of your own
automation.
The goal is simple: help teams spend less time building automation infrastructure and more time
improving software quality.
A site license has two seat types. Core Engineer seats provide access to the private
PrideForge Core repository, framework updates, and PrideForge Academy.
Academy seats are for team members who write and maintain tests — PrideForge Academy,
documentation, and the Automation Author learning path. Each seat is one named user — not a cap
on tests, agents, or pipelines.
You keep what you build. If your subscription ends, you lose access to the private
repository, Academy, and future updates, but your organization may continue using the version of
PrideForge and customizations created during your active subscription for internal automation.
