Proof of work

Seven builds. Different worlds, same standard.

Enterprise and federal engagements are shown with real metrics and anonymized clients, per engagement agreements. EnChaptered is our own product: built, shipped and public.

Web UI, API & data validation · Live migration · Federal healthcare data program, anonymized

Rebuilding a federal regression suite around evidence, not reruns

  • Started from 32 feature-specific step classes, 32 page objects, 1,008 legacy steps and 136 fixed waits. A 376-case regression took 4 hours 8 minutes.
  • A canonical Gherkin vocabulary and shared step layer: new scenarios reuse behavior instead of adding feature-specific Java.
  • One accessibility-first locator resolver that tries test IDs, roles, labels, placeholders and stable text before generated IDs or brittle XPath.
  • State-based synchronization replaces fixed sleeps across loading, search, wizard and download workflows.
  • A risk-aware write lane isolates workflows that create, attest, upload or delete data, keeping them out of smoke and scheduled runs.
  • CI and reporting redesigned for in-repo workflows and durable Allure history, within the network-bound runner constraints.
55%Faster 30-scenario regression (20 → 9 min)
136 → 2Fixed waits, down to two polling intervals
<50 minFull regression (from 4 hr 10 min)
44%Faster with parallelism of two (8:22 → 4:39)
The result that matters · How we measured it

Testers and business analysts now add scenarios from approved Gherkin steps. They no longer wait for a developer to write duplicate step definitions, page objects and locators. Failures trace back to a small shared core, and every run leaves Allure evidence. The shared layer is about 5,082 lines. It replaces 23,404 lines of legacy framework code that is scheduled for retirement.

Whole-suite timing is reported with its caveats because coverage and environment conditions change from run to run. The legacy baseline was 4 hours 8 minutes for 376 cases. Modern runs of a similar size took between 44 minutes 53 seconds and 1 hour 43 minutes, and the longer run included 70 minutes of known, environment-specific email timeouts. With those checks limited to the environment that actually sends email, a comparable run should take about 35 minutes. That is a measured improvement in a migration still under way, not a like-for-like comparison against every historical run.

Java 17 · Playwright · Cucumber · JUnit · Maven · Allure · REST Assured · Jenkins · Docker · AWS S3 · Current through Oct 2026

Web UI & REST API · 4 months · Federal agency

Rebuilding a regression suite the team had learned to route around

  • Rebuilt the framework on DRY principles, cutting the class count by 70%.
  • Centralized configuration management across environments.
  • Automated smoke and regression gates on build and UAT pipelines.
  • GitLab Runners and Docker for parallel execution.
  • Automated reporting integrated directly into CI/CD.
96.5%Pass rate (from 45–50%)
65 minFull run (from 10+ hrs)
650+Test cases (from 350)
2×/moReleases (from monthly)
"This overhaul turned our flaky regression suite into a robust quality gate integrated into modern DevOps pipelines."Automation Architect, federal agency engagement

ETL validation · Big data QA · 3 months · Federal healthcare data program

Turning a five-day manual regression cycle into an automated afternoon

  • Built a custom PySpark and AWS EMR validation framework from scratch.
  • Parameterized SQL and YAML-config-driven test scenarios.
  • Automated EMR cluster creation and auto-shutdown.
  • Automated DataFrame comparisons with exact row and column mismatch detection.
  • Centralized reporting with a full audit trail.
5 days → 6 hrsRegression cycle: 2 testers (about 10 tester-days) to one automated run
350+Test cases (from 128)
40+Scenarios (from 26)
16M+Rows automated
"We built the first bridge between traditional QA and big data validation, enabling scalable, automated quality assurance for massive datasets."Lead QA Consultant, federal healthcare data program

ETL & big data validation · PySpark on Databricks · <6 months · Enterprise data platform, anonymized

Building a medallion-architecture validation framework from zero requirements

  • Built a YAML-driven PySpark framework on Databricks from a standing start, with no existing framework or requirements to build on.
  • One YAML mapping per table generates the full test suite: 40+ validation types (null, duplicate, primary and foreign key checks) tailored by table type, environment and data layer.
  • Validates 150+ tables across Bronze, Silver and Gold layers, now gating CI/CD.
  • Reporting evolved from flat text logs to structured summary and detail tables, with a live Databricks dashboard in progress.
  • Caught critical source-to-target mismatches during a Postgres-to-Databricks migration, working directly with the dev team to root-cause and fix them before the legacy database was retired, on schedule.
150+Tables validated across Bronze, Silver & Gold
40+Validation types enforced per table
90%+Table coverage, from a standing start
<6 moZero to a CI/CD-gated framework
Next · Productization assessment

The framework works, but it only runs inside a Databricks notebook. We audited it module by module and found the coupling concentrated in one small file: a hardcoded naming convention roughly every six lines. The fix is to compile each check down to plain SQL instead of Spark DataFrame calls. The same suite then runs from a laptop, from CI or on a cluster, and finally gets a unit-test suite that doesn't need one.

The assessment also surfaced something nobody had raised. The framework captures real failing values into its results tables. The moment an AI agent can read those tables, source data becomes text a model treats as instructions: an indirect prompt-injection path running straight through a data-quality report. A per-column redaction policy is now a prerequisite, not a follow-up.

Scoped from there: a portable check library, a ten-tool MCP server so a failed run can be triaged conversationally instead of by hand, and the existing root-cause runbooks packaged as agent skills.

Salesforce Lightning + Experience Cloud · 4 months (ongoing) · Enterprise program

QAVision: an AI-powered generator that stops broken automation before it ships

  • Model-first architecture: a single JSON source of truth. Edit once and it propagates everywhere.
  • The Rex validator enforces 16 semantic rules and blocks generation in CI on failure.
  • Detects hardcoded record IDs before they break in staging.
  • Locator healing re-ranks fallbacks after a platform release, with no code touched.
  • Six documented interaction patterns, reusable across every app.
<5 minFramework generation
16Validation rules enforced in CI
0Manual edits for locator healing
6Patterns documented & reusable
"What used to take two weeks to patch after a platform release now takes an afternoon. The CI gate catches what our code reviews were missing."Lead SDET, enterprise Salesforce engagement

Salesforce Lightning · AI-assisted migration · 14 months · 5 engagements, anonymized

Migrating and building Salesforce Lightning automation where most QA teams won't

  • Delivered 5 Salesforce Lightning automation engagements in 14 months: 4 frameworks built from scratch and 1 fully migrated off a legacy suite.
  • Built AI agents on GitHub Copilot to analyze existing test cases and user flows, then convert them into Playwright, Java and Cucumber with Allure reporting.
  • The migrated suite grew about 50% (70 → 100 test cases) while preserving full existing coverage through the cutover, landing at a 97% pass rate.
  • Automated in Salesforce Lightning specifically: dynamic elements and complex flows that lead most QA teams to skip automation entirely.
  • Trained non-technical QA staff across 3 teams to run and extend the frameworks themselves; they're still expanding them independently today.
5Frameworks delivered in 14 months
~50%Coverage growth (70 → 100 cases), zero coverage lost
97%Pass rate on the migrated suite
3Teams trained, still expanding on their own

Consumer AI product · Next.js + Gemini API · Public project

EnChaptered: an AI storybook generator, built and shipped solo

  • Full-stack Next.js app: landing page, live demo and waitlist capture.
  • The Gemini API generates a personalized, age-appropriate story from a child's name and interests.
  • Resend email pipeline for parent and internal notifications.
  • Mobile-first build: most traffic is parents on their phones.
  • Deployed on Vercel and iterated against real signups. github.com/ferkat0316/EnChaptered
<10sTime to a generated story
SoloDesign → API → deploy, one builder
2–8Target age range
LiveShipped on Vercel, real users

Have something that needs this level of scrutiny?

Start with the free assessment or a short email.
Take the assessment ↗Contact us