Software Quality Assurance and Testing Work in the United States: Evidence from 108 Current Vacancies

Software Quality Assurance and Testing Work in the United States: Evidence from 108 Current Vacancies

The report and its eight-file research archive are available at Zenodo DOI 10.5281/zenodo.22414216. Download the research report PDF.

Author: MTF Institute Research Team
Institution: MTF Institute
Publication date: 5 September 2026
Research institution report number: MTF-CF-RR-2026-09-05-30
DOI: 10.5281/zenodo.22414216
Research date: 5 September 2026
Geography: United States
Evidence source: internal normalized-evidence-v2.json, preserved in this pilot as byte-identical evidence/accepted-evidence-v1.json; the public archive contains only rights-limited derivatives
SHA-256: 17d8edb56e986f493539aba046b21e9d28fdc4e6b6a28557ef927fabbf240685

The public archive does not expose the full internal evidence file or its supporting snippets. Its rights-limited accepted-vacancies-v1.csv (SHA-256 ae0c43248b9b1212b3b725642b16f1062c872e072ec2f63c2ae7e689710d7e5a), vacancy-coding-evidence.json, and coding-summary.json are reduced derivatives generated from the reviewed source above. The public CSV shares a legacy filename with a separate internal analyst CSV (SHA-256 5d46bd6a032a2bf15cb400aae86aa8c4a0aaa6455704198a2a80302421a852bd) but differs in both schema and bytes; the two must not be treated as the same artifact.

Abstract

Software testing is sometimes presented as either a purely manual entry route or a branch of software engineering dominated by automation. A purposive review of 108 current United States software quality assurance vacancies shows why neither description is adequate on its own. The most visible practices in this sample were defect work, mentioned in 92 records; test-case or scenario work, 83; regression, 80; and automation, 79. Requirements or other test-basis analysis appeared in 45 records, acceptance or release evidence in 49, API testing in 44, and data testing in 31. Exploratory testing appeared explicitly in 31 records. These categories overlap and describe only this sample.

The role mix is demanding. Only one record met a conservative direct-entry manual or analyst signal. Nineteen were early-career but still contained education, experience, programming, or other technical filters; 22 were general or intermediate; and 66 were senior or automation-progression comparators. This evidence supports a beginner learning pathway built on manual analysis, reproducible evidence, defect communication, retest, and regression, followed by API, data, and automation literacy. It does not support promises of easy hiring, no technical learning, or universal access to QA roles.

The study uses 99 employer-controlled or first-party records and a separately disclosed nine-record fallback stratum. Direct U.S. occupational context from the Bureau of Labor Statistics and O*NET supports the distinct occupational identity of software QA analysis and testing, while also reinforcing its substantial preparation requirements. A direct review of 65 live MTF programmes found no exact duplicate, provided the proposed certificate remains bounded from Systems Analysis and Business Analysis. The learning design is feasible through original text, fictional cases, synthetic data, and original templates without reproducing protected standards, certification curricula, vendor interfaces, or employer expression.

1. Research question and scope

The primary question was: what testing responsibilities, technical progression signals, tools, and transferable skills are explicitly described in a current purposive sample of U.S. software QA vacancies, and what do those observations justify in a professional course?

The question is narrower than a labour-market census. The corpus does not estimate the total number of vacancies, the share of U.S. employers requesting a skill, how frequently a tester performs an activity, or the chance that a learner will be hired. It describes observable public vacancy language in one dated sample. The denominator for every vacancy finding is 108, and non-exclusive codes can appear together in the same record.

This distinction matters because the sample intentionally includes different points on a career path. Manual QA analysts, junior and associate roles, general test engineers, senior QA engineers, automation specialists, and software development engineers in test all contribute useful evidence, but they do not represent one interchangeable learner outcome. Senior requirements show where the work can progress. They must not be rewritten as beginner prerequisites or as proof that an introductory certificate confers advanced competence.

The course-design question is similarly bounded. The proposed Professional Certificate in Software Quality Assurance and Testing should teach a coherent tester workflow. It is not intended to replace a computer-science degree, an employer apprenticeship, a vendor certification, regulated validation training, a Business Analysis programme, or software-development preparation for advanced automation roles.

2. Methods

2.1 Sampling and eligibility

Researchers used public web search and readable employer, ATS, recruiter, and job-board pages on 5 September 2026. Search routes covered software QA, manual and functional testing, test engineering, user-acceptance testing, automation, and SDET work. A record qualified only when its readable description established substantive software-testing responsibility, a U.S. location or U.S. eligibility basis, and credible observable current-status evidence.

Manufacturing quality, hardware inspection, pure software development without material testing work, penetration testing, non-U.S. roles, expired pages, and snippet-only results were outside scope. Current public appearance is a limited observation: it cannot prove that budget, headcount, or hiring intent remained unchanged behind the page.

The four contributing collections supplied 130 raw records. Nineteen cross-source duplicates were removed, with one requisition counted once even when it appeared in multiple sources or locations. Three more records failed final eligibility: one employer page reported that the job no longer existed, one older board listing could not be reopened, and one remote role did not establish U.S. geography. The resulting corpus contains 108 records and 98 employer labels. Distinct requisitions at the same employer were retained; the largest employer cluster contains five records, or 4.6 percent of the sample.

2.2 Source provenance

Employer-controlled sourcing dominates the study. Forty-eight records came from one employer-controlled ATS collection, 26 from a first-party employer-ATS collection, and 25 from another employer-controlled or employer-ATS collection. Together these make 99 first-party or employer-controlled observations. One recruiter ATS record and eight substantive full-description board records form the nine-record fallback stratum.

Fallback evidence was not silently mixed with first-party evidence. Two board records were readable and exposed application controls but were about one year old, and one employer page contained a stale 2025 start reference. These records remain useful when their limitations are preserved, but they cannot carry broad claims about current entry access. Source strata are transparency devices, not statistical weights.

2.3 Coding and review

Twelve practice categories were coded from explicit wording: test basis or requirements, test cases, exploratory testing, defects, regression, acceptance evidence, API testing, data testing, automation, CI/CD, Agile collaboration, and risk or quality work. Positive codes required activity-specific support. Manual testing did not automatically mean exploratory testing; fix verification did not automatically mean regression; acceptance criteria did not automatically establish acceptance evidence; a tool name did not automatically establish automation or CI/CD.

Tools were normalized separately and classified by evidence level: named context, used in a duty, or required/named hard skill. Entry position was also separate from practice coding. Four mutually exclusive bands distinguished a strict direct-entry signal, early-career work with filters, general or intermediate work, and senior or automation progression.

An independent reviewer reopened 14 records across source routes and role bands, tested disputed codes and exclusions, and reconciled the record-level data with aggregate counts. The review found no unresolved deterministic issue in the frozen file. Its PASS applies only to the SHA-256 printed above; changing the evidence would require a new freeze and review.

3. Findings

3.1 A workflow organized around evidence

The sample does not reduce software testing to the act of clicking through screens. Its strongest pattern is the construction of defensible evidence across a change lifecycle.

Practice coded from vacancy descriptions	Records	Share of the 108-record sample
Defects	92	85.2%
Test cases, scenarios, scripts, procedures, data, or traceability	83	76.9%
Regression, smoke, sanity, release, or change-impact suites	80	74.1%
Automation scripting or framework maintenance	79	73.1%
Risk, quality strategy, non-functional quality, or coverage decisions	55	50.9%
Acceptance, release-readiness, quality-gate, or results evidence	49	45.4%
Test-basis or requirements interpretation	45	41.7%
API or service testing	44	40.7%
Exploratory, ad hoc, investigative, or session-based testing	31	28.7%
Data, database, SQL, ETL, or data-quality testing	31	28.7%
CI/CD, pipelines, builds, or test integration	25	23.1%
Explicit iterative-delivery collaboration	11	10.2%

These shares are arithmetic descriptions of the corpus, not estimates for the United States. A category's absence means only that the retained vacancy description did not explicitly support it.

Defect work was the most common code. In practical terms, this means observing a difference between expected and actual behaviour, isolating reproducible conditions, recording useful evidence, communicating impact without exaggeration, following resolution, and verifying a change. The 92-record count supports defect communication as a central learner capability rather than an administrative afterthought.

Test cases and regression were also prominent. Designed cases appeared in 83 records, and regression-related work appeared in 80. Together they support a course sequence in which learners translate a supplied basis into purposeful coverage, record expected results, execute with controlled data, and decide what should be rechecked when software changes. A test case is not valuable merely because a field is populated; it is valuable when another person can understand its purpose, reproduce the setup, and interpret the observed result.

Exploratory testing was explicit in 31 records. That lower count does not make it optional trivia. It shows that exploratory work should be taught accurately as a disciplined complement to prepared checks, without claiming that every vacancy names it. Learners can practise a time-boxed session with a focus, notes, observations, questions, and a clear distinction between an idea and an executed result.

Acceptance evidence appeared in 49 records. The boundary is important: testers can organize evidence, identify unresolved risk, and provide a bounded completion recommendation. Product or business owners decide acceptance; engineering and operational owners decide release; accountable risk owners accept residual risk. The tester's report supports those decisions but does not replace their authority.

3.2 Manual foundations coexist with automation

Automation appeared in 79 records, and 24 records were specifically coded as automation-heavy. That is a strong signal for progression. It is not a reason to erase manual practice from the entry layer.

The same corpus contains extensive case, defect, regression, basis, and acceptance work. Automated checking still depends on deciding what matters, selecting observations, recognizing ambiguous requirements, creating useful data, explaining failures, and separating a product defect from a test or environment problem. These decisions can be learned through original text and guided practice before a learner writes a full automation framework.

A defensible course therefore needs two connected layers. The first builds manual testing judgement: test basis review, coverage, cases, exploratory sessions, defect evidence, retest, regression, and completion reporting. The second develops technical literacy: inspecting an API request and response, validating data with a simple query concept, reading a small test script, understanding where tests sit in a delivery pipeline, and collaborating with automation specialists. Advanced framework design, production-grade software engineering, and pipeline administration belong to progression rather than the beginner promise.

This is a more credible pathway than describing testing as “no-code.” One record in the sample met the strict direct-entry manual or analyst signal. That record still asked for relevant SaaS support experience. Nineteen early-career records contained some combination of experience, education, programming, or technical filters. Sixty-six of the 108 records were senior or automation-progression comparators. The evidence supports a clear place to start learning, not a claim that the market has removed its entry barriers.

3.3 API, data, and delivery-system literacy

API testing appeared in 44 records and data testing in 31. These counts justify meaningful exposure because many product behaviours are not fully visible through a user interface. A learner should understand how to compare a request with a response, recognize status and payload evidence, vary inputs, distinguish test data from live personal data, and document an unexpected service result. Similarly, data-checking practice can cover identifiers, state transitions, completeness, uniqueness, and simple SQL-style reasoning without turning the course into database administration.

CI/CD appeared in 25 records, a smaller but material progression signal. The curriculum can explain what changes when tests run repeatedly in a pipeline: results need stable setup, clear pass criteria, useful failure information, and responsible ownership. It should not imply that naming Azure DevOps, Jenkins, or GitHub Actions proves pipeline expertise. The coding protocol deliberately kept those concepts apart.

Risk and quality decisions appeared in 55 records. That supports prioritizing coverage rather than treating all scenarios as equally important. In a fictional ordinary web application, learners can consider user impact, change size, data sensitivity, failure detectability, and recent defect patterns. They should state assumptions and preserve uncertainty. They should not make legal compliance, regulated safety, or production-release claims.

3.4 Tools are evidence, not the curriculum architecture

SQL and Playwright were each named in 31 records; Selenium in 29; Jira in 24; Cypress and Postman in 18 each; Azure DevOps in 17; and Jenkins in 15. Other normalized names included GitHub Actions, Git, GitLab, pytest, TestRail, TestNG, Appium, Xray, JUnit, Bitbucket, BrowserStack, and Cucumber.

Raw mention order should not become lesson order. For most frameworks, the description merely placed the name in context. SQL was more often expressed as a required or named hard skill than many UI frameworks, while a few products were tied directly to duties. This distinction argues for tool-neutral methods first: define an observation, preserve setup and evidence, compare actual with expected, classify a failure, and make a bounded decision. A current tool can then demonstrate the method without becoming the credential's identity.

Official documentation for Playwright, Cypress, Selenium, and Postman showed active capabilities or maintenance at the study date. That confirms they are plausible examples. It does not prove U.S. prevalence, beginner suitability, or endorsement. Version-specific walkthroughs also age quickly, so a durable course should emphasize decisions and direct learners to current official documentation for optional extension.

3.5 Communication is part of test quality

Explicit soft-skill evidence reinforces the same theme. Communication appeared in 78 records, collaboration in 69, analytical and critical thinking in 53, attention to detail in 31, adaptability and learning in 26, initiative and ownership in 25, organization and time management in 18, and user or customer empathy in five.

These counts are not psychometric rankings. They show what employers chose to state in this sample. They also explain why a useful defect report is more than a technical log. A tester has to present observable facts, make reproduction practical, separate impact from speculation, listen to alternative explanations, and help a team decide what to investigate next. An original course artifact can assess those behaviours directly through clarity, traceability, evidence quality, and revision after peer challenge.

4. U.S. occupational context and entry nuance

The U.S. Bureau of Labor Statistics identifies Software Quality Assurance Analysts and Testers as a distinct occupation. In the occupation-specific row of its employment-projections table, last modified 27 August 2026, BLS reports about 187,600 jobs in 2025 and projects 6 percent growth from 2025 to 2035. Its occupational description covers planning, manual and automated execution, exploratory work, defect reporting, and feedback about usability and functionality. These figures provide national occupational context; they are not derived from the 108 vacancies and do not measure demand for an MTF course. The combined developer, QA-analyst, and tester headline grows 10 percent, but that combined rate is not used here as the QA-specific outlook.

BLS also reports a bachelor's degree as the typical entry-level education for the broader occupational page. The O*NET® profile, updated in 2026, places the occupation in Job Zone Four and includes programming among transferable skills. Its task inventory adds regression and negative testing, retesting, usability work, bug-resolution monitoring, release-readiness methods, and coordination of user or third-party testing.

O*NET also records varied education responses and links the occupation to a registered-apprenticeship route. Those observations show that one pathway does not fit everyone. They do not prove that an apprenticeship is open in every state, that a certificate substitutes for a degree, or that a learner with no prior preparation will meet vacancy requirements.

The most accurate promise is therefore an understandable entry pathway into the practice. A learner can begin with a bounded test basis, develop manual evidence, and build technical literacy without first becoming a professional software developer. The market-facing qualification claim must remain modest: different employers impose different experience, education, domain, coding, location, clearance, and tooling filters.

5. Professional-learning context

Public learning marketplaces add context but not labour-market proof. On the study date, a Microsoft professional certificate page on Coursera described a beginner programme and displayed 1,895 enrolled learners. Two Udemy pages describing beginner manual testing displayed 12,072 and 20,111 students. These figures are global, dynamic, seller- or platform-controlled snapshots. They indicate visible interest in structured learning; they do not establish U.S. willingness to pay, course quality, employer recognition, placement, sales, or revenue.

A publisher-sponsored TestRail survey also described manual functional, regression, exploratory, integration, end-to-end, smoke, and user-acceptance work alongside automation. Because the public report did not establish a U.S.-representative design, none of its percentages is used as U.S. evidence. Its appropriate role is limited comparison, not curriculum prioritization.

6. From evidence to an original learning design

The evidence supports a connected fictional case rather than disconnected definitions. Consider an ordinary appointment-booking web application preparing a small change to rescheduling rules. Learners receive a short original product note, a supplied list of constraints, and synthetic appointments. They first identify ambiguity and testable statements. They then build a compact coverage map across user paths, data states, boundaries, and risks.

Next, learners write a small set of executable manual cases and a charter for a time-boxed exploratory session. They record actual observations rather than inventing results. When a failure appears, they create an original defect record with environment, setup, action, observed behaviour, expected basis, impact, evidence, and uncertainty. After a fictional fix, they plan retest and choose a regression set based on the change. They finish with an evidence index and a bounded recommendation that distinguishes completed checks, unresolved questions, open defects, excluded scope, and ownership of the final acceptance decision.

This workflow can be taught completely through original prose, synthetic data, authored diagrams or tables, and original templates. It does not require reproduction of a standard, certification glossary, employer description, vendor screenshot, commercial course, or licensed framework. Product names can appear descriptively in an optional technical-literacy layer, but no named tool should be necessary to understand the core method.

AI can help organize supplied fictional facts, propose coverage questions, critique the clarity of a defect, or compare an artifact with an original checklist. It cannot serve as execution evidence. A model must not invent a test result, fabricate a screenshot or log, infer that a defect was fixed, determine compliance, or authorize acceptance and release. Human observation and verification remain the source of operational evidence.

7. MTF portfolio position

A same-day public review found 65 live MTF programmes and no exact Software Quality Assurance and Testing certificate. The candidate is distinct only if its ownership boundaries remain visible.

The closest comparator is IT Systems Analysis: Process, Data, Interfaces and Solution Validation. Systems Analysis owns the system boundary, process and data meaning, interface behaviour, requirements coherence, solution choices, cutover, and broad validation design. The testing course should begin with a supplied or explicitly incomplete test basis and go deeper into tester-owned coverage, execution, observations, reproducibility, defect lifecycle, retest, regression, and evidence quality. It should not reuse the existing artifact identities “Integration and Data Test Pack” or “Acceptance Evidence and Defect Review Pack.”

The second critical comparator is Professional Certificate in Business Analysis (PCBA). Business Analysis owns problem framing, stakeholder elicitation, scope, requirements architecture, user stories, acceptance-criteria authorship, backlog, and change control. Testers may question and trace supplied requirements, but the new programme must not turn elicitation or product-scope ownership into its central workflow. The tester supplies evidence; authorized business or product owners decide acceptance.

Project Management owns delivery governance rather than detailed tester craft. IT Support owns incident response and service restoration rather than planned behaviour evaluation around a change. Cybersecurity GRC owns governance and control evidence, not ordinary functional QA. With those lines enforced, the course complements rather than materially duplicates the live portfolio.

8. Rights, marks, and high-stakes boundaries

Public access is not treated as permission to copy. Vacancy pages support factual coding and concise original analysis; they do not supply lesson prose. Marketplace curricula, vendor documentation, certification materials, and survey publications remain source-controlled. The course must use original explanations, cases, test data, checklists, templates, prompts, and worked examples.

BLS occupational facts can be cited as U.S. government context, while BLS imagery, logos, and emblems remain excluded. Reuse of ONET 31.0 database content requires CC BY 4.0 attribution, a licence link, a modification notice, and accurate ONET® trademark treatment. Jira, Postman, Playwright, Cypress, Selenium, Microsoft, Scrum, ISTQB®, CTFL®, and other names may be used only when factually necessary and descriptively. They must stay out of the course title, credential identity, slug, badge, cover art, and primary promise. No logo, interface screenshot, trade dress, endorsement, partnership, or recognition claim is permitted.

ISTQB syllabi, glossary definitions, learning-objective structures, exam formats, sample questions, diagrams, and credential claims are excluded unless a separate future clearance explicitly supports a precise use. The MTF course must not be described as ISTQB-aligned, CTFL preparation, accredited, approved, recognized, or equivalent.

Practice should use fictional, non-regulated software and synthetic data. Medical devices, aviation, automotive safety, industrial control, defence, and regulated financial transaction systems are inappropriate teaching contexts for a general entry pathway. Penetration testing, live credentials, personal or health data, proprietary source code, production logs, legal compliance conclusions, audit opinions, and accessibility-conformance claims are also outside scope. Learners may document an observable concern and route it to an authorized specialist; they may not certify a control, accept risk, approve a regulated system, or authorize release.

9. Limitations

The sample is purposive and shaped by discoverability, public ATS behaviour, readable pages, and the selected searches. It is not a random sample and has no sampling error suitable for national inference. Source families, industries, seniority, locations, and employers are uneven. Record codes capture explicit language, so they understate activities that employers assumed but did not name.

The independent audit reopened a spread of 14 records rather than independently recoding all 108. No inter-rater statistic is available. Some dynamic pages were readable only through current indexed employer renderings, while lower-confidence board pages can lag an employer's actual status. All observations can age after 5 September 2026.

The occupational and learning-intent sources answer different questions. BLS and O*NET provide national occupational context but not course demand. Marketplaces show public participation signals but not U.S. demand or outcomes. Vendor documentation establishes capability, not hiring frequency. The live MTF catalogue establishes a dated public portfolio view, not the contents of unpublished records.

10. Conclusion

The 108-record sample supports a course organized around the quality of evidence: understanding a supplied basis, designing purposeful coverage, executing and exploring carefully, reporting defects reproducibly, retesting changes, selecting regression, and communicating a bounded completion recommendation. API, data, automation, and delivery-pipeline literacy are material extensions, not substitutes for judgement.

The evidence also requires honesty about access. A manual foundation is teachable without first turning the learner into a software developer, but the sampled market is not broadly no-code or frictionless. Only one record met the strict direct-entry signal, and most of the corpus represents intermediate, senior, or technically filtered work. The educational promise should be practical capability and a clear progression route—not hiring, recognition, or advanced-engineering equivalence.

Within the 65-programme MTF catalogue, the candidate is defensible if Business Analysis retains requirements ownership, Systems Analysis retains solution and broad validation design, and Software QA and Testing owns the detailed test-analysis-to-evidence workflow. Original text-only production is feasible under the stated rights, mark, privacy, and high-stakes controls.

Rights statement

Copyright © 2026 MTF Institute. Except for third-party material, this report and its original analysis are licensed under the Creative Commons Attribution 4.0 International licence. This report contains original analysis and paraphrase. It does not reproduce vacancy descriptions, marketplace curricula, standards, certification syllabi, vendor documentation examples, logos, screenshots, or proprietary frameworks. Third-party names identify sources or technologies descriptively and do not imply endorsement, affiliation, accreditation, recognition, or approval. ONET® occupational information is attributed to the ONET 31.0 Database of the U.S. Department of Labor, Employment and Training Administration, under CC BY 4.0; the source observations are paraphrased and reorganized here. O*NET® is a trademark of USDOL/ETA. The licence does not relicense linked pages, employer marks or other third-party material. This report is educational research, not legal advice, a regulatory opinion, or an employment guarantee.

Continue learning

Apply the evidence from this report through MTF Institute's Professional Certificate in Software Quality Assurance and Testing. The programme turns the identified capabilities into structured theory, guided AI practice and reusable workplace artifacts.