Job Description
QA Engineer
\n
Start Date: As soon as possible, but open to discussion
\n
Type: Full-time
\n
Reports to Head of Engineering
\n
Compensation: $95,000-$105,000
\n
\n
About Us
\n
de Anda Capital is an independent sponsor and family office with over 140 deals and over 3 billion USD in investor value creation. We are based in Los Angeles, California and New York City, New York. Our main office is located in New York City.
\n
\n
We acquire, operate and consolidate businesses in property management and real estate services. We work across several verticals, including property management, payroll and payments, decarbonization, manufacturing, and lending and financing.
\n
\n
About the Role
\n
de Anda Capital is hiring a QA Engineer for one of our portfolio companies in the fintech space. The company is a multi-tenant time-and-attendance platform sold alongside payroll providers.
\n
\n
Payroll partners trust what we deliver. A wrong meal-break deduction or a punch leaking across tenants is a customer-facing payroll error. Our automated coverage is strongest in the calculation engine; you will extend it to the edges. You will own the quality of the hours path from punch to delivered export — in code, inside the monorepo, as part of the same spec-driven workflow the engineers use.
\n
\n
Technology stack
\n
- \n
- Frontend: TypeScript, React 18, Vite, Apollo Client with GraphQL Codegen, Tailwind and shadcn/ui, react-intl, Storybook, Jest and Testing Library, in an NX monorepo with enforced module boundaries.
- Backend: Python 3.11, Django 5, Graphene (GraphQL), PostgreSQL, Redis, Celery with Beat, Django Channels for real-time subscriptions. Domain apps cover punch pipeline, calculation, timecards, scheduling, time off, configuration, reports, multitenancy, users and auth, notifications, and integrations. Tested with pytest, factory-boy, and friends.
- Cloud: AWS provisioned with Terraform — ECS Fargate (API, Celery worker, Beat), RDS PostgreSQL, ElastiCache, ALB with blue/green deploys, S3 and CloudFront for the SPA, Secrets Manager, CloudWatch. Serverless Framework Lambdas for scheduled tasks and WebSockets. GitHub Actions for CI and deploys; Docker Compose locally; Sentry for errors.
- Dev environment is live; production infrastructure is in progress. Both hires will help take it the rest of the way.
\n
\n
\n
\n
\n
\n
How we build
\n
We practice Specification Driven Development with AI coding agents doing much of the first-draft implementation. The spec is the unit of work; code is its output, and humans own correctness.
\n
\n
- \n
- PRD. Product and engineering write and refine a Product Requirements Document with explicit acceptance criteria.
- Technical Documents. The PRD is decomposed into smaller Technical Documents: schema and service design, data model changes, UI contracts, test expectations, and the repo patterns to follow.
- Agent-driven implementation. Each Technical Document drives a coding agent (Cursor with Claude models) working against the repo's AGENTS.md conventions to produce a PR.
- Human review. An engineer reviews every agent-authored PR against the Technical Document and acceptance criteria before merge. Tenant isolation, concurrency, timezone handling, and test quality are checked by a person, not assumed.
- Verification. The SDET lands acceptance-criteria-mapped tests in the same milestone; nothing is done until the tests say so.
\n
\n
\n
\n
\n
\n
\n
Engineers here spend more time specifying, reviewing, and hardening than typing boilerplate. Strong candidates are good at writing precise specs, directing agents, and spotting what an agent got plausibly wrong.
\n
\n
What you will test in
\n
- \n
- Three apps on one React/TypeScript codebase: tenant time app, support portal (separate auth, 2FA, OTP), kiosk (PIN). Roles from employee through owner plus internal support tiers; everything tenant-scoped.
- GraphQL API (Django + Graphene) over PostgreSQL and Redis; Celery for async calculation, notifications, and reports; Channels for real-time updates.
- Existing tooling: pytest with factory-boy, pytest-freezer, and xdist; Jest and Testing Library with Apollo MockedProvider; Storybook; deterministic demo-data seeding; Sentry and CloudWatch; GitHub Actions dev deploy with smoke tests.
\n
\n
\n
\n
\n
What you will do
\n
- \n
- Convert PRD acceptance criteria into executable test cases before the feature merges; pair with the engineer on the same Technical Document.
- Write pytest against services and the GraphQL schema: frozen time at period boundaries, tenant-mismatch cases, concurrency (two workers, one queue item), Celery tasks run synchronously.
- Write Jest / Testing Library for role-gated UI: who sees which card, which button is locked, what happens on GraphQL error.
- Build and own the Playwright project in-repo: login per role, punch in/out, missing-OUT exception, approvals, schedule publish, time-off, period-close readiness, support-portal 2FA, kiosk PIN. Wire it into the deploy workflow.
- Design data-driven calculation tests: OT thresholds, meal violations, split shifts, DST days, retro edits after calculation, late punches after close.
- Verify exports: CSV and PDF totals equal timecard totals; scheduled delivery arrives with the right attachment and audit row.
- Run tenant-isolation and RBAC matrices every release; anything that crosses a tenant is P0.
- Review agent-generated tests for false confidence: tests that pass without asserting the acceptance criterion do not count.
- Keep CI healthy: flaky xdist tests, coverage thresholds, slow Jest suites.
- Report defects precisely: tenant, role, pay period, timezone, exact GraphQL operation and variables, expected vs actual hours.
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Projects you will own
\n
- \n
- Hours-engine regression pack — scenario index covering pairing, exceptions, OT, meals, geofence flags, waivers, stale calculation after new input.
- Playwright E2E suite committed in the monorepo, wired into deploy, with per-role fixtures.
- RBAC and tenant-isolation matrix as automated tests, including support-portal boundaries.
- Period-close and delivery verification — blocking vs warning exceptions, delivered totals vs timecards.
- Locked-vs-live admin audit — guard that admin screens not yet backed by GraphQL stay locked until it lands.
- CI health — stabilize xdist and add coverage thresholds that fail builds.
- Performance baselines — schedule grid, dashboard aggregation, large-tenant timecard lists.
\n
\n
\n
\n
\n
\n
\n
\n
\n
Must have
\n
- \n
- 3–5 years in software quality with code-level automation as the primary output, on both the Python and TypeScript sides.
- Python test authoring (pytest, fixtures, factories, mocking) and TypeScript/React component testing (Jest, Testing Library).
- Has built a browser E2E suite from scratch (Playwright preferred; Cypress acceptable) and kept it non-flaky in CI.
- Reads GraphQL operations and responses; can isolate a frontend bug from an API bug from a data bug.
- SQL against PostgreSQL to verify what the UI claims.
- Test design for stateful systems: roles, periods, timezones, retries, eventual consistency.
- Git, PR review, Docker Compose, GitHub Actions.
- Precise written bug reports and test plans.
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Nice to have
\n
- \n
- Time and attendance, payroll, or scheduling domain.
- Testing Celery or other queue-based systems; concurrency and idempotency cases.
- Multi-tenant SaaS isolation testing; auth flows (JWT, TOTP, OTP, rate limits).
- Contract/schema testing for GraphQL; Apollo cache behavior.
- Accessibility (axe), visual regression via Storybook.
- Load testing (k6 / Locust); reading CloudWatch and Sentry.
- Experience using coding agents to generate tests, and judging when their output is wrong.
\n
\n
\n
\n
\n
\n
\n
\n
\n
Not a fit
\n
- \n
- Manual-only QA or test-case management without automation.
- Someone who needs a separate QA environment and team to run tests; you work in the engineering repo and pipeline.
- Automation that only asserts the happy path.
\n
\n
\n