Maintenance Testing
Maintenance testing is testing changes to a system already in operation, or the impact of a changed environment on it. Once software is live, most work on it is maintenance: defects are fixed, features improved, the platform upgraded and, one day, the system retired. You start with real users, years of real data and other systems that depend on today’s behaviour.
For example, a clinic booking system that has run for four years moves to a new database server. No feature changes, yet the team must check that every record arrived intact and that booking, reminders and invoices work as before. Maintenance testing is not a separate test level: it reuses the levels and types you know, such as confirmation and regression testing.
Why it matters
The ISTQB Foundation syllabus describes testing a change in production as two jobs: evaluating whether the change was implemented successfully, and checking for regressions in the parts that did not change, usually most of the system. A change that works perfectly can still break an untouched report or a nightly job, and real customers meet that failure. With rarely enough time to retest everything, impact analysis and a reasoned regression scope put the tester’s effort where the change can do harm, and show the team what was tested and what was not.
Three triggers: modification, migration, retirement
The ISTQB Foundation syllabus groups the events that start maintenance testing into three triggers. Whatever the trigger, testing answers two questions — did the change work, and did anything else break? — and the trigger tells you where to look.
- Modification: planned enhancements in a release, corrective changes that fix defects, and hot fixes released outside the plan because a production failure cannot wait.
- Upgrade or migration of the operational environment, such as a move to another platform or database server. This can require tests of the new environment as well as of the changed software, and tests of data conversion when data from another application is migrated in.
- Retirement: an application reaches the end of its life, for example when another system replaces it. When its data must be kept for a long retention period, test the archiving, and the restoring and retrieving of data from the archive; also check the systems that exchanged data with it. Removing a single feature from a system that stays in use is usually handled as a modification, but its data and callers need the same care.
| Trigger | Did the change work? | Did anything else break? | Also check |
|---|---|---|---|
| Modificationplanned enhancement in a release | New and updated tests for the changed behaviour | Regression for the changed parts and what depends on them, plus the critical core | Old tests whose expected result changed on purpose are updated, not reported |
| Modificationcorrective change or hot fix | Confirmation test: the defect’s steps now pass | A small prepared regression pack before release, the wider run soon after | What was deferred, recorded as residual risk |
| Upgrade or migrationnew platform or environment | Installation, configuration and connections in the new environment | Wide regression: unchanged code now runs on a changed platform | Scheduled jobs, backups, response times against the old baseline |
| Upgrade or migrationdata conversion | Every record arrived intact: counts, totals and sample records match the source | Features that read the migrated records | Old records with different shapes and gaps, not only fresh test data |
| Retirementapplication at the end of its life | Data that must be kept for a long retention period is archived | Everything still in service, including systems that exchanged data with it | Restoring and retrieving data from the archive |
Rows follow the three triggers of the ISTQB Foundation syllabus; the cells summarise this lesson and are not a fixed checklist.
Impact analysis: what can this change affect?
You met impact analysis in the lesson on confirmation and regression testing as the way to choose regression tests. The ISTQB glossary describes it more broadly: identifying all the work products a change affects (code, documents, tests), including an estimate of the resources needed to make the change. In practice: the parts the change touches directly, the parts that depend on them, and the documents and tests that must change with it, including possible side effects. The syllabus notes it can be done before a change is made, to help decide whether to make it, given its consequences elsewhere in the system. Write the result down: it is the argument for your regression scope.
- The change: the ticket, changed modules or code diff, configuration changes, release notes.
- Dependencies: callers of a changed function or API, integrations, reports and exports that read the changed data, scheduled jobs.
- Traceability: links between requirements and tests show which tests cover the affected requirements. Where none were kept, ask, and record your assumptions.
- Data: tables and fields the change reads or writes, including records created years ago by older versions.
- Tests: which existing tests will fail because behaviour changed on purpose (update them, do not report a defect), and which new tests are needed.
Deciding the regression scope
According to the syllabus, the scope of maintenance testing typically depends on the degree of risk of the change, the size of the existing system and the size of the change. A one-line wording fix in a small internal tool needs little beyond a confirmation check; a one-line change to a shared tax calculation in a large ERP (enterprise resource planning) system needs wide regression, because the risk is high even though the change is small.
The three rings from the lesson on confirmation and regression testing (the changed area, its dependents, the critical core) and the selection strategies of the smoke, sanity and regression guide still apply. A live system adds two layers: the environment and its data, and a written record of what you leave out.
- The change: new and updated tests for the changed behaviour, and the confirmation test for a fixed defect.
- Direct impact: regression tests for the changed parts and everything that depends on them.
- The critical core: journeys that must work whatever changed, such as login and payment.
- Environment and data, for migrations and retirement: installation, configuration, integrations, scheduled jobs, backups, response times against the old baseline, data reconciliation (counts, totals, sample records) and archive retrieval.
- Out of scope, with a reason, so the team sees the residual risk instead of assuming everything was tested.
Try it: Regression Scenario Generator Try it: Risk-Based Test Generator
Worked example: a reminder fix in a live booking system
A clinic group’s booking system sends an SMS reminder 24 hours before each appointment, but branches in a second time zone get it at the wrong hour, because the job uses the server’s clock. The corrective fix uses each branch’s time zone and fills a new time_zone field for every existing branch; reminders already scheduled by the old version stay in the database. Impact analysis with the developer gave this scope:
- The change: for a branch in each time zone, the reminder arrives 24 hours before the appointment in local time, including one just after midnight.
- Direct impact: SMS and e-mail reminders, rescheduling and cancelling, and the reminder status report.
- Tests to update: two tests expected reminder times in server time; they are rewritten, not reported as defects.
- Data: every branch has a valid time zone, and reminders already scheduled by the old version are recalculated to local time, as the team decided. Comparing the reminders API response for sample appointments before and after the release shows what moved.
- Critical core: a short smoke run of login, booking and payment.
- Out of scope: detailed billing tests, because billing reads no reminder data — recorded as a decision, not forgotten.
Common mistakes
- Testing only the change and skipping regression in the unchanged parts, where most of the system sits.
- Assuming a migration with "no functional changes" needs no functional testing: unchanged code can fail on a changed platform or with converted data.
- Testing only with fresh data from the new version, while production holds years of older records with different shapes and gaps.
- Rewriting old tests until they pass without checking that the behaviour change was intended — or reporting a deliberate change as a defect.
- Retiring an application without testing archive retrieval and the systems that still exchange data with it.
The QA perspective
On a working team, maintenance testing starts when a change is proposed, not when the build arrives. In refinement or release planning, ask the questions that feed impact analysis: what else reads this data, what happens to records created before the change, how do we roll back? Record a short scope in the ticket or test plan: what will be tested, how deeply, and what is left out and why.
Prepare for hot fixes with a small regression pack of critical journeys that runs in minutes, so no urgent fix ships untested. After each maintenance release, update the regression suite, traceability links and test data. Together with the other work products of testing they are called testware, and keeping testware current is maintenance too.
Practice exercise
Scope the testing for a three-part change request
A library system has been in production for six years. For each item of the change request below, name the trigger, list what impact analysis must cover and propose a testing scope. Finish with what you would leave out, with a reason, and your questions for the team.
Change request CR-118 (library system, in production for six years)
1. The late-return fine rises from 1.00 SAR to 2.00 SAR per day,
for loans that start on or after 1 January.
2. The self-service kiosk application is retired; members use the front desk instead.
Kiosk loan and payment records of the last five years must stay retrievable for audits.
3. The application moves to a new major version of its application server.- Classify each item: modification, upgrade or migration of the environment, or retirement.
- List what each change touches directly, what depends on it, and the testing focus: the change itself, regression, environment, data or archive.
- Decide the overall scope, what is out of scope and your open questions.
Show the model answer
Item 1 is a modification of the fine calculation; overdue notices, member balances and the fines report depend on it. Test the boundary: a loan that starts on 31 December keeps 1.00 SAR per day even when overdue in January; one that starts on 1 January pays 2.00. Tests that expect 1.00 for new loans must be updated.
Item 2 is a retirement: the kiosk application reaches the end of its life. Check that its records are archived and that kiosk loans and payments of the last five years can be restored, found and read; that nothing still depends on the kiosks (integrations, scheduled jobs, reports that count kiosk loans); and, as regression, loans and returns at the front desk, which now carry all the traffic.
Item 3 is an environment upgrade: test installation, configuration, the e-mail and payment connections, the nightly overdue-notice job and key response times against the old baseline.
Scope: three changes, money and a new server, so run the full regression suite at least once on the new environment, plus the tests above. Out of scope, for example: a full load test if response times show no difference, recorded as residual risk. Questions: does a loan renewed after 1 January count as new? Where will the kiosk archive be kept, for how long, and who restores it for an audit? What is the rollback plan?
Frequently asked questions
Is maintenance testing the same as regression testing?
No. Regression testing is one part of it. Maintenance testing also tests the change itself — new or changed behaviour and the confirmation of fixed defects — and, for migrations and retirement, the new environment, converted data and archives. Regression testing also happens outside maintenance, for example on every build while a new system is being developed.
Who does the impact analysis, developers or testers?
Both, ideally with a business analyst or product owner. Developers see code dependencies; testers see business flows, data and test coverage; the business side knows how the feature is really used. One person alone usually misses a whole category of effects.
Does an urgent hot fix still need regression testing?
Yes, but a small, prepared one: the confirmation test plus a short pre-agreed pack of critical journeys before release, then a wider regression run soon after. Record what was deferred so the risk stays visible until that run passes.
What if the old system has no documentation and no tests?
Learn its current behaviour first, by exploratory testing and by talking to users and support staff. Record important outputs before the change — API responses, reports, calculated values — and compare them with the outputs after it. Some teams call such tests characterization tests. Build traceability gradually as you go.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Practise with Mutqan tools
Generate regression scenarios from a change description and a list of affected and related modules.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Compare two API responses (e.g. staging vs production) and list every structural and value difference.
Compare two JSON documents semantically and highlight added, removed and changed values.
Go deeper
- Smoke vs Sanity vs Regression TestingRegression selection: choosing what to run
- Risk-Based TestingUsing risk to select regression tests
- Testing Transactions and DB MigrationsHow to test a migration
- Deployment Verification TestingHow to verify a deployment: a plan written in advance, post-deploy smoke tests, synthetic checks, canary releases, feature flags, signals and rollback.
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.