Skip to main content
Ashish KumarSDET II
Philosophy & system architecture

Quality Engineering Philosophy & Technical Stack

Building release systems where quality is something the architecture produces, not a phase at the end of the sprint.

Escaped defects
<5%
Triomics · LiveSwitch
Regression time
~40%
LiveSwitch
philosophy/credo.md
Core principles

  • // 01. Quality is architecture, not a checklist

    A test suite is a piece of software. Page objects, reusable API clients, and CI wiring are design decisions, not busywork — treating them that way is what keeps a suite alive past the first few sprints.

  • // 02. Release decisions run on signals

    A green pipeline isn't a release decision. Defect severity, critical-workflow coverage, defect trends, and unresolved risks are what actually tell you whether something is ready to ship.

Ashish Kumar

// background

How I Got Here

I'm an SDET who started out writing test cases and ended up building the systems that run them. Over 5+ years I've gone from payments QA at Mastercard to owning cross-platform automation at LiveSwitch, to now building an automation suite from scratch and leading the automation and QA team for a healthcare platform at Triomics — a domain where a flaky test isn't just an inconvenience, it's a risk you can't ship with.

What I actually do day to day is closer to software engineering than most people picture when they hear "QA": I design framework architecture (Page Object Model, reusable API clients, CI pipelines), make build-vs-buy calls on tooling, and decide where AI coding agents genuinely help — first-draft test scaffolding, debugging flaky failures — versus where they don't: test strategy and deciding what actually needs coverage still has to be a human call.

Accessibility is the other half of what I do. I audit against WCAG professionally, and I built this site to the same bar I hold production software to — semantic markup, full keyboard navigation, verified contrast, and a written accessibility statement instead of a footnote claim.

Outside of client work, I tinker with infrastructure — Redis, Sentry, and small cloud projects — mostly as an excuse to work at a layer I don't always get to touch in QA roles.

// foundational architecture

How I Think About Quality

Four pillars, each with a real excerpt from a public repo showing it in practice.

  • Shift-left & contract validation

    Quality starts at discovery

    The cheapest defect is the one caught in a requirement review. Quality work starts when a feature is still an idea and continues after release, when production tells you what the tests missed.

    In practice

    Joined requirement reviews with Product and Engineering at Mastercard to surface edge cases early; at every company since, production incidents get traced back into regression tests so they don't recur.

    utils/openapi-validator.ts
    contract gate
    /**
 * Validates a response body against the OpenAPI spec of the AUT (aut/openapi.json).
 * Returns a list of readable violations; empty means the response matches the contract.
 */
export function openApiViolations(method: string, pathTemplate: string, status: number, body: unknown): string[] {
  const op = spec.paths?.[pathTemplate]?.[method.toLowerCase()];
  if (!op) return [`${method.toUpperCase()} ${pathTemplate} is not in the OpenAPI spec`];
  // …
}
    Real excerpt · view source →(opens in a new tab)
    • OpenAPI
    • Ajv
    • Requirement reviews

  • Risk-based prioritization

    Test where the risk is

    Not every feature deserves the same depth. I prioritize by business risk, customer impact, and integration complexity, and pair automation with exploratory testing where scripted checks won't find the problem.

    In practice

    Defining test strategies for critical user journeys across UI, API, and database layers at Triomics, prioritized by business risk and customer impact.

    .github/workflows/ci.yml
    risk tiers
    # Pull requests and pushes run @smoke; the nightly schedule
# and a manual "full" run execute everything.
if [ "$FULL_RUN" = "true" ]; then GREP=""; else GREP="--grep @smoke"; fi
    Real excerpt · view source →(opens in a new tab)
    • @smoke tier
    • Nightly full run
    • Critical journeys

  • Accessibility by default

    Accessibility is a constraint, not an audit

    WCAG compliance works when it's designed in from the first component, not checked for after launch. I hold my own work — including this site — to the same bar I audit other software against.

    In practice

    This site runs an axe-core audit and a Lighthouse accessibility gate (≥95) in CI on every push, not just a one-time check before launch.

    lighthouserc.json
    CI gate
    "assertions": {
  "categories:accessibility": ["error", { "minScore": 0.95 }],
  "categories:best-practices": ["warn", { "minScore": 0.9 }],
  "categories:seo": ["warn", { "minScore": 0.9 }]
}
    Real excerpt · view source →(opens in a new tab)
    • axe-core
    • Lighthouse CI
    • WCAG 2.1 / 2.2 AA

  • AI-assisted QA

    AI is a tool with judgment attached

    AI-assisted coding is genuinely useful for first-draft scaffolding and debugging flaky failures fast. Deciding what actually needs test coverage stays a human, strategic call — that part doesn't get automated away.

    In practice

    Claude Code and Cursor draft first-pass tests and chase down flaky failures at LiveSwitch and on this site's own tooling; what actually ships is still a manual review call.

    ai/README.md
    human-reviewed
    AI agent -> Playwright MCP -> browser -> AUT -> human-reviewed Playwright tests

1. Planner: explores the AUT from the seed and writes specs/<feature>.md.
2. You review and edit the plan.
3. Generator: turns each scenario into a spec under tests/.
4. Healer: runs failing tests, debugs, and patches them. Review its diffs.
   A healer that edits an assertion to make a test pass may be hiding a product bug.
    Real excerpt · view source →(opens in a new tab)
    • Claude Code
    • Playwright MCP
    • Review gate

// skills & architecture

Categorized Technical Stack

Tools and disciplines I use in real work, grouped by where they sit.

Skills timeline & since-dates

  • Languages

    • Java
    • TypeScript
    • JavaScript
    • C++

  • Test Automation

    • Playwright
    • Selenium
    • Cypress
    • TestNG
    • Appium
    • REST Assured
    • Cucumber
    • Android Studio
    • Xcode
    • Node.js

  • Testing Disciplines

    • UI Testing
    • API Testing
    • Regression
    • Smoke Testing
    • Performance (JMeter)
    • Load Testing (k6)
    • Contract Testing (Pact)
    • UAT
    • Integration Testing
    • Cross-Browser Testing
    • E2E Testing
    • Chaos Testing
    • Accessibility (WCAG)
    • Internationalization (i18n)

  • Platforms

    • Web
    • Android
    • iOS
    • macOS
    • Windows

  • CI/CD & Cloud

    • GitHub Actions
    • Jenkins
    • Azure DevOps
    • Docker
    • AWS

  • Data & Observability

    • MySQL
    • PostgreSQL
    • MongoDB
    • Redis
    • Sentry

  • Version Control & PM

    • Git
    • Bitbucket
    • Jira
    • TestRail

  • AI-Assisted Development

    • Claude Code
    • Cursor
    • GitHub Copilot
    • MCP Server
    • ChatGPT

  • AI Testing & Evaluation

    • LLM Testing
    • RAG Evaluation
    • Evals
    • MCP

// culture & scaling

Leadership & Mentoring

Taking initiative, growing new joiners, and working across time zones.

  • Singapore
  • Dublin
  • Sydney
  • New York City
  • Arlington
  • North Carolina
  • Canada

  • Mentoring, from day one

    Mentored interns and new joiners at Mastercard from both a product and quality perspective, aiming to get them contributing within their first month; did the same with product knowledge transfer and structured onboarding at Triomics and LiveSwitch.

  • Proposed the move, then made it pay off

    Proposed and led the migration of all web automation from Selenium to Playwright, then layered in Claude Code, Cursor, and an MCP server on top of it to cut regression execution time by ~40%.

  • Leading the team, not just writing tests

    Leading the automation and QA team at Triomics, scaling test coverage in a way that's cutting into the product team's testing time and unblocking faster releases.

  • Made accessibility a gate, not an afterthought

    Proposed and drove a mandatory accessibility checklist before any new feature ships to production at Triomics, and moved the org from twice-yearly accessibility reporting to a monthly review across every product shipped.

Mentoring the wider QA community — career guidance for QA & SDETs

// timeline

The Journey So Far

  1. 2017

    Started at NIT Warangal

    B.Tech, graduated 2021 with an 8.69 CGPA.

  2. 2021

    Joined Mastercard Data & Services

    Built 1000+ automated tests and hit 95%+ coverage on a commercial payments platform.

  3. 2024

    Joined LiveSwitch

    Owned cross-platform UI/API automation, cut regression execution time by ~40%.

  4. 2026

    Joined Triomics Healthcare

    Building the automation suite from scratch for an oncology clinical-trial matching platform.

Education

National Institute of Technology, Warangal

Bachelor of Technology · 8.69 CGPA · 2017–2021

Certifications

  • Cypress End-to-End JavaScript Testing
  • HackerRank – Problem Solving

Achievements

  • CodeChef 4-star
  • Merit Scholarship (3x) – NIT Warangal & CBSE

Global Teams

  • Mastercard Data & ServicesSingapore · Dublin · Sydney · New York City · Arlington
  • LiveSwitchNew York City · North Carolina · Canada

// collaboration

Building a quality practice, not just a test suite?

Open to Senior and Lead SDET roles. Happy to talk about your current test debt, release cadence, and where AI fits.
Get in touchLinkedIn(opens in a new tab)