There is a nice article about progressive testing by Mphasis:
https://www.mphasis.com/home/thought-leadership/blog/test-automation-regressive-vs-progressive-automation.html
Progressive automation is to automate almost every test case instead
of executing test cases manually. This is typically seen with the
projects that run in agile methodology. You will see in sprint
automation, which means, automation of the use cases that are
developed in the same sprint. WOW, this looks like a revolution, isn’t
it? When you automate every test case and during software development
the requirements or designs of the application are bound to change.
Then, the automation scripts have to be rewritten or redo completely
as we progress into next sprints.
When we refer more articles and tries to understand more about "Progressive" testing we could find that it resembles a lot with test-driven development(TDD), Agile, V model etc.
But from the
https://opkey.com/blog-detail.php/What-is-Progressive-Automation?
What is Progressive Automation? Progressive automation is one of the
methods of automation technique where test modules are tested one
after the other. In progressive automation, automated test scripts are
written along with the development code, for faster testing and
identification of problems along with quick fixes. The scripts are
essentially written to test new software.
From here it sounds more like overlapping of component testing, integration testing, and TDD
So, from the readings, I would define
"Progressive" testing as a "TDD approach to automated integration
test".
From my personal experience, "Progressive" testing where around 100% scenarios are automated is highly possible for API tests.
- Here both dev and test team starts to work on the same user story. ( We copy-paste the development user story to test user story)
- The user-story explains the use case, expected inputs, expected outputs, performance requirements, and other API contracts.
- Both the test team and the development team start codes for the user-story in the same sprint.
- So by the time the product feature completes, tests are also complete.
- We replace the stubs and drivers with actual data and test it locally.
- Integrates the tests to pipeline
- Developers initiate the build and the test runs in the pipeline,
- The feature is pushed to system test only if all tests pass
Replacing stubs and drivers, with actual component doesn't affect the test in any way as bot testers and developers use the same user story and API contract.
But for UI testing, this approach is not possible because we cannot automate without knowing the HTML DOM, how it will be rendered etc.
Tool suggestion: we used robotframework