QA Take Home Assignment Submission Template (2026)

TL;DR

A strong QA take-home submission lets a reviewer understand scope in two minutes and reproduce the result with one documented command. Package a concise README, risk-based test strategy, focused cases and defects, runnable automation, evidence, limitations, and a professional delivery note.

Key Takeaways

• Make the reviewer path obvious with one README, one setup command, one test command, and clearly named evidence folders.
• Trace every required deliverable to a file or section before spending time on optional framework polish.
• Show risk-based judgment through a prioritized coverage matrix, not through a long unranked test-case list.
• Include reproducible failure evidence and specific bug reports while keeping tokens, credentials, and personal data out of the package.
• Run the final archive or repository from a clean directory so hidden local dependencies cannot surprise the reviewer.
• Use a concise submission email that states scope, execution commands, known limitations, and the exact repository or archive location.
• Prepare to defend why you chose each test level, assertion, locator, and deferred scenario.

A qa take home assignment submission template should remove review friction while showing how you think about product risk. Your package needs more than passing tests: it should tell the reviewer what you covered, why you prioritized it, how to run it, what failed, and what you would do with more time.

Use this guide as a working submission shell. Replace the sample catalog scenario with the assigned product, preserve the structure that matches the brief, and delete artifacts that add no evidence. If the task includes automation, compare your solution with the Playwright TypeScript framework tutorial. For a manual-only exercise, the same README, scope matrix, defect format, and delivery controls still apply.

The goal is not to impersonate a production test platform. The goal is to deliver a bounded piece of QA work that another engineer can inspect and reproduce without guessing.

TL;DR

Submit the smallest complete package that satisfies the brief. A reviewer should be able to scan README.md, locate the requested artifacts, execute the suite, and understand a failure without opening every source file.

1. What a QA Take Home Assignment Submission Template Must Prove

A take-home assignment evaluates delivery judgment as much as testing technique. Build the package around four claims: you understood the request, selected coverage deliberately, produced credible evidence, and respected the reviewer's time. Each claim needs an observable artifact.

Start by converting the prompt into a compliance table. Do this before choosing folders or adding dependencies. The table prevents an attractive automation project from omitting a requested exploratory charter or defect log.

Treat 'complete' as a verifiable state, not a feeling. A test strategy exists only if it identifies product-specific risks. An automated check exists only if the documented command discovers and runs it. A defect exists only if another person can reproduce the observed behavior or understand why reproduction is blocked.

Keep the assignment's original vocabulary. If the brief says 'reservation,' do not rename it 'order' throughout your model because your framework started from an ecommerce sample. Precise domain language signals that you tested the supplied system rather than pasting a portfolio project.

2. Read the Brief, Resolve Ambiguity, and Set a Timebox

Read the prompt once for product behavior and once for delivery constraints. Mark mandatory tools, prohibited tools, deadline and timezone, expected file format, repository visibility, credentials process, and whether communication is allowed. Copy those constraints into a private working checklist so a late packaging decision does not violate them.

Classify ambiguities by impact. A missing logo specification can wait. An unclear rule about duplicate account creation changes the oracle for a high-value test and deserves a concise question. If you cannot get clarification, record an explicit assumption such as: 'A second registration with the same email should be rejected without creating another customer record.' Link the assumption to the affected cases.

Use a fixed budget that matches the requested limit. For an illustrative six-hour exercise, a practical plan is 45 minutes for exploration and requirements, 60 minutes for strategy and cases, 150 minutes for core implementation, 45 minutes for defects and evidence, and 60 minutes for cleanup, clean-room execution, and delivery. These numbers are a planning example, not a hiring benchmark. Reduce optional coverage when implementation slips, but protect reproducibility and documentation time.

Write a stop rule: 'At the final implementation checkpoint, no new scenarios begin.' This guards against a half-finished extra test breaking the default command. Put unfinished experiments on a separate branch or omit them from the submission. Describe valuable deferred scenarios in priority order, with a sentence explaining the risk each would address.

If the job description influenced your approach, upload the relevant resume and role context in the resume analysis workspace. Use the output to understand emphasis, but keep the assignment itself grounded in its rubric and product behavior.

3. Build a Reviewer-Friendly Folder Structure

Use a shallow structure whose names describe evidence. The following layout supports a mixed manual and Playwright assignment without inventing architectural layers:

qa-catalog-assignment/
├── README.md
├── package.json
├── package-lock.json
├── playwright.config.ts
├── .gitignore
├── docs/
│   ├── test-strategy.md
│   ├── test-cases.md
│   └── defects.md
├── tests/
│   └── catalog.spec.ts
├── scripts/
│   └── verify-submission.mjs
└── evidence/
    ├── execution-summary.txt
    └── defect-001.png

Do not include node_modules, local .env files, browser binaries, editor settings, raw videos unrelated to a failure, or an enormous generated report unless the instructions request it. Store a small execution summary in version control and tell the reviewer how to generate the complete HTML report. If you include screenshots, name them by defect or scenario so they retain meaning outside your desktop.

Prefer relative paths in documentation. A link such as docs/defects.md works after cloning; /Users/name/Desktop/task/docs/defects.md does not. Check case sensitivity because Test-Cases.md may work locally on one filesystem while a README link to test-cases.md fails in CI.

For ideas on presenting QA work beyond this task, study beginner QA portfolio GitHub examples. The assignment repository should remain narrower than a general portfolio.

4. QA Take Home Assignment Submission Template for README.md

Your README is the reviewer's control panel. Put the result and the run path before design commentary. Adapt this copy-ready template:

# Catalog QA Take-Home Assignment

## Result
Implemented the two required critical checks and documented eight prioritized
manual scenarios. One medium-severity product defect was reproduced.

## Contents
- Test strategy: docs/test-strategy.md
- Test cases: docs/test-cases.md
- Defects: docs/defects.md
- Automation: tests/catalog.spec.ts
- Execution notes: evidence/execution-summary.txt

## Environment
- Node.js 22 LTS or newer compatible LTS release
- npm
- Chromium installed by Playwright
- macOS, Linux, or Windows

## Setup
1. Run: npm ci
2. Run: npx playwright install chromium
3. Run: npm run test:ci
4. Open the generated report with: npm run report

## Scope
Covered product filtering, empty results, and the assigned critical catalog path.
See docs/test-strategy.md for risks, priorities, and exclusions.

## Assumptions
- Product names are unique within the supplied fixture.
- Filtering is case-insensitive.
- The result count updates after the visible list settles.

## Known Limitations
- The sample uses deterministic local markup because no stable hosted test
  environment was supplied.
- Accessibility scanning and mobile viewport coverage are proposed next steps.

## Design Decisions
Used role-based locators and outcome-focused assertions. Kept the test local to
make the submission reproducible and avoided a page object for one short spec.

## Clean-Run Result
Record the date, commit, command, operating system, and pass/fail count here.

Make the Result section factual. Do not claim comprehensive coverage when you tested one feature, and do not call an unverified behavior a confirmed defect. Separate assumptions from limitations: an assumption defines how you interpreted missing information, while a limitation identifies work the submission does not perform.

5. Present a Risk-Based Test Strategy and Coverage Matrix

A credible strategy connects user harm to test activity. Begin with the feature's purpose, identify failure consequences, define what is in and out, then choose the cheapest dependable level for each check. The guide to writing a test strategy gives a fuller structure for larger systems.

Use a matrix like this for a catalog filter assignment:

Define entry conditions such as an accessible build, working seed data, and valid credentials. Define exit criteria in terms of the assignment, for example: all P0 scenarios executed, required automation passes from a clean install, and every observed blocker is documented. Do not use '100 percent tested' as an exit criterion because the denominator is undefined.

List exclusions with reasons. Performance testing may be excluded because the local fixture cannot represent production load; cross-browser execution may be deferred because the exercise requires Chromium only. An exclusion is not an apology. It demonstrates scope control when paired with an impact statement and next action.

For a portfolio-quality strategy artifact, use documenting a QA portfolio test strategy case study after the assignment is delivered and confidentiality permits reuse. Never publish the employer's private brief, credentials, product data, or proprietary code.

6. Include Concrete Test Cases and Defect Reports

Write cases at the level the prompt needs. A compact case should expose priority, preconditions, data, actions, and an observable expected result. Avoid splitting every click into a separate case or writing outcomes such as 'works correctly.'

TC-CAT-003: Empty search returns a recoverable state

• Priority: P0
• Preconditions: Catalog contains no item named zxq-not-present; user is on the catalog page.
• Data: Search term zxq-not-present.
• Steps: Enter the term, submit the search, inspect the result region, then clear the query.
• Expected: Zero product cards appear; a status message says no products match; clearing restores the default catalog without a full-page error.
• Evidence: Execution note records browser, build, and observed result.

Pair tests that expose different risks. The positive and negative test case guide helps distinguish a meaningful rejection path from a positive case with different data. For requirement-derived coverage, consult writing test cases from requirements.

A useful defect report makes triage possible:

BUG-001: Product count remains stale after clearing a category filter

• Environment: Assignment build 8f31c2a, Chromium, 1440 by 900 viewport.
• Preconditions: At least two categories contain different product totals.
• Steps: Select Keyboards; note the count; choose All products; compare the count with visible cards.
• Expected: Count equals the number of visible cards after the filter is cleared.
• Actual: All cards return, but the count retains the Keyboards total until reload.
• Severity: Medium, because users receive conflicting catalog information but can still browse.
• Reproducibility: 3 of 3 attempts with the supplied fixture.
• Evidence: evidence/defect-001.png and browser console excerpt with sensitive values removed.

Severity describes impact; priority describes scheduling. If the brief does not define its scale, state your interpretation. Review defect wording against writing a bug report that gets fixed, and never inflate severity to make the submission appear more productive.

7. Add Runnable Automation and Failure Evidence

When automation is requested, make the default route deterministic. This example uses current Playwright APIs, semantic locators, and local markup so a reviewer can run it without depending on a public demo site.

Create package.json:

{
  "name": "qa-catalog-assignment",
  "private": true,
  "type": "module",
  "scripts": {
    "test:ci": "playwright test",
    "report": "playwright show-report",
    "verify:submission": "node scripts/verify-submission.mjs"
  },
  "devDependencies": {
    "@playwright/test": "latest"
  }
}

Verify the manifest with npm install, then run npm ls @playwright/test. The dependency tree should list one installed Playwright Test package without an unmet dependency. Commit the generated package-lock.json so npm ci is available to the reviewer.

Add playwright.config.ts:

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

export default defineConfig({
  testDir: './tests',
  reporter: [
    ['list'],
    ['html', { open: 'never', outputFolder: 'playwright-report' }],
  ],
  use: {
    trace: 'retain-on-failure',
    screenshot: 'only-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  ],
});

Verify configuration discovery with npx playwright test --list. After the spec below exists, the output should show two tests under the chromium project. If it lists zero, confirm the file is inside tests/ and ends in .spec.ts.

Create tests/catalog.spec.ts:

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

const catalogMarkup = `
  <main>
    <h1>Catalog</h1>
    <label for="category">Category</label>
    <select id="category">
      <option>All products</option>
      <option>Keyboards</option>
    </select>
    <p role="status">2 products</p>
    <ul aria-label="Products">
      <li data-category="Keyboards">Compact Keyboard</li>
      <li data-category="Mice">Wireless Mouse</li>
    </ul>
  </main>
  <script>
    const select = document.querySelector('#category');
    const items = [...document.querySelectorAll('li[data-category]')];
    const status = document.querySelector('[role=status]');
    select.addEventListener('change', () => {
      const chosen = select.value;
      let visible = 0;
      for (const item of items) {
        const show = chosen === 'All products' || item.dataset.category === chosen;
        item.hidden = !show;
        if (show) visible += 1;
      }
      status.textContent = visible + (visible === 1 ? ' product' : ' products');
    });
  </script>
`;

test.beforeEach(async ({ page }) => {
  await page.setContent(catalogMarkup);
});

test('filters the visible catalog by category', async ({ page }) => {
  await page.getByLabel('Category').selectOption({ label: 'Keyboards' });

  await expect(page.getByRole('status')).toHaveText('1 product');
  await expect(page.getByRole('listitem')).toHaveCount(1);
  await expect(page.getByRole('listitem')).toHaveText('Compact Keyboard');
});

test('restores every product when the filter is cleared', async ({ page }) => {
  const category = page.getByLabel('Category');
  await category.selectOption({ label: 'Keyboards' });
  await category.selectOption({ label: 'All products' });

  await expect(page.getByRole('status')).toHaveText('2 products');
  await expect(page.getByRole('listitem')).toHaveCount(2);
});

Install the browser with npx playwright install chromium. Verify behavior with npm run test:ci; expect two passed tests and an HTML report directory. Then run npm run test:ci -- --repeat-each=3 to look for obvious state leakage. Repetition is supporting evidence, not proof that a test can never flake.

Keep traces and screenshots for failures, but inspect them before sharing. Authentication tokens, customer records, email addresses, and internal URLs can appear in network logs or pixels. If a real application is in scope, redact sensitive evidence without altering the facts needed to reproduce the issue.

8. Validate the Submission From a Clean State

A passing run in your working directory may depend on cached browsers, untracked fixtures, or environment variables. Clone the repository into a temporary directory or expand the exact archive you plan to send. Follow only the README. Record the commit identifier, runtime, operating system, command, and result in evidence/execution-summary.txt.

Add this dependency-free validator as scripts/verify-submission.mjs:

import { access, readFile } from 'node:fs/promises';

const requiredFiles = [
  'README.md',
  'package.json',
  'playwright.config.ts',
  'docs/test-strategy.md',
  'docs/test-cases.md',
  'docs/defects.md',
  'tests/catalog.spec.ts',
  'scripts/verify-submission.mjs',
];

for (const file of requiredFiles) {
  await access(file);
}

const textFiles = await Promise.all(
  requiredFiles.map(async (file) => [file, await readFile(file, 'utf8')]),
);
const suspicious = /(?:api[_-]?key|token|password)\s*[:=]\s*['"][^'"\s]{8,}/i;
const exposed = textFiles.filter(([, content]) => suspicious.test(content));

if (exposed.length > 0) {
  throw new Error(`Review possible secrets in: ${exposed.map(([file]) => file).join(', ')}`);
}

console.log(`Submission check passed for ${requiredFiles.length} required files.`);

Verify it with npm run verify:submission. The expected output is Submission check passed for 8 required files. This lightweight pattern check cannot guarantee the absence of secrets. Also inspect git status, the files inside the archive, and repository history. Use a dedicated secret scanner if the assignment or organization provides one.

If the reviewer expects a hosted report, deploy a test report to GitHub Pages only when public hosting is allowed. A private assignment should not be exposed merely to make the report easier to click.

9. Write the Submission Email and Control Access

The delivery message should identify the role, provide one authoritative link or attachment, state the main command, and surface limitations that affect review. It should not duplicate the entire README.

Subject: QA Take-Home Submission - [Your Name] - [Role]

Hi [Reviewer Name],

I completed the QA take-home assignment and submitted it here:
[private repository link or attached archive name]

The package includes the test strategy, prioritized cases, defect report,
Playwright checks, and execution notes. From the repository root, run:

npm ci
npx playwright install chromium
npm run verify:submission
npm run test:ci

The README documents assumptions, scope, and known limitations. The required
critical checks pass from a clean install. I limited execution to Chromium as
specified and listed the next coverage priorities in the strategy.

Repository access is granted to [review account] until [agreed date, if any].
Please let me know if you have trouble opening or running the submission.

Thanks,
[Your Name]
[Phone or portfolio link, only if requested or appropriate]

Test private access using the exact reviewer account if the platform supports that view. Do not switch a repository to public to solve an invitation problem without permission. If you send an archive, use the requested channel and filename, such as firstname-lastname-qa-assignment.zip; avoid password protection unless the recipient has agreed on a secure way to receive the password.

10. Final QA Take Home Assignment Submission Template Checklist

Use this checklist against the exact artifact you will deliver, not only your working folder.

Content

• Every prompt requirement maps to a file or README section.
• Scope, exclusions, assumptions, environment, and exit criteria are explicit.
• Coverage is prioritized by product risk.
• Test cases contain observable expected outcomes and controlled data.
• Defects distinguish expected from actual behavior and include reproducible evidence.
• Deferred work is ordered by value, with no claim of exhaustive testing.

Execution

• npm ci succeeds from a clean checkout.
• The documented browser installation command is correct.
• The default test command discovers the intended checks.
• Failed runs produce useful traces, screenshots, or assertion diffs.
• The recorded clean-run result matches the final commit.
• Generated directories are excluded unless the brief requests them.

Security and delivery

• No .env, credentials, tokens, customer data, or private URLs are present.
• Repository visibility and reviewer access match the instructions.
• README links and filename capitalization work after cloning.
• The archive opens to one obvious project root.
• The email includes the correct role, link, command, and limitation summary.
• The final link or attachment was opened once after sending.

A useful self-review rubric is 25 points for requirement coverage, 20 for risk judgment, 20 for reproducibility, 15 for test and code quality, 10 for defect evidence, and 10 for communication and security. This is an illustrative personal quality gate, not a claim about any employer's scoring formula. If your score is weak because a required artifact is missing, fix that before adding another abstraction or visual report.

Interview Questions and Answers

Use the nine model answers in the interviewQnA section of this article to rehearse the defense. Three questions deserve especially concrete responses:

• Why these scenarios? Tie each choice to user impact, repeatability, and the assignment timebox.
• How did you make the suite reliable? Point to isolated state, semantic locators, web-first assertions, and the clean-run record.
• What comes next? Name a short, risk-ordered backlog and identify the failure each addition could reveal.

Practice the explanation in the QA interview practice workspace. Your defense should sound like an engineering review of evidence and constraints, not a memorized tour of filenames.

Common Mistakes

• Optimizing for test count: Ten near-duplicate cases show less judgment than four cases covering distinct business failures.
• Hiding ambiguity: An assertion based on an unstated guess looks incorrect; an assumption with impact is reviewable.
• Using machine-specific setup: Global packages, absolute paths, and uncommitted fixtures make a local pass irrelevant to the reviewer.
• Submitting secrets in evidence: A redacted README cannot repair a token stored in Git history or a trace attachment.
• Treating retries as a fix: Automatic retries can collect diagnostics, but they do not repair shared data, weak synchronization, or unstable locators.
• Overbuilding architecture: Factories, dependency injection, and page layers need a demonstrated maintenance benefit in the submitted scope.
• Writing vague limitations: 'More testing needed' gives no direction; name the missing scenario, risk, and next test level.
• Sending an untested private link: Correct code is still inaccessible when permissions target the wrong account.
• Changing work after submission: Unannounced edits destroy the connection between execution evidence and reviewed commit.

Conclusion

The best qa take home assignment submission template makes reasoning, execution, and evidence easy to inspect. Deliver a requirement map, concise README, prioritized strategy, specific cases and defects, runnable checks, clean-run record, explicit limitations, and one controlled delivery message.

For your next assignment, create the folder shell immediately, paste the compliance table into the README, and reserve the final portion of the timebox for a clean clone. Run the checklist against the exact commit or archive, send the tested link, then prepare a five-minute defense covering your highest risk, strongest assertion, main tradeoff, and next improvement.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Junior QA Postman Take Home Assignment (2026)
• QA Lead Test Strategy Take Home Assignment (2026)
• QA Manager Quality Metrics Take Home Assignment (2026)
• Contract Testing Take Home Assignment (2026)
• Cypress Take Home Assignment Examples (2026)
• How to Grow from QA to QA lead (2026)