DEV Community: Sai Krishna Oggu

How to Configure Playwright for Multi-Tenant Applications Using Projects?

Sai Krishna Oggu — Wed, 07 Oct 2026 07:44:09 +0000

🚀 Scaling Playwright for Multi-Tenant Applications:

Testing a multi-tenant application can quickly become challenging when the same application behaves differently based on the tenant, configuration, permissions, or test data.

In my latest article, I cover how to configure Playwright for multi-tenant applications using projects in playwright.config.ts, including:

🔹 Tenant-specific configurations
🔹 Reusing the same test scenarios across tenants
🔹 Environment and authentication management
🔹 Organizing scalable Playwright test suites
🔹 Running tests selectively for specific tenants
🔹 Practical configuration examples

The goal is simple: write tests once, configure tenants independently, and scale automation without creating unnecessary duplication.

If you're working with Playwright, SaaS, multi-tenant platforms, or large-scale test automation, I'd love to hear how you're handling tenant-specific testing.

Visit my website: https://saikrishnaoggu.ai.studio/

Read full article here : https://medium.com/@saikrishnaoggu/how-to-configure-playwright-for-multi-tenant-applications-using-projects-c56b8da29fe3?postPublishedType=initial

How To Design a Test Automation Strategy for a New Product Using Playwright ?

Sai Krishna Oggu — Mon, 28 Sep 2026 10:15:39 +0000

When a new product enters development, one of the first questions teams ask is:

“How quickly can we automate the application?”

I think the better question is:

“What should we automate, how should we automate it, and how will the automation help the team release faster?”

For a new product, automation shouldn’t begin with writing hundreds of test scripts.

It should begin with understanding the product, architecture, business-critical workflows, APIs, risks, accessibility requirements, and release process.

My approach is to build an automation strategy that covers the complete product lifecycle:

Requirements → Test Strategy → UI + API + Accessibility → Automation Framework → CI/CD → Reporting → Continuous Improvement

For web applications, Playwright + TypeScript provides a strong foundation for this approach.

Start With the Product, Not the Automation Tool Before writing the first Playwright test, I want to understand the product.

I usually start by identifying:

Core business workflows

User roles and permissions

Critical revenue-generating functionality

Authentication and authorization

Integrations with external systems

APIs and backend services

Database dependencies

Third-party services

Supported browsers

Responsive requirements

Accessibility requirements

Deployment environments

CI/CD pipeline

Release frequency

I then divide the product into business-critical workflows.

For example, imagine we’re testing a SaaS application.

A typical critical workflow could be:

Login
↓
Dashboard
↓
Create Customer
↓
Create Opportunity
↓
Update Opportunity
↓
Generate Quote
↓
Submit Quote
↓
Verify API response
↓
Verify UI state
This workflow becomes one of the first candidates for automation.

The goal isn’t maximum automation.

The goal is maximum risk coverage with maintainable automation.

Define the Automation Pyramid For a new product, I don’t put everything into UI automation.

I prefer separating automation into different layers.

┌─────────────────────┐
│ UI / E2E │
│ Critical Flows │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ API Automation │
│ Business Services │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Accessibility Tests │
│ WCAG / a11y checks │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Unit / Component │
│ Tests │
└─────────────────────┘
The exact distribution depends on the product, for example:

UI automation
Use for:

Critical business journeys

Authentication

Checkout

Payments

User registration

Major workflows

Cross-browser validation

API automation
Use for:

Business rules

CRUD operations

Authentication

Authorization

Data validation

Negative scenarios

Integration workflows

Accessibility automation
Use for:

Keyboard navigation

Semantic structure

Form accessibility

Labels

ARIA attributes

Color/contrast checks where automated tooling can detect them

Automated WCAG checks

Accessibility automation doesn’t replace manual accessibility assessment, but it can continuously catch many common issues.

Create the Playwright Framework For a new product, I prefer building a framework that can grow with the application. A typical structure could look like this:

playwright-automation/
│
├── tests/
│ ├── ui/
│ │ ├── login.spec.ts
│ │ ├── customer.spec.ts
│ │ └── opportunity.spec.ts
│ │
│ ├── api/
│ │ ├── customer-api.spec.ts
│ │ └── opportunity-api.spec.ts
│ │
│ └── accessibility/
│ ├── login-a11y.spec.ts
│ └── dashboard-a11y.spec.ts
│
├── pages/
│ ├── LoginPage.ts
│ ├── DashboardPage.ts
│ ├── CustomerPage.ts
│ └── OpportunityPage.ts
│
├── api/
│ ├── CustomerApi.ts
│ └── OpportunityApi.ts
│
├── fixtures/
│ └── test-fixtures.ts
│
├── utils/
│ ├── test-data.ts
│ ├── api-utils.ts
│ └── accessibility-utils.ts
│
├── config/
│
├── playwright.config.ts
│
└── package.json
The exact structure can change depending on the product, but the principle remains:

Keep test intent separate from implementation details.

Use Page Object Model for UI Automation I use Page Object Model (POM) to separate page behavior from test scenarios, for example:

import { Page, Locator } from ‘@playwright/test’;
export class LoginPage {
readonly page: Page;
readonly username: Locator;
readonly password: Locator;
readonly loginButton: Locator; constructor(page: Page) {
this.page = page;
this.username = page.getByLabel(’Username’);
this.password = page.getByLabel(’Password’);
this.loginButton = page.getByRole(’button’, {
name: ‘Login’
});
} async login(username: string, password: string) {
await this.username.fill(username);
await this.password.fill(password);
await this.loginButton.click();
}
}
Then the test remains focused on the business scenario:

test(’user can login successfully’, async ({ page }) => {
const loginPage = new LoginPage(page);
await loginPage.login(
process.env.USERNAME!,
process.env.PASSWORD!
); await expect(page).toHaveURL(/dashboard/);
});
The test describes what the user does.

The page object describes how the application is interacted with.

That separation becomes extremely valuable as the application grows.

Don’t Create One Giant Page Object A common mistake is creating a huge page object containing every action in the application. Instead, I prefer smaller, domain-oriented objects.

For example:

CustomerPage
CustomerForm
CustomerTable
CustomerDetails
OpportunityPage
OpportunityForm
OpportunityTable
OpportunityDetails
This improves:

Maintainability

Reusability

Debugging

Code ownership

Parallel development

The framework should evolve with the product rather than becoming another source of technical debt.

Add API Automation From Day One UI automation alone is not enough. If the application exposes APIs, I want API automation early in the project. Playwright’s APIRequestContext makes this possible without introducing a completely separate automation stack.

For example:

import { APIRequestContext } from ‘@playwright/test’;
export class CustomerApi {
constructor(private request: APIRequestContext) {} async createCustomer(data: object) {
return await this.request.post(’/api/customers’, {
data
});
} async getCustomer(id: string) {
return await this.request.get(/api/customers/${id});
}
}
Now we can validate backend behavior directly, for example:

const response = await customerApi.createCustomer({
name: ‘Automation Customer’,
email: ‘automation@example.com’
});
expect(response.ok()).toBeTruthy();const body = await response.json();expect(body.name).toBe(’Automation Customer’);
This gives us much faster feedback than reaching the same functionality exclusively through the UI.

Combine API and UI Automation One of my preferred approaches is using APIs to prepare data and the UI to validate the user experience, for example:

API
↓
Create test customer
↓
API
↓
Create opportunity
↓
UI
↓
Login
↓
Open opportunity
↓
Verify data
↓
UI action
↓
Update opportunity
↓
API
↓
Verify backend state
This can dramatically reduce unnecessary UI setup. Instead of spending several minutes creating test data through the UI, the test can create the required state through an API and use the UI only where UI behavior needs to be validated.

This makes end-to-end tests:

Faster

More deterministic

Easier to maintain

Less dependent on previous tests

Build Accessibility Into the Framework Accessibility shouldn’t be something we remember at the end of the project. I prefer treating accessibility as another quality dimension. A Playwright test can integrate with accessibility tooling such as axe-core.

Example:

import AxeBuilder from ‘@axe-core/playwright’;
test(’dashboard accessibility’, async ({ page }) => {
await page.goto(’/dashboard’); const results = await new AxeBuilder({
page
}).analyze(); expect(results.violations).toEqual([]);
});
Accessibility checks can now run as part of the automated test suite, we can also include targeted checks for:

Accessible names

Form labels

Keyboard navigation

Heading structure

ARIA attributes

Focus behavior

Interactive elements

For organizations with formal accessibility requirements, automated checks should be combined with manual testing and appropriate accessibility expertise.

Use Fixtures for Reusable Test Setup As the product grows, test setup becomes increasingly important. Instead of repeating authentication and common setup:

test.beforeEach(async ({ page }) => {
// login
});
I prefer creating reusable Playwright fixtures, for example:

export const test = base.extend<{
authenticatedPage: Page;
}>({
authenticatedPage: async ({ page }, use) => {
// authentication logic await use(page);
}
});
Then tests can focus on the scenario:

test(’create customer’, async ({
authenticatedPage
}) => {
// test scenario});
Fixtures can also provide:

API clients

Test data

Authenticated sessions

Database helpers

Environment configuration

Custom utilities

Design for Parallel Execution A new product can start with 20 tests, six months later it might have:

500+ tests.

If every test runs sequentially, execution time becomes a bottleneck.

That’s why I design the framework with parallel execution in mind.

Playwright provides:

Workers

Parallel test execution

Projects

Sharding

Retries

Trace viewer

HTML reporting

For example:

Worker 1 → Tests 1–50
Worker 2 → Tests 51–100
Worker 3 → Tests 101–150
Worker 4 → Tests 151–200
This allows the regression suite to scale with the product.

Build the CI/CD Pipeline Automation becomes significantly more valuable when it runs automatically. A typical pipeline could look like:

Developer Push
↓
Pull Request
↓
Build
↓
Lint
↓
Unit Tests
↓
API Tests
↓
Playwright UI Tests
↓
Accessibility Tests
↓
Reports
↓
Deploy
For example, GitHub Actions can execute Playwright:

name: Playwright Tests
on:
pull_request:
push:jobs:
test:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4 - uses: actions/setup-node@v4
with:
node-version: 20 - run: npm ci - run: npx playwright install --with-deps - run: npx playwright test - name: Upload report
if: always()
uses: actions/upload-artifact@v4
with:
name: playwright-report
path: playwright-report/
Now every code change gets automated quality feedback.

Separate Smoke, Regression and Critical Tests Not every test needs to run on every commit. I usually categorize tests.

Smoke
Critical functionality:

Customers
Opportunities
Reports
Notifications
Permissions
Integrations
Accessibility
Critical pages
Forms
Navigation
Interactive components
Full E2E
Complete business journeys:

Make Test Data a First-Class Concern Poor test data management can destroy an otherwise good automation framework. I prefer:

Unique test data

API-based data creation

Environment-specific configuration

Cleanup strategies

Independent test data

No dependency on another test’s execution

For example:

const customer = {
name: Automation-${Date.now()},
email: qa-${Date.now()}@example.com
};
The objective is simple:

Every test should be capable of running independently.

Add Observability to Test Failures A failed test should tell the developer why it failed. I enable Playwright artifacts such as:

Screenshots

Videos where appropriate

Traces

Console logs

Network information

HTML reports

For example:

use: {
trace: ‘retain-on-failure’,
screenshot: ‘only-on-failure’,
video: ‘retain-on-failure’
}
When a test fails in CI, the developer shouldn’t need to reproduce it locally just to understand the failure.

The automation framework should provide the evidence.

Measure Automation Like an Engineering System I don’t consider automation successful simply because:

“We have 500 automated tests.”

Instead, I track meaningful metrics.

Useful metrics
Automation coverage

Automated critical scenarios

Total critical scenarios
Pass rate

Passed tests

Executed tests
Flaky test rate

Flaky executions

Total executions
Regression execution time

Before automation → 6 hours
After optimization → 45 minutes
Other useful metrics include:

Defect escape rate

Mean time to detect

Mean time to diagnose

CI failure categories

API coverage

Accessibility violation trends

Automation maintenance effort

The purpose of these metrics isn’t to produce impressive dashboards.

It’s to identify where the quality process is slowing down delivery.

What My End-to-End Strategy Looks Like For a completely new product, my approach can be summarized as:

PRODUCT REQUIREMENTS
│
▼
RISK ANALYSIS
│
▼
AUTOMATION STRATEGY
│
┌────────────┼────────────┐
▼ ▼ ▼
UI API ACCESSIBILITY
│ │ │
▼ ▼ ▼
Playwright APIRequest axe-core
│ │ │
└────────────┼────────────┘
▼
POM + Fixtures
│
▼
Test Data Strategy
│
▼
Parallel Execution
│
▼
CI/CD
│
▼
Reports + Artifacts
│
▼
Quality Metrics
│
▼
Continuous Improvement
This is how I think about test automation:

Not as a collection of scripts, but as an engineering system.

The Goal Isn’t 100% Automation One of the biggest misconceptions in automation is:

“We need to automate everything.” I don’t agree with that approach.

Some tests are better suited for:

Manual exploratory testing

Usability testing

Visual assessment

Accessibility assessment

Investigative testing

New feature exploration

Automation is most valuable when it handles repetitive, predictable and high-value validation.

The goal is not:

100% automated testing.

The goal is:

Fast, reliable and actionable feedback.

My Playwright Automation Stack
For a modern web product, my preferred stack can look like:

Language
TypeScript
UI Automation
PlaywrightAPI Automation
Playwright APIRequestContextAccessibility
axe-core + PlaywrightArchitecture
Page Object ModelTest Data
Fixtures + APICI/CD
GitHub Actions / Azure DevOps / JenkinsReporting
Playwright HTML ReportVersion Control
Git / GitHubTest Management
Jira / Azure DevOps
The exact stack should always adapt to the product and engineering ecosystem, not to popularity.

Final Thoughts
When I join a new product, I don’t start by asking:

“Which test cases should I automate first?”

I start by asking:

“Which risks can automation help us detect earlier and more reliably?”

From there, I design the automation architecture around:

Business risk → UI → API → Accessibility → Test data → Framework → CI/CD → Reporting → Metrics

With Playwright, TypeScript, API automation, accessibility checks and CI/CD working together, automation becomes more than regression testing.

It becomes part of the software delivery system.

And that’s the approach I believe modern QA teams should move toward:

Build quality into the delivery pipeline — not inspect quality only at the end.

Looking to Build or Improve Your Playwright Automation?
I work with teams that need help with:

✓ Playwright automation frameworks from scratch
✓ UI + API end-to-end automation
✓ Page Object Model architecture
✓ CI/CD integration
✓ Accessibility automation
✓ Regression automation
✓ Flaky-test investigation and optimization
✓ QA automation strategy for new products
✓ AI-assisted QA and test automation

If you’re building a new product and are thinking about how to establish a scalable QA automation strategy from the beginning, feel free to connect with me or reach out.

I’m always interested in discussing practical QA automation challenges and helping teams build a reliable path from requirements → automation → CI/CD → release.

Sai Krishna Oggu
Senior QA Automation Engineer | SDET | Playwright | TypeScript | AI-Driven Testing

🌐 Website: saikrishnaoggu.ai.studio

💼LinkedIn: Connect with me on LinkedIn

Great products aren’t just built to work — they’re built to keep working.
Let’s make quality part of the journey, not the final checkpoint. 🚀

Playwright #TestAutomation #QAAutomation #SDET #TypeScript #APITesting #E2ETesting #AccessibilityTesting #CICD #QualityEngineering #SoftwareTesting #AITesting #TestAutomationEngineer

Why Do Playwright Tests Pass Locally but Fail in CI/CD?

Sai Krishna Oggu — Sat, 19 Sep 2026 08:09:42 +0000

“It works perfectly on my machine.”

Every automation engineer has said it.

Your Playwright test passes 20 times locally.
You push the code.
The CI pipeline starts.
And suddenly:

❌ Test failed.

You run it again locally.

✅ Passed.

So, what changed?

Usually, the test didn’t suddenly become bad. The environment changed.

Here are the most common reasons behind this frustrating problem — and how to debug them.

Timing Issues — The Classic Flaky Test Your local machine may give the application enough time to render.

CI may be under CPU or memory pressure, making everything slightly slower.

A fragile test might look like:

await page.click('#submit');
await page.waitForTimeout(1000);
expect(await page.locator('.success-message').isVisible()).toBeTruthy();
Instead, let Playwright wait for the expected state:

await page.getByRole('button', { name: 'Submit' }).click();
await expect(
page.getByText('Success')
).toBeVisible();
Rule:
Don’t wait for time. Wait for state.

Avoid using waitForTimeout() as a solution for flaky tests.

Your Local Environment ≠ CI Environment This is one of the first things I check. Your local environment might use:

QA1
while the pipeline is configured for:

QA2
Or your local .env may contain variables that aren't available in CI.

Check:

baseURL
API endpoints
environment variables
feature flags
tenant configuration
test credentials
database state
A test can be perfectly written and still fail because it is talking to the wrong environment.

Browser or Playwright Version Differences Your local machine may be running one browser version while CI runs another.

Check your Playwright version:

npx playwright --version
Make sure your project uses a consistent dependency version and that CI installs the expected browsers.

For CI environments, browser installation should be explicit when needed:

npx playwright install --with-deps
Consistency matters.

Same code + different browser/runtime = potentially different behavior.

Headless vs Headed Execution Most CI pipelines run Playwright in headless mode.

Locally, you may be running:

npx playwright test --headed
while CI runs:

npx playwright test
This can expose problems involving:

animations
responsive layouts
viewport assumptions
visual elements
timing
Try reproducing the pipeline locally in headless mode.

Parallel Execution Can Expose Hidden Dependencies This is a big one, you might run locally:

npx playwright test --workers=1
But your CI pipeline may execute multiple workers, now imagine two tests using the same user:

Test A → Update User
Test B → Delete User
Run independently:

PASS ✅

Run simultaneously:

FAIL ❌

Shared test data is often the real culprit, watch for dependencies involving:

users
database records
files
API data
tenants
orders
accounts
Tests should be as isolated as possible.

Test Data Exists Locally — but Not in CI Your local database may already contain:

User: testuser123
Order: 45678
Tenant: ABC
Your pipeline may not.

Download the Medium app
If your test assumes that data exists, it can fail immediately.

Instead of relying on existing state, create the required data as part of the test setup.

For example:

test.beforeEach(async ({ request }) => {
await createTestUser(request);
});
A reliable test should control the data it depends on.

Authentication & Storage State Another common issue:

Local
↓
Valid storageState
↓
Authenticated
↓
Test passes
CI:

Missing/expired storageState
↓
Login/session fails
↓
Test fails
Check:

cookies
access tokens
session state
authentication setup
CI secrets
storage state files
Don’t assume authentication works simply because it works locally.

CI Secrets Are Different You may have:

process.env.USERNAME
process.env.PASSWORD
process.env.BASE_URL
working locally because they’re defined in your .env.

But CI needs those values configured separately.

A missing environment variable can create a failure that looks like a Playwright problem — but isn’t.

Timezone Differences Here’s a subtle one.

Your machine:

IST
CI server:

UTC
Now consider a test involving:

Today's date
Expiry date
Scheduled job
Booking time
Timestamp
Your test may behave differently.

If dates matter, make timezone assumptions explicit rather than relying on the machine’s local timezone.

Windows Works. Linux Doesn’t. This catches many automation engineers; your local machine may be Windows.

Your CI runner may be Linux.

Windows filesystem handling can be different from Linux, particularly around filename casing.

For example:

import LoginPage from './pages/loginpage';
while the actual file is:

LoginPage.ts
It may work locally and fail in a Linux pipeline.

Treat filenames and imports as case-sensitive.

The Most Powerful Debugging Tool: Trace Viewer
When a test fails in CI, don’t immediately increase the timeout.

First, find out why it failed.

Configure Playwright:

use: {
trace: 'retain-on-failure',
screenshot: 'only-on-failure',
video: 'retain-on-failure'
}
Then inspect the trace:

npx playwright show-trace trace.zip
You can investigate:

the exact action that failed
DOM state
screenshots
network activity
console messages
timing
locator behavior
Instead of guessing:

“Maybe the page wasn’t loaded?”

You can actually see what happened.

My CI Debugging Checklist
When a Playwright test passes locally but fails in CI, I check these in roughly this order:

Environment / Base URL ↓
Test data ↓
Authentication ↓
Timing / synchronization ↓
Browser & Playwright versions ↓
Headless execution ↓
Parallel workers ↓
Viewport / responsive behavior ↓
Timezone ↓
CI resources / network Then I reproduce the pipeline conditions locally:

npx playwright test --workers=1
and inspect the trace if the failure persists.

The Bigger Lesson
A CI failure isn’t necessarily a Playwright problem.

It can reveal a weakness in your:

test → data → environment → application → infrastructure

chain.

That’s why good automation isn’t just about writing locators.

It’s about creating tests that are:

Reliable. Isolated. Reproducible. Observable.

The goal isn’t to make CI green by adding more waits.

The goal is to understand why it wasn’t green in the first place.

Final Thought
Local passing tells you the test can work.
CI passing tells you the test can be trusted.

And that’s the real difference between a test that runs and an automation suite you can rely on.

Integrating Playwright with CI/CD Using GitHub Actions

Sai Krishna Oggu — Fri, 18 Sep 2026 10:20:54 +0000

Automating Playwright tests locally is useful, but running them automatically in a CI/CD pipeline gives teams faster feedback on every code change.

In this guide, we'll integrate Playwright with GitHub Actions using a simple YAML workflow.

1. Project Setup

Assuming you already have a Playwright project:

playwright-project/
├── tests/
├── playwright.config.ts
├── package.json
└── package-lock.json

Make sure the tests run locally:

npx playwright test

2. Create the GitHub Actions Workflow

Create the following file:

.github/workflows/playwright.yml

Add:

name: Playwright Tests

on:
  push:
    branches: [main]

  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Install Playwright browsers
        run: npx playwright install --with-deps

      - name: Run Playwright tests
        run: npx playwright test

      - name: Upload Playwright report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/

3. How It Works

Whenever code is pushed to main or a pull request is created, GitHub Actions will:

Code Push / Pull Request
          ↓
   Checkout Repository
          ↓
     Install Node.js
          ↓
    Install Dependencies
          ↓
 Install Playwright Browsers
          ↓
    Run Playwright Tests
          ↓
    Generate Test Report

If a test fails, the workflow fails and the Playwright report is still uploaded because of:

if: always()

This makes it easier to investigate failures directly from GitHub Actions.

4. Why Integrate Playwright with CI/CD?

CI/CD integration helps teams:

Run tests automatically
Catch regressions early
Validate pull requests
Execute tests consistently
Store reports and artifacts
Reduce manual testing effort

For larger frameworks, you can extend the pipeline with parallel execution, environment variables, secrets, scheduled regression runs, test sharding, and deployment gates.

Final Thought

Playwright becomes much more valuable when automation is part of the development pipeline—not just something executed manually on a QA engineer's machine.

Write the tests once. Run them continuously. Get feedback early.

🚀 1,200+ Test Cases Migrated from Tosca to Playwright – A Major QA Transformation Success! 🚀

Sai Krishna Oggu — Mon, 08 Jun 2026 03:46:01 +0000

Excited to share the successful migration of 1,200+ automated test cases from Tosca to Playwright, helping our customer modernize their automation landscape and build a faster, more scalable, and cost-effective testing ecosystem.

Why Move from Tosca to Playwright?
✅ No Licensing Costs – Open-source framework that eliminates licensing fees and reduces automation costs.
✅ Faster Test Execution – Native parallel execution enables significantly quicker regression cycles.
✅ Better CI/CD Integration – Seamlessly integrates with modern DevOps and continuous testing pipelines.
✅ Superior Web Application Support – Auto-waiting and robust locators improve test stability and reliability.
✅ Rich Debugging & Reporting – Built-in traces, screenshots, videos, and logs simplify failure analysis.
✅ Cross-Browser Testing – Supports Chromium, Firefox, and WebKit from a single automation framework.
.
Value Delivered:

🎯 Successfully migrated 1,200+ automated test cases
🎯 Improved execution speed and test stability
🎯 Reduced long-term automation costs
🎯 Enhanced maintainability and scalability
🎯 Accelerated feedback cycles for development teams
🎯 Established a modern automation foundation for future growth

Large-scale automation transformations require the right strategy, technical expertise, and a strong focus on quality. Proud to have contributed to this journey and to the measurable value delivered to the customer.

🚀 1,200+ Test Cases Migrated from Tosca to Playwright – A Major QA Transformation Success! 🚀 Excited to share the successful migration of 1,200+ automated test cases from Tosca to Playwright, helping our customer modernize their automation landscape

Sai Krishna Oggu — Mon, 08 Jun 2026 03:44:41 +0000

Testing the product as an end user.

Sai Krishna Oggu — Sun, 05 Oct 2025 02:11:05 +0000

🧪 Testing isn’t about ticking boxes. It’s about thinking like a user.

Requirements are written with assumptions; they tell you what’s expected.
Users arrive with expectations, and they need experience they really don't care about user stories in Jira.

The gap between the two? That’s where startups succeed… or stumble.

I test like your first customer, your 100th customer, and your toughest investor. 🐞🚀

Great startups don’t just launch features; they launch experiences people believe in. We identify the gap between user expectations and user stories of your product.