Hey There 👋

⭐ 🎭 Dokan E2E & API Automation Suite — Highlights ⭐

Highlights of my work:

🧱 Black-box, folder-isolated architecture — each feature owns its spec, page object, and test data, with no cross-folder imports.
🌱 Deterministic seeding — vendors, customers, products, and modules are provisioned by setup projects before the test phase runs.
🏷️ Tag-driven Lite/Pro gating (@lite, @liteOnly, @pro) so the suite runs cleanly on fork PRs without the Pro repository.
⚡ CI sharding & reporting — 6-way parallelization plus storage-state authentication to eliminate per-test login cost.
🐛 Flake hunting at the source — auto-dismiss handlers for the Pro 5.0 announcement modal and robust REST-auth patterns.

🔗 Dokan Automation Suite Github Actions CI/CD →

I am SHOHAN, a Software Quality Assurance Engineer and automation tester from Bangladesh. I work at weDevs on the Dokan multi-vendor marketplace ecosystem, the StorePulse product suite, and WP ERP — tools powering thousands of WooCommerce and WordPress sites. I focus on end-to-end automation, CI test infrastructure, and performance testing. Day-to-day I write Playwright suites, harden GitHub Actions pipelines, and track down test flakiness at the source.

Want to know more about me? Connect with me on LinkedIn.

🏢 Currently working as an SQA Engineer & Automation Tester at weDevs
🧪 Focusing on Playwright (TypeScript), REST API testing, and CI sharding & reporting
🤖 Exploring AI-assisted QA workflows and performance testing
📍 Based in Bangladesh
🧩 Products I work on:
🛒 Dokan — Multivendor plugin, Umbrella plugins & Mobile App
💼 WP ERP
📈 StorePulse — StoreGrowth, CartPulse, Conversion Tracking for WC & Texty

Find me on Social Platforms

What I Work On

Area	Recent work
E2E Automation	Refactoring Dokan's Playwright suite for stability and reliable CI reporting
CI Hardening	Improving GitHub Actions pipelines — caching, sharding, and quality reports
Performance	Load and performance testing for marketplace flows
Internal Tooling	Tooling to streamline QA workflows and debugging

Active contributor in getdokan and wp-erp — opening and merging pull requests and filing detailed, reproducible issues, mostly around E2E stability, CI infrastructure, and regression coverage. Recently had my end-to-end test suite merged into wp-erp.

🎭 Dokan E2E & API Automation Suite

A flagship project I work on: the official QA gate for Dokan Lite & Pro, built on Playwright + TypeScript. It drives a real WordPress + WooCommerce + Dokan stack inside Docker (@wordpress/env) — no local PHP, MySQL, or WordPress install required.

Metric	Detail
~2,000+	end-to-end tests
~400	REST API tests (`/dokan/v1`, `/v2`, `/v3`)
Surfaces	Vendor dashboard (React 5.0+), Admin React shell, Pro modules, Lite storefront
CI	6 parallel shards with merged HTML reporting via GitHub Actions

🎟️ EventHub — Playwright E2E + API Automation Suite

Note

🌟 A personal, self-initiated side project — built outside of work to showcase my automation skills (not a professional/company project like Dokan).

A production-style automation suite for the EventHub application, covering both the browser (E2E) and the REST API layers with Playwright + TypeScript. GitHub Actions CI/CD integrated — UI and API suites run in parallel and publish the HTML report as an artifact.

🧩 Two layers, one suite — UI journeys and API contract/validation tests share types, data, and config.
🏗️ Page Object Model — every page is a class; specs read like English, with zero raw selectors.
🔌 Typed API client — a fully-typed wrapper over Playwright's APIRequestContext with Bearer-token handling.
🔐 Authenticate once — a setup project logs in and saves storageState; all UI specs reuse it.
🎭 Playwright best practices — web-first auto-retrying assertions, role/data-testid locators, no hard waits, traces on failure.
🌱 Realistic, parallel-safe data — @faker-js/faker generators produce unique data per test.
🐞 Bugs documented — defects found during exploration are filed as GitHub-issue-style reports in /bugs.

🔗 EventHub Automation Suite Github Actions CI/CD →

🛒 Client Dashboard ("Let's Shop") — Playwright E2E + API Automation Suite

Note

🌟 A personal, self-initiated side project — built outside of work to showcase my automation skills (not a professional/company project like Dokan).

A production-style automation suite for the Client Dashboard ("Let's Shop") practice app, covering both the browser (E2E) and the REST API layers with Playwright + TypeScript. GitHub Actions CI/CD integrated — UI and API suites run in parallel and publish the HTML report plus a job-summary table.

🧩 Two layers, one suite — UI journeys and API contract/validation tests share types, data, and config.
🏗️ Page Object Model — every page is a class; specs read like English, with zero raw selectors.
🔌 Typed API client — a typed wrapper over Playwright's APIRequestContext, encoding the API's quirks (raw authorization token, userId-in-path endpoints).
🔐 Authenticate once — a setup project logs in and saves storageState; UI specs reuse it, guest specs opt out explicitly.
🎭 Playwright best practices — web-first auto-retrying assertions, role/label locators, no hard waits, traces/screenshots/video on failure.
🌱 Realistic, parallel-safe data — @faker-js/faker generators produce unique data per test.
🧪 Happy + negative + edge coverage — 65 tests (1 setup · 31 UI · 33 API), each traceable to a written TEST-CASES.md spec.
🐞 Bugs documented — defects found during exploration are filed as GitHub-issue-style reports in /bugs.

🔗 Client Dashboard Automation Suite Github Actions CI/CD →

🏆 Achievements

✅ Merged pull requests into the getdokan/dokan, wp-erp codebase, including CI reliability fixes
🧪 Built and maintained automated end-to-end test coverage for a production WooCommerce plugin
🐛 Filed detailed, reproducible bug reports and test-case checklists used by the team
🔧 Improved CI pipeline stability and reporting for a multi-vendor e-commerce platform