About Kalpla

Kalpla is an online education platform. We build the software that learners, instructors and institutions use every day: courses, live classes, assessments, mentorship and certification.

We run two products side by side:

- Kalpla is our public learning platform, across web, mobile web and a native mobile app.
- Academics is our institutional product for diploma programmes and college partners, across web and mobile web.

Why this role exists We ship new features every day across both products, and our test surface is growing faster than manual testing can keep up with. The honest problem is that regressions slip in daily, and we often find them late, sometimes after they reach production.

We want someone to own that problem. Our goal is that when a developer breaks something that used to work, we find out within minutes of the deploy, not days later from a user. You will be the person who builds that safety net and keeps it trustworthy.

Where we are today

Honestly, at the beginning. There is no automated regression suite and no quality gate in CI yet. Testing today is manual, and it cannot keep pace with how fast we ship.

That is exactly why this role exists. You will set up our test automation from the ground up.

You will choose the framework, decide what to cover first, and make automated testing part of how every release goes out.

What you will own

- The automation foundation. Choose and set up our test framework and project structure: conventions, environments, test data strategy and reporting, designed so the rest of the team can contribute later.
- The regression suite. Build coverage from nothing, starting with a small smoke suite for the flows that cannot break (login, purchase and enrolment, course playback), then expanding across assessments, live classes, and the instructor and admin portals, for both Kalpla and Academics.
- CI quality gates. Wire the suite into GitHub Actions so tests run automatically on every deploy to staging, and grow it into a gate that stops a release when core flows break. Smoke and regression tiers, parallel runs, and failure reports with screenshots, traces and videos.
- Keeping the suite trustworthy. Flaky tests destroy confidence.

Hunt down flakiness, quarantine what cannot be fixed yet, and make sure a red build always means a real problem.

- API testing. Test our REST APIs directly, which is faster and more stable than going through the UI. Catch broken contracts between frontend and backend, and cover authorization and role-based access for learners, instructors and admins.

- Test data and environments.



Create and manage test users, courses and fixtures so tests are repeatable and never depend on leftover state.
- Deciding what to automate. Prioritise by risk. Some things are worth automating on day one, and some are better left to manual or exploratory testing.

We want you to make and explain those calls.

- Working with the team. Pair with our QA tester to turn test cases and manual checks into automated specs. Work with developers to add stable test selectors and reproduce bugs.

Write bug reports a developer can act on without a follow-up conversation.

Your first 90 days, roughly

1. A framework decision, with a short written rationale.
2. A green smoke suite running in CI on every staging deploy.
3. A prioritised coverage plan for the full regression suite.

What we are looking for

Automation and engineering

- You have set up a test automation framework from scratch at least once, not only added tests to one somebody else built.

Tell us what you would do differently now

- 2 to 4 years in QA, with at least 2 years writing and maintaining UI automation on real projects
- Strong hands-on Playwright (preferred) or Cypress: page objects, fixtures, auth state reuse, network interception and parallelisation

- Solid JavaScript or TypeScript. You write test code the way developers write production code: readable, reusable and reviewed
- API testing with Postman, Playwrights request API or similar, and a good grasp of HTTP, status codes, auth tokens and JSON

- CI/CD experience, ideally GitHub Actions: running suites in pipelines, handling secrets safely, publishing reports
- Comfort with Git, pull requests and code review

Testing judgement

- A clear sense of what makes a test flaky and how to design it out: proper waits instead of fixed sleeps, isolated test data, resilient selectors
- You know the difference between smoke, regression and exploratory testing, and when each is worth the cost

- Risk-based thinking. You can look at a recent feature and say where it is most likely to break

AI-assisted development We build with Claude Code, and it is a genuine accelerator for test automation.

We are looking for someone who:

- Uses AI to write and refactor test specs faster,



then reviews every line, because a test that passes for the wrong reason is worse than no test
- Can spot when AI-generated tests are shallow: checking that a page loaded rather than that the feature actually works

How you work

- You take ownership of quality. A regression reaching production bothers you, and you go back and add the test that would have caught it
- Clear written communication. A lot of our alignment happens in Notion and Slack
- Self-directed and comfortable being the go-to person for automation

Nice to have These are genuinely optional. Tell us if you have them, and do not worry if you do not.

- Mobile automation for React Native apps (Detox, Appium or Maestro)
- Testing real-time or video features (WebRTC, WebSockets)
- Testing payment flows in sandbox mode (Cashfree, Razorpay or similar)
- Visual regression, accessibility testing (axe) or basic performance testing (k6)
- Experience with products that have multiple user roles and permissions, or in EdTech

Who this role is probably not right for We would rather be honest upfront than waste your time.

- If you mainly want to do manual or exploratory testing. It matters here, but it is not this seat
- If you want an established framework to maintain. There is not one yet, and building it is the job
- If AI-assisted tooling feels like a threat rather than a tool, we are probably not aligned

What you get

- Real ownership. You define how quality works at Kalpla, rather than following someone else’s process
- Visible impact. Fewer regressions reaching production, and you will be able to measure it
- Direct access to the Head of Engineering and the developers. No layers to push an idea through
- A team that is genuinely investing in automation and AI-assisted development

Location and work model You will be on-site with us in Udupi for the first 45 days. We have found that the first few weeks are where you absorb the product, meet the team properly, and build the context that makes remote work possible afterwards. After that we move to a hybrid model.

How our hiring process works

1. Profile review. Your resume, plus links to any automation frameworks or projects you have built.
2. Intro conversation. 30 to 45 minutes with the Head of Engineering, mostly about how you think about quality.
3. Practical task. Automate a few real flows. You are welcome to use Claude Code or any AI assistant.
4. Walkthrough. Explain your test design and the trade-offs you made. We will ask why you tested what you did, and what you chose to skip.
5. Offer.

📌 QA Automation Engineer (Udupi)
🏢 Learncap Academy
📍 Udupi