What do software quality analysts do? The real role, explained
Most people picture a tester clicking through screens the night before a release. The real job starts weeks earlier, with a question about a requirement that nobody else thought to ask.
What do software quality analysts do?#
A software quality analyst checks that software does what its users need, by questioning requirements early, aiming tests at the riskiest parts and telling the team whether a release is ready. The US Bureau of Labor Statistics (BLS) describes the occupation in its Occupational Outlook Handbook, read on 8 October 2026 and updated with May 2025 data. In its words, analysts and testers "design and execute software tests to identify problems and learn how the software works." That second half matters. However, running tests is only the visible part of the job.
Most of the value comes before a single test runs. A question about a requirement costs a short talk. But the same flaw found later can cost a rebuild. NIST's Planning Report 02-3 made the point in May 2002. It says that "regardless of when an error is introduced it is always more costly to fix it downstream in the development process." In short, software quality analysts find the flaw early and report it in words a team can act on.
What is a quality analyst, by the official definition?#
The US Bureau of Labor Statistics Occupational Outlook Handbook, read in October 2026, describes the job as designing and running software tests to find problems and learn how the software works. The handbook then lists the typical duties. First, analysts create test plans, scenarios and procedures for new software. Second, they identify project risks and recommend steps to reduce them. Then they run manual, automated or exploratory tests and judge the results. Finally, they report defects and give feedback on usability and functionality.
Create test plans, scenarios and procedures
Analysts plan how new software will be tested before the testing starts.
Identify project risks and reduce them
They name the project risks and recommend steps to reduce each one.
Run tests and judge the results
They run manual, automated or exploratory tests and judge what the results mean.
Report defects and give feedback
They report defects and give feedback on usability and functionality.
Notice what that list leaves out. Yet it never says the job starts when coding ends. Because risks and test plans come first, a quality analyst belongs on the team from the first story. Also, the same BLS entry groups analysts and testers into one occupation. So job sites use the two titles loosely, and some shorten the role to software analyst.
What does a quality analyst notice that others miss?#
A quality analyst notices the gap between what a requirement says and what a user will actually do, the place where a developer stops looking because the main path works. Developers test the path they built. Meanwhile, a scripted check repeats the steps it was given. An analyst asks what happens off that path, and the attention lands on four kinds of thing.
- Ambiguity. A requirement two people could read two ways, such as letting a user cancel an order. It says nothing about orders already shipped.
- Edge cases. An empty field, the last day of a short month, a name with an apostrophe, or a slow network.
- Unspecified paths. The back button during payment, a second browser tab, or a session that expires at checkout.
- The user's side. ISO/IEC 25010 calls this interaction capability. It includes user error protection, which is how well a system stops users from making mistakes.
| Kind of thing | What the analyst asks about |
|---|---|
| Ambiguity | Letting a user cancel an order: what about orders already shipped? |
| Edge cases | An empty field, the last day of a short month, a name with an apostrophe, a slow network |
| Unspecified paths | The back button during payment, a second browser tab, a session that expires at checkout |
| The user's side | User error protection: how well a system stops users from making mistakes |
In practice, the BLS duty to identify project risks is the formal name for this habit. Also, none of it reaches a test script until someone has noticed it first.
What quality does an analyst check against?#
The ISO/IEC 25010:2023 product quality model gives an analyst a checklist that runs from functional suitability and reliability to security, flexibility and safety, far beyond whether a feature works. In November 2023, the International Organization for Standardization published this second edition. The iso25000.com summary lists its nine characteristics. They are functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety.
In turn, each one splits into parts an analyst can test. For example, functional suitability covers completeness, correctness and appropriateness. Performance efficiency covers time behaviour, resource use and capacity. So the question changes. It is no longer whether a feature works, but whether it works for the right people, fast enough and safely. Because the parts have names, a team can agree before a release which ones matter most. As a result, a test plan stops being a pile of cases and becomes a map of risks.
Why is software quality important?#
NIST Planning Report 02-3, published in May 2002, puts the yearly cost of inadequate software testing infrastructure to the US economy at $22.2 billion to $59.5 billion. The same NIST report adds that "Over half of these costs are borne by software users" through work to avoid and recover from errors. The rest falls on developers as extra testing effort.
In NIST's own breakdown, the total yearly cost is $59.5 billion. Of that, feasible testing improvements could remove $22.2 billion, both in 2002 dollars.
$59.5 billion
Yearly cost of inadequate testing infrastructure
$22.2 billion
Cost reduction from feasible improvements
Of a $59.5 billion yearly cost, NIST estimates feasible testing improvements could remove $22.2 billion.
| Option | billion US dollars a year, 2002 dollars |
|---|---|
| Yearly cost of inadequate testing infrastructure | $59.5 billion |
| Cost reduction from feasible improvements | $22.2 billion |
In short, poor quality is not a private problem for the team that ships it. Instead, it moves onto the people who use the software every day.
Why does a defect cost more the later it is found?#
NIST Planning Report 02-3, published in May 2002, puts the relative cost of fixing a requirements flaw at 1X when caught at requirements and 30X after release. In the same NIST table, the cost climbs at every handoff in between. So no stage is a cheap place to wait.
Show data table
| Item | Value |
|---|---|
| Requirements and design | 1 |
| Coding and unit test | 5 |
| Integration and system test | 10 |
| Early customer feedback and beta | 15 |
| Post-product release | 30 |
In NIST's example, a flaw found after release costs 30 times what it costs at requirements.
The reason is plain. For example, a flaw found in a requirement is fixed by changing a sentence. After release, the same flaw means code changes, more tests and a new deploy. It can also mean support calls and data repair. NIST presents the table as an example, so treat the multipliers as a shape rather than a law. Still, that shape is why an analyst works upstream. The earliest question is the cheapest fix.
What does a late defect cost in dollars?#
In this worked example, one analyst hour at the O*NET median wage of $50.14 for May 2025 grows to $1,504.20 when the same flaw is found after release.
O*NET OnLine is the US Department of Labor's occupation database. It lists that 2025 median for software quality assurance analysts and testers. Here it is only a labour statistic, used to put the NIST May 2002 multipliers into money.
Say one flaw takes one hour to fix at requirements, at that median wage and on that ladder. Say it slips instead: it then costs $250.70 in coding, $501.40 in system test, $752.10 in beta and $1,504.20 after release. For instance, a flaw that takes three hours at requirements would take 90 hours after release.
| Phase caught | Source stage | Relative cost | Cost to repair |
|---|---|---|---|
| Requirements | Requirements Gathering and Analysis/Architectural Design | 1x | $50.14 |
| Coding | Coding/Unit Test | 5x | $250.70 |
| System test | Integration and Component/RAISE System Test | 10x | $501.40 |
| Beta | Early Customer Feedback/Beta Test Programs | 15x | $752.10 |
| Post-release (selected) | Post-product Release | 30x | $1,504.20 |
The escalation rule: the cost to repair a defect climbs with every phase it survives. A flaw caught in a requirements conversation costs about one unit. The same flaw found after release costs 30 units in NIST Planning Report 02-3, Table 5-1, which the report marks Example Only, and that counts rework alone. That gap, not the bug report, is the analyst's real product.
What does a QA analyst do day to day?#
A QA analyst's day moves with the release: reviewing stories before code, planning tests around risk, exploring builds, reporting defects and checking fixes after every deploy. Before code, the analyst reads each story and asks what its acceptance criteria leave out. While code is written, they plan tests around the riskiest areas and prepare test data.
When a build lands, they explore it and run the planned checks. Then they write defect reports with clear steps to reproduce. Also, they join triage to help decide which defects block the release. After release the work goes on. The BLS handbook says analysts and testers "run manual and automated checks to look for errors and usability problems once the software is released and after any upgrades or maintenance." So the test run everyone pictures is one slice of the week.
Review each story before code
The analyst reads each story and asks what its acceptance criteria leave out.
Plan tests around the riskiest areas
While code is written, they plan tests around risk and prepare test data.
Explore the build and run checks
When a build lands, they explore it and run the planned checks.
Report defects and join triage
They write defect reports with clear steps to reproduce, then help decide which defects block the release.
Check again after release
They run manual and automated checks after release and after any upgrades or maintenance.
How is a QA analyst different from a software tester?#
A software tester mostly runs and reports tests, a QA analyst decides what to test and why from requirements and risk, and an automation specialist builds the scripts both rely on. The BLS counts all of them as one occupation. So employers draw the line, not a standard. Therefore the useful test is to ask who owns which question.
In short, the analyst owns what to test and why. The tester owns running it well and reporting it clearly. Meanwhile, the automation specialist owns the code that runs checks without a person watching. On a small team, one person often wears all three hats. So when a job ad says tester but asks for risk analysis, it describes an analyst.
| Role | Owns | Typical work |
|---|---|---|
| QA analyst | What to test and why | Decides what to test from requirements and risk |
| Software tester | Running tests well and reporting them clearly | Runs and reports tests |
| Automation specialist | The code that runs checks without a person watching | Builds the scripts both rely on |
What skills does a software quality analyst need?#
The ISTQB Certified Tester Foundation Level v4.0 exam, as ISTQB lists it in October 2026, has 40 questions and a pass mark of 26, and it is the usual first credential. ISTQB is the International Software Testing Qualifications Board. Its CTFL v4.0 page, read on 8 October 2026, says the certificate suits testers, test analysts, test managers and software developers. It also names business analysts and project managers.
Still, the skills behind it are practical. O*NET OnLine lists reading comprehension and critical thinking among the essential skills for the occupation. In daily terms, that means reading a requirement for what it leaves out. It means judging which risks matter most. And it means writing a defect report a developer can reproduce on the first try. Finally, enough database and scripting knowledge to check data yourself saves hours of waiting.
Read a requirement for what it leaves out
Reading comprehension, in O*NET terms, applied to stories and acceptance criteria.
Judge which risks matter most
Critical thinking decides where the testing effort goes first.
Write defect reports developers can reproduce
A developer should reproduce the defect on the first try.
Script enough to check data yourself
Database and scripting knowledge saves hours of waiting on someone else.
Sit the ISTQB CTFL v4.0 exam
The usual first credential: 40 questions and a pass mark of 26.
What do software quality analysts earn?#
The US Bureau of Labor Statistics lists a median annual wage of $104,300 for software quality assurance analysts and testers in May 2025. In the same BLS May 2025 data, the lowest tenth earned less than $61,440. The highest tenth earned more than $167,010.
Show data table
| Item | Value |
|---|---|
| Lowest 10 percent earned less than | 61,440 |
| Median | 104,300 |
| Highest 10 percent earned more than | 167,010 |
The median software quality assurance analyst or tester earned $104,300 a year in May 2025.
These are pay statistics for employees in the US occupation, not what any service costs. However, pay also varies by industry and state. The BLS publishes those breakdowns beside the national figure.
Is software quality analysis a growing career?#
The US Bureau of Labor Statistics counts about 187,600 software quality assurance analysts and testers in 2025 and projects 198,200 jobs by 2035. In the BLS projection for 2025 to 2035, that is growth of about 6%.
| Occupation | Jobs in 2025 | Projected jobs in 2035 |
|---|---|---|
| Software quality assurance analysts and testers | 187,600 | 198,200 |
The handbook links part of the demand to security. Organisations that invest in protective software need analysts and testers "to create and execute software tests." Automation does change how checks run. However, the questions about risk and requirements still need a person to ask them.
When is a dedicated quality analyst not a fit?#
A dedicated quality analyst is not a fit for a throwaway prototype or a small team shipping low-risk changes, where developers testing their own work with a checklist is enough. Here are three cases, each with a better tool.
- A prototype you expect to throw away. Instead of an analyst, show it to a few real users. Then keep a short list of what to retest if it survives.
- A small team shipping small, reversible changes. Use developer testing plus a shared release checklist. Build it from the ISO/IEC 25010 characteristics that matter to your product.
- A team whose only gap is a slow regression suite. That is an automation problem. So invest in faster automated checks before adding analysis.
The NIST ladder is the deciding test. If a flaw that escapes would cost users far more than the time spent looking for it, the role pays for itself.
Where should you go from here?#
If the role sounds like the missing piece, the next steps are writing clearer test cases, exploring builds on purpose and learning how a reported defect gets triaged. Start with writing clear and effective test cases. Then try exploratory testing with Rapid Reporter. For usability checks, read about heuristic evaluation and cognitive walkthroughs.
After a defect is reported, bug triage discussions decide what happens next. The psychology of bugs explains why authors miss their own. If your team wants an analyst on a project, see hiring QA specialists. For a build with quality planned from requirements, see custom software development. Otherwise, the BLS handbook, the ISTQB syllabus and the ISO/IEC 25010 model are enough on their own to start.