Acceptance Testing and Regression Testing: Difference, Process & Examples
Your new feature works today. But is it useful enough for the people who requested it? And did adding it damage a feature that worked yesterday? These are two different testing questions.
Does the product meet agreed user or business needs and the conditions for acceptance?
After a change, do previously working parts still behave correctly?
Acceptance testing is a testing level used to judge whether a system is suitable for its intended users and ready for an acceptance decision. Regression testing checks whether a code, configuration, or environment change has caused an unwanted effect on existing behaviour. Acceptance testing asks, “Can we accept this?” Regression testing asks, “What did this change break?”
Open the chapter map
In the software testing chapter, we saw that different tests answer different questions. This chapter studies two of those questions deeply. Their names are often placed together in exam notes, but their purposes are different.
Start with a Simple Mock-Test App Example
Imagine a website where students practise timed MCQ tests. The exam coordinator requested these rules:
- The test contains 25 questions.
- Each correct answer gives 2 marks.
- Each wrong answer deducts 0.5 mark.
- An unanswered question gives 0 marks.
- At the end of the timer, the test submits automatically and shows the result.
The developer finishes the feature. Now two separate checks are needed.
Can students take the test as intended? Does the result follow the agreed marking rules? Can the coordinator accept the feature for use?
The timer was changed. Do manual submission, saved answers, review, and previously working result pages still work?
Notice the focus: the first question looks at the expected outcome for users. The second looks at the possible side effects of a change. The unit testing chapter showed how to check a small part in isolation; here we are asking wider questions about intended use and change.
What is Acceptance Testing?
Acceptance testing checks a system against agreed acceptance conditions and user or business needs. The result helps the relevant people decide whether to accept the system, request changes, or delay release. It is a test level, not simply “the last test before launch”.
For the mock-test app, a test that only proves the score-calculation function returns 20 is useful, but it does not answer whether a student can complete the test and receive a correct, understandable result. The acceptance question follows a meaningful user task.
Clear conditions matter. The requirements documentation chapter explains how a vague request becomes something we can verify. “The app should work well” is too vague; “the test auto-submits when the timer reaches zero and preserves saved answers” is testable.
A passing script is evidence for a decision; the decision also considers unresolved issues and agreed scope.
Who performs acceptance testing?
It depends on the type of acceptance. Intended users or customer representatives commonly perform user acceptance testing (UAT), often with help from testers and developers. Operations staff may check deployment and support readiness. A designated customer or authority may check contract or regulatory conditions. The developer alone should not silently decide what the user will accept.
What is an acceptance criterion?
An acceptance criterion is an agreed condition a feature should satisfy. It should be clear enough to check. For example: “If time reaches zero while a test is active, the system submits the saved responses once and shows the result using the published marking rule.” This defines observable behaviour, including an important boundary case.
| Weak statement | Testable acceptance criterion |
|---|---|
| Result should be correct. | For 10 correct, 4 wrong, and 11 unanswered answers, score is 10 × 2 − 4 × 0.5 = 18 marks. |
| Timer should work. | When time reaches zero, saved responses are submitted once and the test cannot accept further answers. |
| Website should be easy to use. | A student can start, answer, submit, and find the score using the agreed supported devices and accessibility checks. |
On mobile, swipe the table sideways if needed.
The last criterion still needs the team to define the supported devices and checks. Do not claim a requirement is measurable if its important details are missing.
Main Types of Acceptance Testing
User acceptance testing (UAT)
Intended users or their representatives check whether the system supports real tasks. Example: students take a practice test while an exam coordinator checks result rules.
Operational acceptance testing (OAT)
Checks whether the system can be operated and supported: deployment, backup, recovery, monitoring, and related operational procedures where relevant.
Contractual acceptance
Checks conditions written in an agreement. Example: an agreed export feature, data format, or support requirement must be delivered.
Regulatory acceptance
Checks applicable regulatory conditions where the product's domain requires them. The actual conditions must come from the relevant rules, not assumptions.
Alpha testing
Selected users test a product in a controlled environment associated with the developer before broader release. Feedback helps find practical issues.
Beta testing
Selected external users try a product in their own or a real-use environment before general release, under a defined beta programme.
Do not mix the names: UAT is one form of acceptance testing, not a synonym for every acceptance activity. Alpha and beta describe particular ways a product can be tried by users; they do not mean “all testing is finished”.
Acceptance Testing Process: Step by Step
Decide what will be accepted, who will run the checks, and who can make the acceptance decision.
Use approved requirements, user stories, business rules, contracts, or operational needs. Resolve unclear expectations early.
Choose tasks that represent genuine use. For a mock test, include correct, wrong, unanswered, timeout, and interrupted attempts as relevant.
Use a stable version and a setting close enough to intended use to make observations meaningful.
Compare observed results with agreed criteria. Record defects, severity, and any limitations.
Fix issues, confirm fixes, and rerun appropriate checks before making the decision.
The authorised stakeholder accepts, requests more work, or defers release based on results and agreed conditions.
An acceptance decision does not promise that software has zero defects. It records that the product meets the agreed conditions to an acceptable extent for the planned use, with known issues handled according to the team's decision. The SDLC chapter places this decision within the larger development and release process.
What is Regression Testing?
Regression testing reruns selected checks after a change to find unwanted effects in behaviour that previously worked. Changes can include a bug fix, a new feature, refactoring, an updated dependency, configuration, or a changed environment. The key question is whether the change affected something else.
Suppose the mock-test app's timer is changed so it auto-submits reliably. That fix may accidentally submit the test twice, lose an answer saved at the last second, or block the student's manual Submit button. Regression tests look for such side effects.
A good regression set follows likely effects instead of repeating random tests.
Regression testing can be done at component, integration, system, or even acceptance-related levels depending on the change and risk. For example, a small score-function change needs component checks, while a timer and result-flow change may also need connected and user-facing checks. Understanding dependencies between modules helps identify where a change might spread.
Regression testing vs retesting
Reproduce the original defect after the fix. Did that specific problem go away?
Check other affected behaviour. Did the fix create a new problem elsewhere?
Example: a student previously received 19 marks instead of 18. After the calculation fix, checking that exact scenario now returns 18 is confirmation testing. Checking that unanswered questions still count as zero, the result page loads, and old completed attempts remain correct is regression testing. The two checks complement each other.
Regression Testing Process and Test Selection
Read what was changed and why. Identify affected code, interfaces, data, and user journeys.
Trace dependencies and risk. A timer change may affect submission, answer storage, scoring, and history.
Run checks for changed and connected areas first; include important core workflows and past defect cases.
Add a test for the new behaviour and update any expected results changed intentionally by the requirement.
Compare against expected behaviour. Separate a genuine product failure from a stale test or unstable environment.
Remove duplicate or obsolete checks and keep important tests repeatable for future changes.
Selective regression
Choose tests based on affected areas and risk. Useful when the suite is large and feedback must be quick.
Broader regression
Run a wider suite for a major release, risky shared change, or other situation where more coverage is justified.
Automation support
Automate stable, repeatable checks where it saves time. Human investigation remains useful for complex or surprising behaviour.
Important: Regression testing does not always mean “run every test again”. Choose depth from impact, risk, available time, and the importance of the affected workflow. A small smoke check can be part of a fast feedback cycle, but it is not a complete regression strategy by itself.
Complete Worked Example: Adding Negative Marking
Project change
The mock-test app previously gave 2 marks for a correct answer and 0 for a wrong answer. The exam coordinator now requests a deduction of 0.5 mark for each wrong answer. Unanswered questions still give 0. The timer, review screen, result page, and saved history must continue working.
Acceptance scenarios: Is the new rule suitable?
| ID | Scenario | Expected result |
|---|---|---|
| AT-01 | 10 correct, 4 wrong, 11 unanswered. | Score is 18 marks: 20 − 2 + 0. |
| AT-02 | Student checks marking instructions before starting. | “+2 correct, −0.5 wrong, 0 unanswered” is clearly shown. |
| AT-03 | Timer reaches zero while a student has saved answers. | Test submits once and shows a result following the agreed rule. |
| AT-04 | Coordinator reviews a sample result. | Displayed totals for correct, wrong, unanswered, and score agree with the rule. |
On mobile, swipe the table sideways if needed.
These tests support the acceptance decision because they represent what the student and coordinator need from the changed feature.
Regression scenarios: What might the change disturb?
| ID | Previously working behaviour to recheck | Reason |
|---|---|---|
| RT-01 | Manual Submit saves one attempt. | Score calculation is called by the submit flow. |
| RT-02 | Unanswered questions remain unanswered and carry 0 marks. | New deduction must not apply to skipped questions. |
| RT-03 | Answer review still identifies chosen and correct options. | The result data shape may be shared with review. |
| RT-04 | Existing completed attempts remain readable. | History and result display may use shared score fields. |
| RT-05 | Automatic submission still occurs once. | Timer and scoring work together during submission. |
On mobile, swipe the table sideways if needed.
There may also be a new direct test of the changed scoring function and a confirmation test for any bug fixed along the way. Test labels describe the objective of each check. One useful scenario can support more than one decision, but it is still important to state what it is proving.
Acceptance Testing vs Regression Testing: Key Differences
| Point | Acceptance testing | Regression testing |
|---|---|---|
| Main purpose | Support a decision about suitability and readiness for intended use. | Find unwanted effects after a change. |
| Key question | Does it meet agreed user or business needs? | Does previously working behaviour still work? |
| Classification | Test level. | Change-related testing activity; can occur at different levels. |
| Test basis | User needs, acceptance criteria, business rules, contracts, or operational conditions. | Change details, impact analysis, existing requirements, past tests, and risks. |
| Typical people | Intended users, customer or business representatives, operations staff, or designated authorities, depending on type. | Developers and testers commonly execute it; roles depend on project and test level. |
| When used | When an increment or system is ready to evaluate against agreed conditions; can repeat each iteration. | Whenever a change may affect existing behaviour. |
| Typical outcome | Accept, request fixes, or defer based on evidence and agreed conditions. | Confidence in unchanged behaviour or defects that need investigation. |
On mobile, swipe the table sideways if needed.
The two can happen close together. A team may run regression checks after a fix and then ask users to perform acceptance scenarios on the updated build. The order depends on the workflow; the two purposes remain different.
Common Mistakes Students Should Avoid
“Acceptance means bug-free”
Acceptance is a decision against agreed conditions and known risk. It does not prove the absence of every defect.
“Regression tests only new code”
The main concern is existing behaviour that the new change may have damaged.
“Retesting and regression are the same”
Retesting checks the particular fix. Regression looks for unwanted side effects.
“UAT equals all acceptance testing”
UAT is one form. Operational, contractual, regulatory, alpha, and beta activities can also be relevant.
“Regression must rerun everything”
Use impact and risk to select depth. Broader runs are useful when justified, not automatically for every tiny change.
“Only testers do these checks”
Different roles participate. Intended users are especially valuable for user acceptance, while developers often help run automated regression suites.
These checks belong in the wider quality assurance and verification/validation work. No one test activity tells the whole story of product quality.
How to Write This Topic in Semester Exams
2-mark answer
Acceptance testing checks whether software meets agreed user or business conditions and supports an acceptance decision. Regression testing checks whether a change has caused unwanted effects in behaviour that previously worked.
5-mark answer structure
- Define acceptance testing and its purpose.
- Define regression testing and when it is used.
- Give one common example.
- Differentiate them by objective, basis, participants, and outcome.
- Explain confirmation testing in one line to avoid confusion.
10-mark ready answer
Acceptance testing and regression testing are important software testing activities with different objectives. Acceptance testing is a test level that checks whether a software product satisfies agreed user or business needs and is suitable for its intended use. It supports an acceptance or release decision. The test basis can include acceptance criteria, requirements, business processes, contracts, and operational needs. Intended users or customer representatives commonly participate in user acceptance testing.
Forms of acceptance testing include user acceptance testing, operational acceptance testing, contractual acceptance testing, regulatory acceptance testing, alpha testing, and beta testing. A basic acceptance process is to agree on scope and criteria, prepare representative scenarios and a suitable environment, execute tests with relevant participants, record results and defects, resolve issues, and document the acceptance decision.
Regression testing checks whether a change to software or its environment has produced unwanted effects on existing behaviour. The change may be a bug fix, new feature, refactoring, configuration update, or dependency update. Testers first understand the change and perform impact analysis. They then select existing checks for changed, connected, and important areas, update tests for intended changes, execute them, investigate failures, and maintain the regression suite. Stable checks are often automated because they are run repeatedly.
For example, if a mock-test app adds negative marking, acceptance testing checks that the score and student-facing rules match what the exam coordinator requested. Regression testing checks that manual submission, unanswered questions, answer review, timer submission, and saved history still work. Checking that one earlier scoring defect has been fixed is confirmation testing; checking for side effects of that fix is regression testing.
Thus, acceptance testing asks whether the software is suitable for agreed use, while regression testing asks whether a change broke existing behaviour. Both contribute evidence to a reliable release decision.
Quick Revision and Memory Trick
Remember A-R-C: Acceptance = Agreed need; Regression = Risk after change; Confirmation = Check the exact fix.
Frequently Asked Questions
Is regression testing performed only after fixing bugs?
No. It is useful after any change that might affect existing behaviour, including new features, refactoring, and configuration updates.
Is acceptance testing always the final activity?
No. Acceptance scenarios can be run for each completed increment. Additional fixes and checks may still be needed after a failed or conditional acceptance review.
What is the difference between UAT and acceptance testing?
UAT is user acceptance testing, one form of acceptance testing. Other forms focus on operational, contractual, regulatory, alpha, or beta concerns.
Should all regression tests be automated?
Automation is useful for stable, repeatable checks, but not every useful observation fits an automated script. Choose methods based on risk and purpose.
Can the same scenario be used for acceptance and regression?
Yes. A timed submission scenario may show that a new requirement is met and later become a regression check after future changes. State the objective each time it is run.
Conclusion
When you study these terms, remember the two questions behind them. Acceptance testing checks whether the product meets the agreed needs of its users and supports a decision to accept it. Regression testing checks whether a change damaged behaviour that already worked. For a dependable release, teams need clear acceptance criteria, thoughtful impact analysis, useful test evidence, and an honest record of remaining issues.
