Functional & Regression Testing
Every release has to do what was asked and leave everything else working. We test both, scope regression by risk, and give you sign-off evidence showing what was checked on which build.
The release passed testing, and two days later finance noticed that credit notes no longer carried the original invoice number. Nobody had tested credit notes, because nobody had changed them. Escaped defects often look like this. They sit next to the feature that was built, in something that shared a table, a rule or a screen with it. Testing a release means answering two questions, and the second, what did we break, usually gets the least time.
Two questions, two kinds of testing
Functional testing asks whether the change does what was asked. That needs acceptance criteria agreed before the work started, test cases written from them, and a tester who also tries what the criteria forgot: the empty field, the second currency, the user with two roles. Much of it is manual the first time, and should be, because a new screen needs a person’s judgment before it needs a script.
Regression testing asks whether anything that used to work has stopped. It’s repetitive by nature, which makes it the right place for automation once a feature settles. Both kinds are traced to the requirement they check. When someone asks whether the discount rules were tested in this release, the answer is a link to the results rather than somebody’s recollection.
Regression scope should be a decision
Full regression every release
Run the whole regression pack before every release. It’s easy to explain, nothing is skipped on paper, and anyone who asks whether testing was done gets a clear answer.
- Simple to plan and simple to audit afterward
- No judgment call that someone could later be blamed for
- The pack grows each release until it no longer fits the window
- Testers skim the long, familiar parts, where defects quietly get through
Regression scoped by risk
Scope each release from what changed, what depends on it and what a failure would cost. The full pack still runs, on a schedule instead of every time.
- Changed areas and their neighbors get the deepest testing
- Money, customer data and compliance paths are checked every release
- Scope decisions are written down with the reasoning, for review
- It takes analysis up front, and someone has to own the call
How regression scope gets decided
| Area | Reason | Depth |
|---|---|---|
| Code changed in this release | Direct impact of the change | Full functional plus exploratory |
| Features sharing data or components | Likeliest place for side effects | Core paths and known edge cases |
| Payments, invoicing, personal data | A failure costs money or trust | Every release, changed or not |
| Areas with recent production defects | History says they break | Extended until they stay stable |
| Stable areas untouched for months | Low change, low exposure | Smoke test, full pack on schedule |
How a release gets tested
The cycle is the same for a weekly release and an annual upgrade; only the time each step gets changes. Every step leaves a record you can open later.
- 01
Read the change
Release notes, tickets, the code diff, and a conversation with the developers about what they touched and what worried them. You receive a short impact summary: what changed, what it touches and what is out of scope.
- 02
Agree the scope
Regression scope from the risk table, the new test cases, and the environment and data each one needs. The business owner approves it before testing starts, so any gap is a choice made in advance rather than a surprise.
- 03
Test the new behavior
Test cases against the acceptance criteria, then exploratory sessions on the same build. Defects go into your tracker with steps, data and the build number, so a developer can reproduce them on the first try.
- 04
Run regression
Automated checks run first, and manual regression covers what isn’t automated yet. Fixes are retested and the areas around each fix get a second look. You can follow results build by build in your test management tool.
- 05
Sign off
A release report states what was tested on which build, what failed, what is still open and who accepted it. The release decision stays with you; the report makes it a decision on evidence.
What sign-off rests on
A signature is only as good as what it refers to. The release pack gives the person approving the release, and anyone who asks later, the same four things.
Traceability to requirements
Each requirement links to the test cases that check it and their latest result, so an untested requirement is visible before release, not after a complaint.
Results tied to a build
Every result names the build, the environment and the test data it ran against. A pass on last week’s build is not counted as a pass on this one.
Open defects with an owner
Anything still open at release is listed with its severity, its workaround and the name of whoever accepted shipping with it. Accepted risk is recorded, not implied.
What was not tested, and why
Scope left out on purpose is listed with the reasoning. If a defect turns up there later, the conversation is about a known decision rather than a missed check.
What release owners ask
No, though they overlap. Test automation is about building a suite that runs on every change. This work decides what each release must be checked against, covers what a script can’t, and produces the evidence for sign-off. Automated tests are one of its tools, and the stable parts of a manual regression pack are the obvious next things to automate.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.