What this estimate does and does not do
This calculator estimates software quality assurance process effort, not product testing effort. In this context, SQA means activities such as process definition, training, standards, quality planning, process improvement, and auditing whether the team followed its defined process.
It does not estimate manual testing, automated test execution, system testing, defect fixing, test environment setup, or customer support. Many organisations call all of that “QA”, but the 5–6% rule used here is specifically about process SQA. Keep testing and bug fixing in separate planning buckets.
Formula used
SQA low = total project effort × low SQA %
SQA target = total project effort × target SQA %
SQA high = total project effort × high SQA %
process/training = SQA target × process split %
auditing/compliance = SQA target × (100% - process split %)
monthly SQA = SQA target / project duration months
SQA FTE = SQA target hours / (project months × FTE hours per month)If the input is a budget instead of hours, the calculator uses hourly loaded cost to estimate equivalent SQA hours and FTE.
Worked example
For a 10,000-hour software project using a 5.5% SQA target and an even 50/50 process/audit split:
SQA target = 10,000 × 5.5% = 550 hours
process/training = 550 × 50% = 275 hours
auditing/compliance = 550 × 50% = 275 hours
monthly SQA over 6 months = 550 / 6 = 91.7 hours/month
average SQA FTE = 550 / (6 × 160) = 0.57 FTEAt $100/hour loaded cost, the SQA target cost would be $55,000.
What belongs in the SQA bucket?
Typical process SQA work may include:
- creating the software quality assurance plan
- defining review, test, release, and change-control processes
- creating templates and checklists
- training the team on required processes
- auditing whether reviews, tests, traces, approvals, and releases followed the process
- reporting process compliance and improvement actions
- supporting corrective/preventive actions for recurring process failures
What does not belong in this bucket?
Do not include these unless your organisation intentionally defines SQA differently:
- writing and executing product test cases
- exploratory testing
- automated regression execution
- bug fixing
- system testing
- customer acceptance testing
- post-release support
- developer unit testing
Those may be quality-related, but they are not the narrow process-SQA activity this calculator is modelling.
Assumptions and limitations
- The 5–6% range is a planning rule of thumb, not a standard.
- Agile teams may distribute SQA responsibilities across roles rather than one dedicated SQA person.
- Regulated, safety-critical, audited, or immature organisations may need more process assurance.
- Mature teams with lightweight processes may need less formal SQA, but should still fund process improvement and compliance checks.
- Internal historical data is better than any generic rule of thumb.
Frequently asked questions
What is the SQA budget rule of thumb?
A commonly cited process SQA rule of thumb is about 5–6% of total project effort, split roughly evenly between process creation/training and process auditing.
Is SQA the same as software testing?
No. In this calculator, SQA means process quality assurance: defining, training, improving, and auditing the process. Product testing and bug fixing should be budgeted separately.
How do you calculate SQA FTE?
Convert the SQA target into hours, then divide by project duration in months and by FTE hours per month.
Should every project use 5–6% for SQA?
No. It is an early planning benchmark. Regulated, safety-critical, immature, or process-heavy organisations may need more; mature lightweight teams may allocate responsibilities differently.
What should be included in process/training vs auditing?
Process/training includes quality planning, standards, templates, coaching, and process improvement. Auditing includes checking whether required reviews, traces, approvals, and evidence actually happened.