Record a Test Automation Portfolio Demo Video

TL;DR

Record a three to five minute QA portfolio demo that explains the risk, runs one representative automated test, creates one safe failure, and uses the report or trace to diagnose it. Finish with your design decisions, limitations, and links to reproducible evidence.

Key Takeaways

• Build the demo around one product risk and one automation story instead of touring every repository file.
• Show a passing run, a controlled failure, and the evidence used to diagnose that failure.
• Use a short shot list and rehearse commands so the recording stays focused and technically accurate.
• Hide secrets, personal data, notifications, tokens, and employer information before capture.
• Add captions, a readable description, and direct links to the repository, strategy, and test report.
• Verify the published video while signed out and on a small screen before sharing it with recruiters.
• Treat the video as a guided evidence path, not as a substitute for runnable code and documentation.

To record test automation portfolio demo video content that helps you get interviews, tell one verifiable engineering story. Show the product risk, the automated check, the result, and how you investigate a failure. A fast tour of tools and folders does not prove the same judgment.

Use this tutorial with the QA Portfolio Job Search Complete Guide for 2026. The video becomes a guided entry point to your repository, report, test strategy, and interview narrative.

You will produce a three to five minute screen recording using a Playwright and TypeScript example. The workflow also applies to Selenium, Cypress, API, mobile, performance, and manual testing projects. Replace sample names and claims with evidence from your own public project.

What You Will Build

By the end, you will have:

• A concise story built around one important product risk.
• A shot list with narration, screen state, and evidence for each scene.
• A repeatable passing test run and a controlled, explainable failure.
• A clean 1080p recording with readable text and no private data.
• Captions and a useful video description linking the supporting artifacts.
• A final quality checklist for publishing and recruiter outreach.

Your finished video should answer five questions: What did you test? Why did it matter? What did you build? How do you know it works? What do you do when it fails?

Use lightly edited scenes for most portfolios. Keep the real command output and artifacts, but remove dead time, repeated attempts, and unrelated navigation. If the example stack is new to you, review the Playwright screenshots and video guide for another practical look at capture artifacts.

Prerequisites

Prepare the following:

• A public repository you own or have permission to share.
• Node.js 22.x and npm 10.x for the example project.
• Playwright Test installed in the project with a committed lockfile.
• Git 2.45 or newer.
• OBS Studio 31.x or the current stable release, or your operating system's screen recorder.
• A microphone or wired headset in a quiet room.
• A Chromium-based browser and a plain browser profile with no private bookmarks.
• A published or local HTML report and one safe failure artifact.

Check the project tools:

node --version
npm --version
npx playwright --version
git status --short

Install dependencies and the Chromium browser if needed:

npm ci
npx playwright install chromium

Do not record employer code, customer data, authentication state, internal URLs, private API responses, terminal history, environment files, access tokens, email, or notification previews. Build a clean-room sample against a public application when professional work cannot be shared.

Step 1: Choose One Story Before You Record a Test Automation Portfolio Demo Video

Choose one critical flow that you can explain, execute, and diagnose in under five minutes. Checkout, login protection, search, file upload, or an API contract works well. Avoid demonstrating the entire regression suite.

Create docs/demo-plan.md in your portfolio project:

# Demo story

Audience: QA recruiter and SDET hiring manager
Product: Demo commerce application
Risk: A shopper can receive an incorrect cart total
Automation: Playwright UI check plus API-level price validation
Proof: Source test, terminal result, HTML report, failure trace
Decision: Use role locators for actions and a test ID for the dynamic total
Limitation: Tax and payment provider behavior are mocked
Call to action: Review the repository, strategy, and published report

The risk is the spine of the video. Every scene should either establish it, test it, explain a decision, or show evidence. Delete scenes that only announce a library, open an empty folder, or scroll through code without interpretation.

Write one honest contribution statement. For example: I designed the risk-based checks, implemented the Playwright tests, configured the report, and documented the investigation. If you forked the application or followed a course, distinguish your work from the starter code.

Verify the step: read the plan aloud in 30 seconds. A listener should be able to repeat the product, risk, your contribution, proof, and limitation. If the story becomes a list of tools, narrow it again.

Step 2: Prepare a Reliable Demo Test

Use a small tagged test so your recording does not depend on the full suite. The following Playwright test is complete when the documented demo application provides these accessible names, route, and test IDs. Adapt the locators and expected value to your real project, then run it before recording.

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

test('cart displays the calculated total @demo', async ({ page }) => {
  await page.goto('/products');
  await page.getByRole('link', { name: 'Trail backpack' }).click();
  await page.getByRole('button', { name: 'Add to cart' }).click();
  await page.getByRole('link', { name: 'Cart' }).click();

  const unitPrice = page.getByTestId('unit-price');
  const quantity = page.getByLabel('Quantity');
  const total = page.getByTestId('order-total');

  await expect(unitPrice).toHaveText('$79.00');
  await expect(quantity).toHaveValue('1');
  await expect(total).toHaveText('$79.00');
});

Add stable scripts to package.json:

{
  "scripts": {
    "test:demo": "playwright test --grep @demo --project=chromium",
    "test:demo:headed": "playwright test --grep @demo --project=chromium --headed",
    "report": "playwright show-report"
  }
}

Configure useful artifacts in playwright.config.ts:

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

export default defineConfig({
  testDir: './tests',
  reporter: [['list'], ['html', { open: 'never' }]],
  use: {
    baseURL: process.env.BASE_URL ?? 'http://127.0.0.1:3000',
    screenshot: 'only-on-failure',
    trace: 'retain-on-failure',
    video: 'retain-on-failure'
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } }
  ]
});

Use no retries during the demo. A retry can hide instability and make the narration confusing. Seed predictable test data, start the application before capture, and keep external services out of the critical path when possible.

Verify the step: run npm run test:demo three times from a clean state. Each run should execute only the intended test, exit with code 0, and create playwright-report/index.html. If results vary, fix the data or environment before recording.

Step 3: Build a Timed Shot List and Narration

Plan scenes instead of writing a word-for-word speech. A rigid script often sounds read aloud, while no script produces rambling. Use short prompts that state what the viewer sees and why it matters.

| Time | Screen | Narration goal |
|---|---|---|
| 0:00-0:20 | Project title and app | Name the risk and your contribution |
| 0:20-0:50 | README evidence links | Show where proof lives |
| 0:50-1:35 | Representative test | Explain locator and assertion choices |
| 1:35-2:05 | Passing command | Connect output to the risk |
| 2:05-3:05 | Controlled failure and report | Diagnose with trace or screenshot |
| 3:05-3:40 | Strategy and limitations | Explain scope and tradeoffs |
| 3:40-4:00 | Repository links | Give the viewer a next action |

Open with the outcome: This project checks whether a shopper sees the correct cart total. I built the risk-based Playwright coverage and reporting. I will show the test, run it, and diagnose a controlled failure.

Narrate decisions, not visible syntax. Instead of saying, Here I call getByRole, explain, I use the button's accessible role and name because it matches how a user and assistive technology find the control. Pause briefly after commands and scene changes.

Keep the repository evidence aligned with your narration. A strong QA GitHub project README for recruiters gives viewers direct paths to the files you mention.

Verify the step: rehearse with a timer and record a disposable take. Stay between three and five minutes, speak at a natural pace, and confirm that every claim is visible or linked. Cut a scene before increasing speaking speed.

Step 4: Sanitize and Arrange the Recording Environment

Create a dedicated desktop or virtual workspace. Close email, chat, password managers, cloud dashboards, unrelated terminals, and private browser tabs. Turn on Do Not Disturb and use a clean browser profile.

Prepare the terminal without exposing history:

clear
printf 'Ready to run the tagged portfolio demo.\n'
npm run test:demo

Do not type secrets on screen, even if you plan to blur them later. Load safe values from a local ignored file, and make sure error output cannot print credentials. Search the visible project for common secret patterns before capture:

git status --short
git ls-files | rg '(^|/)(\.env|auth|storage-state)' || true
rg -n 'API_KEY|TOKEN|PASSWORD|SECRET' --glob '!node_modules/**' --glob '!playwright-report/**' .

Review fixtures, report attachments, screenshots, traces, and videos. These artifacts can contain cookies, headers, form values, customer records, or internal endpoints even when the source code looks safe. Use synthetic names, addresses, and orders.

Set the editor to a readable theme, hide the minimap if it compresses code, increase terminal and editor text, and collapse irrelevant sidebars. Keep only the test, terminal, application, report, and one strategy page open. Set browser zoom so headings and results remain readable in a typical embedded player.

Verify the step: make a ten-second test capture and inspect every corner at normal playback size. Confirm there are no names, notifications, bookmarks, tokens, private paths, clipped windows, tiny text, or cursor highlights over sensitive content.

Step 5: Configure and Capture Clear Video and Audio

In OBS, create one display or window capture scene at 1920 by 1080. Record at 30 frames per second because code, terminals, and reports do not need gaming frame rates. Use the built-in hardware encoder when available, save locally as MKV for crash resilience, then remux to MP4 from OBS after recording.

Use these practical settings as a starting point:

Run a short audio test. Put the microphone a consistent hand span from your mouth, speak across it to reduce plosives, and remove fan or keyboard noise where practical. Do not add music under technical narration. It competes with speech and can create licensing problems.

Record scenes in the planned order. When you make a mistake, pause for two seconds, repeat the full sentence, and continue. That silence creates an obvious edit point. Keep the cursor still while explaining and move it deliberately when directing attention.

Show real execution. You may shorten installation and test waiting time in editing, but label any time compression. Never splice output from a different commit while implying it came from the visible run.

Verify the step: play the raw recording with headphones and then laptop speakers. Speech should be clear, terminal output readable, cursor movement calm, and the beginning and end of each scene intact. Confirm the file opens after remuxing.

Step 6: Demonstrate a Controlled Failure and Diagnosis

A green run shows execution. A controlled failure shows investigation. Change one expected value on a temporary local branch, or use a test fixture designed to produce a known mismatch. Do not break the public default branch.

Create a branch and edit the final expectation from $79.00 to $78.00:

git switch -c demo/controlled-failure
npm run test:demo

The expected terminal output should identify the failed assertion and show a nonzero test result. Open the report:

npm run report

In the video, show the expected and received values, the failing line, and one artifact such as the trace timeline or screenshot. Explain the diagnosis: the application displayed $79.00, but the temporary assertion expected $78.00, so this is a deliberately introduced test expectation defect, not an application defect.

Then restore the correct expectation with your editor and rerun the tagged test. Keep the branch unpushed or delete it after capture. Do not manufacture a product bug and claim that your suite discovered it. Label the exercise as controlled.

Use the failure to demonstrate a repeatable method: read the assertion, inspect the page state, compare the data source, decide whether the product, test, environment, or data is wrong, then rerun after the smallest justified change.

Verify the step: the recording must show the nonzero result, the relevant artifact, your diagnosis, the correction, and a passing rerun. Check git diff afterward to confirm that no accidental failure remains.

Step 7: Edit, Caption, and Package the Evidence

Cut long waits, false starts, private frames, and repeated explanations. Preserve enough context that viewers can tell which command produced the result. Use simple cuts and brief text labels such as Controlled failure or 2x speed during test startup. Avoid animated intros and visual effects.

Generate captions with your editor or a transcription tool, then review every testing term, command, filename, and product name. Automatic captions commonly mishear Playwright, locator names, and acronyms. Export WebVTT when your host accepts a caption file:

WEBVTT

00:00:00.000 --> 00:00:04.500
This project verifies the cart total with a Playwright test.

00:00:04.500 --> 00:00:09.000
I will show a passing run and diagnose a controlled failure.

Add a final frame with the repository URL, but also place a clickable link in the description. On-screen URLs are difficult to copy. Export 1080p MP4 using H.264 video and AAC audio for broad compatibility. Let the editor choose a sensible quality preset instead of forcing an extreme bitrate.

Watch the entire export rather than trusting the timeline preview. Editing can create silent sections, frozen frames, caption drift, or a private frame at a cut boundary.

Verify the step: play the exported file from start to finish with captions on and audio muted. Then play it with captions off. Both paths should communicate the main story, all commands should be legible, and no edit should misrepresent the run.

Step 8: Publish After You Record Test Automation Portfolio Demo Video Evidence

Upload the video as unlisted or public according to your portfolio plan. An unlisted video is often sufficient when you want anyone with the link to view it without making it broadly discoverable. Do not use a privacy setting that requires the recruiter to request access.

Use a descriptive title such as Playwright QA Portfolio Demo: Cart Total Test and Failure Diagnosis. Add a concise description:

I demonstrate a risk-based Playwright check for cart total accuracy, run the tagged test, and diagnose a controlled assertion failure.

Repository: https://github.com/YOUR-USER/YOUR-REPO
Test strategy: https://github.com/YOUR-USER/YOUR-REPO/blob/main/docs/test-strategy.md
Published report: https://YOUR-USER.github.io/YOUR-REPO/

Scope note: The application and data are public portfolio fixtures. Payment and tax provider behavior are mocked.

Add a clean thumbnail with a short phrase such as Test, Fail, Diagnose. Do not fill it with tiny code. Place the video near the top of your README, portfolio page, and relevant job application materials. Link the detailed strategy and the live report so a technical reviewer can verify your claims.

Use the tutorial to document a QA portfolio test strategy case study, then deploy your test report portfolio with GitHub Pages. The three artifacts support different depths of review.

Verify the step: open the video URL in a signed-out browser and on a phone. Test playback, captions, description links, thumbnail, privacy, and audio. Ask another person to follow the repository link without instructions.

Troubleshooting

The test fails unpredictably during recording -> Stop recording and stabilize it. Seed data, remove shared state, run only the tagged test, avoid unreliable external services, and verify three clean runs before another take.

Code is unreadable after upload -> Record and export at 1080p, enlarge editor and terminal text, reduce sidebars, and avoid showing the full desktop when one window is enough. Test the host's processed version, not only the local file.

Audio has echo or keyboard noise -> Move closer to the microphone, lower input gain, use a softer room, and record narration separately if necessary. Apply light noise reduction, but avoid aggressive filters that distort speech.

The demo runs longer than five minutes -> Keep one risk, one representative test, one controlled failure, and one diagnosis. Move setup, architecture depth, and extra scenarios into the README or strategy.

The report exposes private data -> Do not publish or blur it as a first response. Regenerate the run with synthetic data, inspect attachments and traces, rotate any exposed credential, and remove sensitive files from accessible history.

The video link works only for you -> Test it signed out. Change the host setting to public or unlisted, confirm age and organization restrictions, and ensure linked repository and report pages also allow anonymous access.

Best Practices

• Lead with the tested risk and your contribution.
• Show one strong flow instead of shallow coverage of many files.
• Rehearse commands and narration, but keep your voice conversational.
• Use real output from the visible project and commit.
• Label controlled failures, mocks, edits, and time compression.
• Explain why you chose locators, layers, assertions, and artifacts.
• Keep text readable in an embedded player and on a phone.
• Provide reviewed captions and clickable evidence links.
• State limitations beside results.
• Keep the default branch runnable after recording.
• Recheck privacy inside reports, traces, videos, and browser chrome.
• Update or replace the video when commands and project behavior materially change.

Where To Go Next

Return to the complete QA portfolio and job search guide to connect the demo with your resume, LinkedIn profile, applications, and interview preparation.

Strengthen the evidence path by learning to write a QA GitHub project README recruiters can scan. Add your reasoning with a QA portfolio test strategy case study, and give reviewers live results when you publish a test report with GitHub Pages.

Practice the same four-minute explanation without screen sharing. In an interview, the repository may not load, but the risk, design decision, failure investigation, and limitation should still be clear. If you are positioning this project as part of a role change, connect the evidence to the skills in the guide to becoming a QA automation engineer.

Interview Questions and Answers

Q: What should a test automation portfolio demo prove?

It should prove that you can connect a product risk to a test, execute it reproducibly, interpret evidence, and explain limitations. Tool familiarity is useful, but the decisions and diagnosis reveal more engineering judgment.

Q: Why show a controlled failure?

A controlled failure lets you demonstrate how you read an assertion, inspect artifacts, classify the likely cause, and verify a correction. Label it clearly so you do not misrepresent it as a product defect.

Q: How do you keep a live demo reliable?

Use a tagged test, deterministic data, a known environment, committed dependencies, and short package scripts. Rehearse multiple clean runs and keep external systems outside the critical path.

Q: Which artifacts should appear in the video?

Show the representative source test, terminal result, HTML report, and one useful failure artifact. Link the README, strategy, full report, and CI workflow for deeper review.

Q: How do you protect sensitive information in a QA demo?

Use synthetic data and a clean browser profile, close private applications, and inspect source, output, reports, traces, screenshots, and video. Never type a secret on screen with the intention of blurring it later.

Q: How long should the demo be?

Three to five minutes is a useful target for one focused automation story. If it takes longer, move supporting detail into linked documentation instead of speeding through the narration.

Conclusion

To record test automation portfolio demo video evidence that earns attention, guide the viewer through one risk, one representative check, a real result, and a disciplined failure investigation. Make every claim visible, reproducible, or linked.

Publish the video only after checking privacy, captions, mobile readability, anonymous access, and repository stability. Then use it as the short front door to deeper evidence, not as a replacement for code, strategy, reports, and honest discussion of limitations.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Deploy a Test Report Portfolio on GitHub Pages
• Document a QA Portfolio Test Strategy Case Study
• Debug Java Test Automation Race Conditions: A Practical Guide
• How to Become a API Test Engineer in 2026
• How to Become a Performance Test Engineer in 2026
• How to Become a QA Automation Engineer in 2026