The 90-Day SDET Blueprint: From Manual Tester to Modern SDET With a Portfolio That Proves It

Last month I watched a LinkedIn post from Nikhil Sidana rack up 261 reactions and 231 comments with a single line of advice: “Stop applying to 100 jobs this weekend. Build this 2-hour portfolio project instead.” The comment section exploded. Manual testers tagged colleagues. Engineering managers bookmarked it. Recruiters shared it with the note, “This is what we look for.”

That one sentence crystallizes everything wrong with the way most manual testers try to break into SDET roles—and everything right about the approach that actually works. If you are a manual QA professional reading this in 2026, this article is your complete operating manual. We will cover the 2-hour portfolio project Nikhil referenced, a full 90-day week-by-week roadmap, resume transformations, Page Object patterns, CI/CD pipeline setup, and every tool you need to land your first SDET offer.

Why “Manual Test Execution” on Your Resume Is a Conversion Killer in 2026

Let us be direct. The hiring market has shifted permanently. In 2024, “manual testing” was a yellow flag on a resume. In 2026, it is a red one. Here is why your resume saying “Manual Test Execution” is not converting for SDET roles:

• ATS filters have evolved. Applicant Tracking Systems now score resumes on keyword density AND context. “Manual test execution” paired with zero automation keywords drops your resume into the reject pile before a human ever reads it.
• AI-assisted testing is the baseline. Companies expect even junior SDETs to leverage AI tools for test generation, debugging, and maintenance. If your resume does not mention CI/CD, API testing, or framework design, you look like a candidate from 2019. Check out how Playwright test agents are reshaping AI testing to understand the new baseline.
• The supply-demand imbalance is brutal. There are roughly 4x more manual QA professionals looking to transition than there are entry-level SDET openings. The only differentiator left is proof of work—a portfolio.
• Hiring managers scan for GitHub links. A 2026 survey by Test Automation University found that 73% of SDET hiring managers check a candidate’s GitHub profile before scheduling an interview. No repo? No callback.

This is not gatekeeping. This is the market. The good news? The bar for “impressive portfolio” is surprisingly low because so few testers bother to build one at all.

The Career Gap Between Manual QA and Modern SDET

Before we jump into the blueprint, let us map the actual gap. Understanding what you need to learn—and what you can skip—saves months of wasted effort.

What Manual QA Gives You (That Is Still Valuable)

• Test design thinking. You already know how to decompose requirements into test cases. This is the hardest skill to teach engineers.
• Defect intuition. Years of exploratory testing give you a nose for where bugs hide. Automation without this intuition produces brittle, low-value test suites.
• Domain knowledge. If you have spent three years testing a fintech application, you understand edge cases that a fresh computer science graduate will take months to learn.
• Communication skills. Writing clear bug reports, collaborating with developers, presenting test results to stakeholders—these soft skills compound in SDET roles.

What You Need to Add

• Programming fluency in at least one language (Python, JavaScript, or Java).
• Test framework proficiency with tools like Playwright, Cypress, Selenium, or RestAssured.
• API testing skills—understanding REST, HTTP methods, status codes, authentication, and payload validation.
• CI/CD pipeline knowledge—GitHub Actions, Jenkins, or GitLab CI.
• Version control mastery—Git workflows, branching strategies, pull requests.
• A public portfolio that demonstrates all of the above.

The gap is real but bridgeable. In 90 days of focused effort, you can close it. Let us start with the fastest win: the 2-hour portfolio project.

The 2-Hour Portfolio Project: 4 Steps That Land Interviews

This is the project Nikhil Sidana was talking about—the one that generated the highest engagement in the SDET community. It is not a toy. It is a fully functional API test suite with CI/CD integration that runs on every push. Hiring managers can see the green badge on your README and click through to verify your pipeline actually passes. That single artifact puts you ahead of 90% of applicants.

Step 1: Write 3 Basic API Tests With Playwright

We will use Playwright for API testing because it is the fastest path from zero to working tests in 2026. If you prefer Java, substitute RestAssured—the principles are identical. We will test against the free Reqres API.

First, initialize your project:

mkdir sdet-portfolio-api-tests
cd sdet-portfolio-api-tests
npm init -y
npm install @playwright/test --save-dev

Now create your test file at tests/api.spec.ts:

import { test, expect } from '@playwright/test';

const BASE_URL = 'https://reqres.in/api';

# Test suite covering GET, POST, and 404 scenarios
test.describe('Reqres API Test Suite', () => {

  test('GET /users - should return a list of users with status 200', async ({ request }) => {
    const response = await request.get(`${BASE_URL}/users?page=1`);

    expect(response.status()).toBe(200);

    const body = await response.json();
    expect(body.data).toBeTruthy();
    expect(body.data.length).toBeGreaterThan(0);
    expect(body.data[0]).toHaveProperty('id');
    expect(body.data[0]).toHaveProperty('email');
    expect(body.data[0]).toHaveProperty('first_name');
    expect(body.data[0]).toHaveProperty('last_name');
  });

  test('POST /users - should create a new user with status 201', async ({ request }) => {
    const payload = {
      name: 'Pramod Dutta',
      job: 'Senior SDET'
    };

    const response = await request.post(`${BASE_URL}/users`, {
      data: payload,
      headers: { 'Content-Type': 'application/json' }
    });

    expect(response.status()).toBe(201);

    const body = await response.json();
    expect(body.name).toBe(payload.name);
    expect(body.job).toBe(payload.job);
    expect(body.id).toBeTruthy();
    expect(body.createdAt).toBeTruthy();
  });

  test('GET /users/9999 - should return 404 for non-existent user', async ({ request }) => {
    const response = await request.get(`${BASE_URL}/users/9999`);

    expect(response.status()).toBe(404);

    const body = await response.json();
    expect(Object.keys(body).length).toBe(0);
  });

});

Add the Playwright config file playwright.config.ts:

import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  timeout: 30000,
  retries: 1,
  reporter: [['html'], ['list']],
  use: {
    extraHTTPHeaders: {
      'Accept': 'application/json',
    },
  },
});

Run the tests locally to confirm they pass:

npx playwright test

You should see three green checkmarks. That is Step 1 done in under 30 minutes.

Step 2: Push to GitHub

If you do not have a GitHub account, create one now. Then run these commands:

# Initialize git repo
git init
git add .
git commit -m "feat: add API test suite with Playwright"

# Create repo on GitHub (using GitHub CLI)
gh repo create sdet-portfolio-api-tests --public --source=. --remote=origin

# Push to main branch
git push -u origin main

Step 3: Create .github/workflows/test.yml for Auto-Running on Push

This is the step that separates “I wrote some tests” from “I built a production-grade test pipeline.” Create the file .github/workflows/test.yml:

name: API Test Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # Runs every Monday at 6 AM UTC

jobs:
  api-tests:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout repository
        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
        run: npx playwright install --with-deps chromium

      - name: Run API tests
        run: npx playwright test

      - name: Upload test report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Commit and push this workflow:

git add .github/workflows/test.yml
git commit -m "ci: add GitHub Actions test pipeline"
git push origin main

Within two minutes, navigate to your repository’s Actions tab. You will see the pipeline running. When it completes with a green checkmark, you have just built a real CI/CD pipeline. If you have ever dealt with flaky tests killing your CI/CD pipeline, you will appreciate how clean API tests keep your pipeline green and reliable.

Step 4: Add CI/CD Green Badge to Resume and LinkedIn

Add this line to the top of your repository’s README.md:

![API Test Pipeline](https://github.com/YOUR_USERNAME/sdet-portfolio-api-tests/actions/workflows/test.yml/badge.svg)

# SDET Portfolio - API Test Suite

Automated API test suite built with Playwright, integrated with GitHub Actions CI/CD.

## Tech Stack
- **Language:** TypeScript
- **Framework:** Playwright
- **CI/CD:** GitHub Actions
- **API Under Test:** Reqres.in

## Running Locally
npm install
npx playwright test

On your resume, add the GitHub link directly under your name or in a “Projects” section. On LinkedIn, update your headline to include “SDET | Test Automation | Playwright” and pin a post showcasing your green-badge repo. Hiring managers will click it, see the green badge, and immediately understand you can build and maintain test automation pipelines.

That is the complete 2-hour project. Now let us zoom out and build the full 90-day plan around it.

The Complete 90-Day SDET Transition Roadmap

This roadmap assumes you are working full-time in a manual QA role and can dedicate 1.5 to 2 hours per day to upskilling. If you have more time, you can compress the timeline. If you have less, extend it—but do not skip steps.

Month 1 (Weeks 1-4): Automation Fundamentals

The goal of Month 1 is simple: get comfortable writing code and running automated tests. You do not need to be a software engineer. You need to be a tester who can express test logic in code.

• Choose one language. Python or JavaScript/TypeScript. Do not debate this for more than five minutes. Pick the one used at your current company. If neither is used, pick JavaScript—it pairs natively with Playwright.
• Learn the language basics. Variables, functions, loops, conditionals, arrays/lists, objects/dictionaries, async/await. You do not need classes or design patterns yet.
• Write your first UI test. Use Playwright to automate a simple flow: navigate to a page, click a button, assert the result.
• Understand selectors. CSS selectors, XPath basics, and Playwright’s built-in locators (getByRole, getByText, getByTestId).
• Build the 2-hour portfolio project. Follow the four steps above. This becomes your anchor project for the rest of the 90 days.

For inspiration on building automation frameworks with AI assistance, read Vibe Coding Automation Framework Part 1—it shows how modern SDETs leverage AI to accelerate framework development from day one.

Month 2 (Weeks 5-8): API Testing + CI/CD Integration

Month 2 is where you become dangerous. API testing is the single highest-leverage skill for an SDET because API tests are fast, stable, and catch bugs before they reach the UI.

• Deep dive into REST APIs. Understand HTTP methods (GET, POST, PUT, PATCH, DELETE), status codes (200, 201, 400, 401, 403, 404, 500), headers, authentication (Bearer tokens, API keys, OAuth basics), and request/response payloads.
• Expand your test suite. Add 10 more API tests to your portfolio project covering CRUD operations, error handling, authentication flows, and data validation.
• Master GitHub Actions. Understand workflows, jobs, steps, matrix strategies, environment variables, secrets, and artifacts. Add Jenkins basics if time permits.
• Add a second project. Create a UI test automation project using Playwright that tests a real web application. Push it to GitHub with its own CI/CD pipeline.
• Practice Git workflows. Create feature branches, write pull requests, do code reviews on open-source test repos.

If you want to see how a real-world automation framework evolves through iterations, How I Built a Real-Life Automation Framework Using Cursor AI Part 2 walks through the complete process from scaffold to production-ready code.

Month 3 (Weeks 9-12): Advanced Patterns — Page Objects, Test Data, Reporting

Month 3 is about polish, advanced skills, and interview readiness. By the end, you should have a portfolio that makes hiring managers say, “This person can contribute from day one.”

• Learn the Page Object Model (POM). Refactor your UI tests to use POM. This design pattern is asked about in 90% of SDET interviews.
• Add test data management. Use fixtures, factories, or environment-based configuration to manage test data across environments.
• Implement parallel test execution. Configure Playwright to run tests in parallel. Demonstrate you understand sharding and test isolation.
• Add reporting. Integrate Allure or Playwright’s built-in HTML reporter. Include screenshots on failure.
• Learn Docker basics. Containerize your test suite so it runs identically on any machine.
• Practice mock interviews. Use the STAR method to describe your portfolio projects. Be ready to explain every line of code.

Here is a production-quality Page Object pattern you should implement in your UI test project:

# Page Object for Login Page — keeps selectors and actions in one place
import { type Page, type Locator } from '@playwright/test';

export class LoginPage {
  readonly page: Page;
  readonly usernameInput: Locator;
  readonly passwordInput: Locator;
  readonly loginButton: Locator;
  readonly errorMessage: Locator;

  constructor(page: Page) {
    this.page = page;
    this.usernameInput = page.getByTestId('username');
    this.passwordInput = page.getByTestId('password');
    this.loginButton = page.getByRole('button', { name: 'Login' });
    this.errorMessage = page.locator('.error-message');
  }

  async navigate() {
    await this.page.goto('https://www.saucedemo.com');
  }

  async login(username: string, password: string) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }

  async getErrorText(): Promise<string> {
    return await this.errorMessage.textContent() ?? '';
  }
}

And the test file that uses it:

# Test file using Page Object Model pattern
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';

test.describe('Login Tests Using Page Object Model', () => {

  test('should login successfully with valid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.navigate();
    await loginPage.login('standard_user', 'secret_sauce');
    await expect(page).toHaveURL(/inventory/);
  });

  test('should show error for invalid credentials', async ({ page }) => {
    const loginPage = new LoginPage(page);
    await loginPage.navigate();
    await loginPage.login('invalid_user', 'wrong_password');
    const error = await loginPage.getErrorText();
    expect(error).toContain('Username and password do not match');
  });

});

This pattern keeps your locators in one place, makes tests readable, and is exactly what interviewers want to see. For more on how AI tools like Playwright test agents can help generate Page Objects automatically, explore our deep dive on the topic.

Week-by-Week Learning Plan Table

Print this table. Pin it to your wall. Check off each week as you complete it.

Week	Focus Area	Deliverable	Tools
1	Language basics (variables, functions, loops)	Complete 20 coding exercises on LeetCode or HackerRank	JavaScript/TypeScript or Python, VS Code
2	Git fundamentals and Playwright setup	Local Git repo with first passing Playwright test	Git, GitHub, Playwright, Node.js
3	UI test automation basics (selectors, assertions)	5 UI tests for a demo web application	Playwright, CSS selectors, DevTools
4	2-hour portfolio project build	Public GitHub repo with 3 API tests and green CI badge	Playwright, GitHub Actions, Reqres API
5	REST API deep dive (HTTP methods, status codes)	Postman collection with 15+ requests and test scripts	Postman, cURL, Reqres API, JSONPlaceholder
6	API test automation with Playwright	Expand portfolio to 15 API tests covering CRUD and auth	Playwright, TypeScript, REST APIs
7	GitHub Actions and CI/CD pipelines	Enhanced pipeline with matrix testing and reporting	GitHub Actions, Jenkins basics, YAML
8	Second portfolio project (UI automation)	New repo with 10 UI tests and CI/CD pipeline	Playwright, SauceDemo, GitHub Actions
9	Page Object Model and design patterns	Refactored UI tests using POM structure	Playwright, TypeScript, POM pattern
10	Test data management and parallel execution	Configurable test suite with parallel runs and fixtures	Playwright fixtures, env configs, sharding
11	Docker, reporting, and advanced CI/CD	Dockerized test suite with Allure reports	Docker, Allure, GitHub Actions artifacts
12	Portfolio polish and interview preparation	3 repos complete, updated resume, 3 mock interviews done	GitHub profile README, resume builder, STAR method

How to Demonstrate Skills, Not Just Claim Them

The fundamental shift in SDET hiring is this: claims are worthless, demonstrations are everything. Here is the difference in practice:

Claiming (Weak)	Demonstrating (Strong)
“Proficient in Playwright”	GitHub repo with 25 Playwright tests and green CI badge
“Experience with CI/CD”	GitHub Actions workflow running on every push with artifacts
“Knowledge of API testing”	Test suite covering GET, POST, PUT, DELETE with auth and error handling
“Familiar with Page Object Model”	Refactored test project with clean POM structure anyone can read
“Strong problem-solving skills”	Blog post or LinkedIn article explaining how you debugged a flaky test

Every bullet on your resume should have a corresponding piece of evidence someone can verify. If you say you know GitHub Actions, your repo should have a .github/workflows directory. If you say you understand test design, your tests should have meaningful names and cover positive, negative, and edge cases.

Resume and LinkedIn Transformation Checklist

Resume Before: The Manual QA Version

EXPERIENCE
QA Analyst | Acme Corp | 2022 - Present
- Performed manual test execution for web and mobile applications
- Created and maintained test cases in Excel spreadsheets
- Reported defects in Jira with screenshots and steps to reproduce
- Participated in daily standup meetings and sprint planning
- Conducted regression testing before each release

Resume After: The SDET-Ready Version

EXPERIENCE
QA Engineer | Acme Corp | 2022 - Present
- Designed and executed 200+ test cases across web and mobile platforms,
  identifying 45+ critical defects pre-release
- Built automated API test suite using Playwright/TypeScript, reducing
  regression cycle from 4 hours to 12 minutes
- Implemented CI/CD pipeline with GitHub Actions, achieving automated
  test execution on every pull request
- Created data-driven test frameworks covering CRUD operations,
  authentication flows, and error handling scenarios

PROJECTS
SDET Portfolio - API Test Suite | github.com/username/sdet-portfolio
- 15 automated REST API tests with Playwright validating CRUD and auth
- GitHub Actions CI/CD with scheduled runs and HTML reporting
- Tech: TypeScript, Playwright, GitHub Actions, REST APIs

SDET Portfolio - UI Automation | github.com/username/sdet-ui-tests
- End-to-end UI tests using Page Object Model design pattern
- Parallel execution with Playwright sharding, 60% faster runs
- Tech: TypeScript, Playwright, Docker, Allure Reports

LinkedIn Optimization Checklist

• Update headline: “SDET | Test Automation Engineer | Playwright | CI/CD | API Testing”
• Add GitHub portfolio link in the Contact Info and Featured sections
• Pin a post showcasing your green-badge CI/CD repository
• Update About section to mention automation skills, tools, and your transition story
• Add each portfolio project as a separate entry under Projects
• List certifications: Playwright, ISTQB, or any testing-related credentials
• Request recommendations from colleagues who can speak to your technical growth
• Follow and engage with SDET thought leaders (comment meaningfully, not just “Great post!”)
• Share weekly updates on your 90-day journey—visibility attracts recruiters

8 Common Mistakes That Delay the Transition

1. Tutorial hell. Watching 47 Udemy courses without writing a single test. Cap tutorials at 30% of your time; spend 70% writing code.
2. Tool hopping. Starting with Selenium, switching to Cypress, trying Playwright, going back. Pick one framework and go deep for 90 days.
3. Perfectionism paralysis. Refusing to push code because “it is not good enough.” A messy public repo beats a pristine private one nobody can see.
4. Skipping API testing. Going straight to UI automation because it feels familiar. API tests are faster, more stable, and more impressive to hiring managers.
5. Ignoring CI/CD. A test suite that only runs locally is like a car with no engine. The pipeline makes your tests professionally valuable. Understand why flaky tests kill CI/CD pipelines so you can build robust ones.
6. Mass-applying without a portfolio. Ten targeted applications with a portfolio link outperform 100 generic submissions without one.
7. Not networking. Share your progress on LinkedIn. Tag testing community members. Post what you learned each week. Opportunities come through visibility.
8. Underestimating soft skills. Technical skills get you the interview. Communication and problem-solving narratives get you the offer. Practice the STAR method.

Frequently Asked Questions

1. Can I become an SDET without a computer science degree?

Absolutely. The majority of successful SDETs I know transitioned from manual QA, biology, mechanical engineering, and even non-technical backgrounds. What matters is your portfolio and your ability to demonstrate competence. A computer science degree is a nice-to-have, not a requirement. Your GitHub profile IS your degree in 2026.

2. Should I learn Selenium or Playwright in 2026?

Start with Playwright. It has better developer experience, built-in API testing, auto-waiting, superior debugging tools, and is backed by Microsoft with active development. Selenium still exists in legacy codebases, but new projects overwhelmingly choose Playwright. If a job requires Selenium, you can learn it in a week once you know Playwright—the underlying concepts are identical.

3. How many hours per day do I need for this 90-day plan?

The roadmap is designed for 1.5 to 2 hours per day, six days a week—roughly 10 to 12 hours per week. Consistency beats intensity. Forty-five minutes every morning before work is more effective than a 6-hour Saturday marathon followed by nothing for a week. If you can only manage 1 hour daily, extend to 120 days. The key is to never go more than two consecutive days without writing code.

4. Will AI replace SDETs before I finish the transition?

No. AI is augmenting SDETs, not replacing them. Tools like GitHub Copilot and Claude help you write tests faster, but they cannot design test strategies, understand business context, or make judgment calls about risk. The SDETs who use AI tools effectively are becoming more productive and more valuable. The ones who ignore AI are falling behind. Learn to use AI as a coding partner—it is a multiplier, not a replacement.

5. What salary can I expect after transitioning from manual QA to SDET?

In India, the jump is typically 40-80% depending on city and company size. A manual QA professional earning 6-8 LPA can expect 10-15 LPA in their first SDET role. In the US, SDETs command $90K-$140K depending on experience and location, compared to $55K-$80K for manual QA. Remote SDET positions from India with US companies typically pay $30K-$60K USD. The ROI on 90 days of focused effort is massive—this might be the highest-leverage career investment you ever make.

Your Action Plan Starts Now

Let me bring this back to where we started. Nikhil Sidana’s advice was deceptively simple: stop mass-applying and build something instead. The 2-hour portfolio project is your quickest win. The 90-day roadmap is your complete plan. The resume and LinkedIn checklists show you exactly how to present your new skills.

Here is what I want you to do in the next 24 hours:

1. Open your terminal and run mkdir sdet-portfolio-api-tests.
2. Follow Step 1 from this article. Write the three API tests. Run them locally.
3. Push to GitHub. It does not matter if the code is imperfect. Ship it.
4. Add the CI/CD pipeline. Watch the green badge appear on your README.
5. Share your repo link on LinkedIn with a post: “Day 1 of my SDET journey. Just built my first automated API test suite with CI/CD. 89 days to go.”

The testing industry is not going to wait for you to feel ready. The tools are free. The knowledge is available. The only missing ingredient is your decision to start.

To accelerate your journey, explore the Vibe Coding Automation Framework series for building frameworks with AI, and read How I Built a Real-Life Automation Framework Using Cursor AI Part 2 for real-world implementation patterns. If pipeline stability is a concern, our guide on flaky tests killing CI/CD pipelines will save you hours of debugging.

The best time to start was last year. The second best time is right now.