I’m a QA engineer with 1.7 years of hands-on testing across payment platforms, casino games and factory software. So far that’s 7,000+ test cases and 1,000+ defects logged, retested and closed. I work remotely with a team in Austin, from India.
Each one had many roles, real money or real chemistry behind it, and plenty of ways to go wrong.
A manufacturing and quality control system for agrochemicals. I tested workflows across 7 enterprise roles: sample management, batch creation, laboratory testing, chemical inventory, production approval, COA workflows and packaging plant controls.
A payment and gaming transaction platform. I covered Player, Agent, Master Agent and Super Admin journeys, and validated integrations with WERT, Stripe, Coinbase, Fiserv, CLKK and PayNearMe.
A social casino back office with a multi-level role hierarchy. I tested user management, game CRUD, game coins, RTP, bonus features, recharge and redeem, support tickets and chat.
The player-facing side. I played through 100+ slot games, checking gameplay and functionality as a real player would.
Four small pieces that show my process. The examples are illustrative, with no client data.
| ID | Scenario | Expected result | Priority |
|---|---|---|---|
| RBAC-01 | Super Admin opens user management | Full list is visible with create, edit and disable options | High |
| RBAC-02 | Agent opens the Super Admin URL directly | Access is denied and the user is redirected | High |
| RBAC-03 | Agent views the user list | Only their own downline is shown | High |
| RBAC-04 | Agent creates a user under another agent | Action is blocked with a clear message | High |
| RBAC-05 | Player calls an admin API with a valid player token | Server returns 403, no data | High |
| RBAC-06 | Role is changed while the user is logged in | New permissions apply after refresh or next login | Medium |
| RBAC-07 | Disabled user tries to log in | Login fails with a clear message | Medium |
| RBAC-08 | Menu items for each role | Only permitted menu items are shown | Low |
A small example of the style I use: one clear behavior per test, readable names, and checks on what the user sees.
import { test, expect } from '@playwright/test';
test('agent cannot open the super admin area', async ({ page }) => {
// log in as an agent
await page.goto('/login');
await page.getByLabel('Email').fill(process.env.AGENT_EMAIL);
await page.getByLabel('Password').fill(process.env.AGENT_PASSWORD);
await page.getByRole('button', { name: 'Log in' }).click();
// try the restricted page directly
await page.goto('/admin/users');
await expect(page).not.toHaveURL(/admin\/users/);
await expect(page.getByText('Access denied')).toBeVisible();
});I planted four bugs in this tiny shop. Test it like a QA would and see how many you can trigger. Nothing is sent anywhere.
Manual first to understand the product. Automation next to make quality repeatable.
I approach every product with a quality-first mindset. I start by understanding requirements, challenging assumptions, identifying risks, and exploring real-world user scenarios. I validate functionality across roles, workflows, business logic, calculations, APIs, and databases. Once a feature is stable, I build Playwright automation to make regression testing faster and more reliable. I also use Postman and JMeter to validate API behavior, data integrity, and application performance beyond what the UI reveals.