October 15, 2026
A QA automation portfolio in 2026 needs to show that you can design reliable tests, maintain them as the application changes, and integrate them into a delivery pipeline — not just that you can write a passing test. Hiring managers in senior QA and SDET roles evaluate portfolios differently from how candidates build them: the candidate optimizes for tool count and test volume; the hiring manager looks for evidence of judgment, maintainability, and system thinking.
This guide covers the projects worth building, what to include in each one, how to present them, and the specific proof points that distinguish candidates who can own an automation suite from those who know the syntax of a framework. For teams looking to bring QA capability in-house, Astaqc’s hire a QA team page describes how we staff and onboard QA engineers at different automation maturity levels. The complete software testing guide provides the conceptual foundation for the practices covered here.
The most common portfolio mistake in QA automation is showcasing what the candidate learned, not what the candidate can do in production. A portfolio that lists five frameworks with three tests each signals breadth of exposure but not depth of execution. A portfolio that shows one framework used to build a real test suite — with evidence of maintenance decisions, flakiness handling, and CI/CD integration — signals the kind of judgment a team actually needs.
Hiring managers evaluate three things: whether the candidate understands the problem before reaching for a tool, whether the tests in the portfolio would survive a real application changing around them, and whether the candidate can articulate the tradeoffs of the choices they made. A portfolio that includes only passing tests, with no documentation of failures encountered, baselines revised, or coverage decisions made, raises the question of whether the candidate has worked on a live system or only on controlled exercises.
The best QA automation portfolio projects share three qualities: they are based on a real or realistic application (not a trivial todo app), they include test maintenance evidence (not just test creation), and they show integration with a workflow beyond running tests locally on demand.
Open-source application test suite. Choose an open-source web application — a project management tool, an e-commerce application, or a CMS — and build a functional test suite against it using Playwright, Selenium, or Cypress. The project should include a page object model or an equivalent abstraction layer, at least one API-level test alongside the UI tests, and a documented decision about what is not covered and why. Commit the project to GitHub and keep a changelog that shows the tests breaking when the application updated and how you fixed them. Evidence of maintenance is more valuable than initial coverage.
CI/CD-integrated test pipeline. Set up a GitHub Actions or GitLab CI pipeline that runs your test suite on every pull request to the repository. Include a badge in the README showing the test status. Document the pipeline configuration decisions: whether tests run in parallel, how failures are reported, and how flaky tests are handled. A pipeline that is visibly running in a public repository is a proof point that a hiring manager can verify directly rather than taking on faith.
API test collection with assertions beyond status codes. Build an API test collection using Postman, RestAssured, or similar tooling for a public API with a documented spec. Include schema validation, chained requests that use data from one response in the next request, and error condition testing. API test skills are increasingly valued as teams shift testing earlier in the development cycle, and many candidates with UI automation experience have not built structured API test coverage. Astaqc’s test automation services cover API, UI, and performance automation as part of a complete coverage strategy.
Performance baseline project. Run a load test against a public API or a locally hosted application using k6 or Locust. Document the baseline — response time at 10 concurrent users, at 100 concurrent users — and write a brief analysis of where the bottleneck appears. Performance testing is a distinct skill from functional automation, and including it in a portfolio demonstrates range. Astaqc’s performance testing page describes the types of performance assessments engineering teams typically need and the tools used for each.
The portfolio should be easy to navigate in ten minutes — the time a hiring manager typically spends evaluating a candidate’s technical work before a technical screen. Structure it around outcomes rather than tools: each project should have a clear statement of what application was tested, what coverage was built, what the CI/CD integration looks like, and what decisions were made about the scope.
A GitHub profile with one well-maintained repository is more effective than five repositories with stale branches. The README for each project is the interview on paper: it should explain what the project tests, how to run it, what the CI pipeline does, and one or two non-obvious decisions made during development. Hiring managers who interview QA candidates use the README to generate technical interview questions — candidates who write good READMEs get better interview questions, which gives them a better chance to demonstrate competence.
Include a brief case study or post-mortem for at least one project. This can be a section of the README or a separate document. Describe a test that broke when the application changed, how you diagnosed it, and how you fixed it. Describe a flaky test you encountered, its root cause, and whether you fixed it or documented it as an accepted risk. Real engineering work involves diagnosis and judgment; demonstrating both is what distinguishes a portfolio that shows growth from one that shows only initial capability.
For candidates applying to roles that require cross-functional collaboration, include brief documentation of how the test suite was designed to communicate with developers and product managers. A test that has a clear description of the business scenario it covers, references the acceptance criteria it validates, and explains the failure message when it fails is a much stronger signal of professional maturity than a test named test1 that runs a sequence of steps without explanation. The manual vs. automated testing guide covers how to communicate coverage decisions to stakeholders who do not write tests.
QA candidates often build portfolios around showing familiarity with as many tools as possible — Cypress, Playwright, Selenium, Appium, Postman, k6, TestRail, and more. This strategy signals exposure but not execution depth. A hiring manager looking for someone to own an automation suite is not looking for a candidate who has run the tutorial for every major framework; they are looking for someone who has used one or two frameworks deeply enough to make non-obvious decisions.
| Approach | What it signals | How to show it effectively |
|---|---|---|
| Deep on one UI framework (e.g., Playwright) | Can build and maintain a production test suite | Maintained repo with CI, page objects, documented tradeoffs |
| API testing in addition to UI | Understands the test pyramid; can cover more at lower cost | Postman collection or RestAssured project with chained requests and schema assertions |
| Performance testing awareness | Understands non-functional quality; not just functional pass/fail | k6 or Locust script with documented baseline and analysis |
| Familiarity with a no-code tool (e.g., TestInspector) | Can enable non-engineers to contribute to test coverage | Document a scenario where no-code tooling reduced bottleneck vs. code-first approach |
| Five frameworks at tutorial depth | Signals exploration, not execution capability | Replace with deeper investment in fewer tools |
The most effective portfolios show a primary automation skill at production depth and one or two adjacent skills at working depth — enough to demonstrate range without spreading so thin that no single competency is convincing. The adjacent skills most valued in 2026 are API testing (because teams are shifting test coverage left), CI/CD integration (because isolated test suites that run only locally are not useful), and accessibility testing (because WCAG compliance is increasingly a product requirement). Astaqc’s software testing services cover the full stack of automation types engineering teams need.
Two to three well-maintained projects are better than six shallow ones. A hiring manager evaluating a portfolio has limited time; a portfolio with two strong projects where each shows depth, maintenance history, and CI integration communicates competence more clearly than six projects that are each at the tutorial level. Prioritize the depth of each project over the count. If the portfolio includes multiple projects, the best-maintained project should be listed first.
The application matters less than what you did with the tests. A well-structured, maintained test suite against a todo application demonstrates more competence than a shallow suite against a complex application. That said, choosing an application with realistic complexity — authentication flows, multi-step workflows, API endpoints, dynamic content — gives you more opportunities to demonstrate real skills. Avoid testing a static website where there is nothing to break and nothing to maintain.
Including test results is valuable if the results include failures, fixes, and evidence of maintenance. A screenshot of passing tests in a CI pipeline is a positive signal; it becomes more valuable when the history shows tests failing, being diagnosed, and being corrected. A CI pipeline with a visible history — even if some runs show failures — demonstrates that the portfolio is from live work rather than a curated snapshot. Avoid portfolios that show only clean runs; they suggest the tests were written against a fixed application and never maintained through change.
If you are building a portfolio without professional experience, build it against open-source applications and document your process as carefully as your code. Join open-source projects and contribute test coverage to them — this gives you a public contribution history and the experience of testing a codebase you did not build. Contribute to test automation discussions in QA communities to demonstrate domain knowledge. The key differentiator for candidates without professional experience is the quality of their documentation and evidence that they understand why the tests are written the way they are. The outsource testing guide covers how QA knowledge is typically structured in professional teams, which is useful context for building a portfolio that matches professional expectations.
Including experience with AI-native QA tools signals awareness of where the automation market is moving. A portfolio that shows only traditional code-first frameworks suggests the candidate has not worked with the no-code and AI-assisted tools that many teams are adopting. Demonstrating TestInspector — or a comparable AI-native tool — alongside a code-first framework shows that the candidate can work in both models and can help a team decide which approach fits which scenario. The TestInspector page describes how AI-native no-code testing differs from traditional automation and what it enables for teams without dedicated automation engineers.
A QA automation portfolio focuses on test design, coverage decisions, defect detection, and system reliability — it demonstrates judgment about what to test, how to make tests maintainable, and how to integrate testing into a delivery workflow. A software engineering portfolio focuses on building features and systems. The overlap is in code quality, CI/CD integration, and debugging skill. QA portfolios that look like software engineering portfolios — optimized for code cleverness rather than test reliability and coverage — miss the specific evaluation criteria hiring managers use for QA roles: can this person own a test suite, not just write code that passes.
A QA automation portfolio that shows maintained tests, CI integration, and coverage decisions made under real constraints demonstrates more than a collection of frameworks ever can. Hiring managers are evaluating judgment, not syntax knowledge.
October 15, 2026
Sign up to receive and connect to our newsletter
We founded ASTAQC as a tight-knit group of professional Software Testers and software developers.
Subscribe to our Newsletter
