Progression testing
Progression testing is testing the new or changed behaviour in a release to confirm it does what its requirements say. Some teams use the term, and it is not an ISTQB glossary term. It is the counterpart of regression testing, which re-checks behaviour that was left unchanged to confirm the change did not break it.
The longer version
A release contains two kinds of code. One kind is new or modified: a feature, a changed rule, a fixed defect. The other is everything else, which the team did not mean to touch. Progression tests target the first kind. They are written from the requirements or acceptance criteria of the change, so the expected result comes from the new or changed requirement and not from a previous release: for a new feature there is no earlier behaviour to compare with, and for a changed rule the old behaviour is exactly what is no longer right.
Regression testing runs the other way. Its tests already exist, they passed before the current change, and the question is whether they still pass. The same test changes role over time. A check written to prove a new discount rule is progression work for that change; after it merges, the first change made for some other reason that re-runs it turns it into a regression check. Retesting, which re-runs a failed test after a fix, is a third thing again: it confirms one defect is gone, where progression testing confirms a whole change behaves as specified.
The usual failure is giving the progression work all the attention. The new feature is demonstrated, the suite of old checks is trusted without being run, and the change breaks something nobody retested. The opposite failure is an automated regression run that goes green while the new behaviour has no test at all, because nobody wrote one until the next sprint. Both come from treating the two as one activity.
In a sprint the order is natural. Progression tests are written alongside the story and run first, since the new behaviour is the most likely place for a defect. The regression suite then runs over the whole build, and the progression tests that passed are added to it as the new baseline.
Common questions
What is the difference between progression testing and regression testing?
Progression testing checks behaviour that is new or changed in the release, against its requirements. Regression testing re-checks behaviour that was not meant to change, against how it worked before. One asks whether the change works; the other asks whether the change broke anything else.
Is progression testing the same as new feature testing?
New feature testing is the main part of it, and the term also covers changed behaviour in an existing feature, such as a revised pricing rule. The defining trait is that the expected result comes from the new requirement, not from how the product behaved before.
When does a progression test become a regression test?
A progression test becomes a regression test once it has merged and a later change, made for something else, runs it again. From that run onward it guards behaviour the later change was not meant to touch, which is regression work. A test written for a story keeps its assertions and changes its label.
Which should run first, progression or regression tests?
Progression tests usually run first, because the new or changed behaviour is the likeliest place for a defect and the earliest result gives developers the most time to fix it. The regression suite runs once the build is stable enough to be worth running it against.
Does visual regression testing count as progression testing?
A visual comparison against an approved baseline is a regression check. When the design changed on purpose, the new page has no baseline, so a person reviews it against the design as a progression test, and the approved image then becomes the baseline for later runs.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.