Not all software applications (information systems) are the same.

Some are OperatingSystem based, some are Web-based.

But even within the Web-based section they differ from one to another.
Because there are so many ways a software application can be build and what their core functionality is, there are also different types of test frameworks.

Examples of types of test frameworks are:
1. Linear Automation Framework
2. Modular Based Testing Framework
3. Library Architecture Testing Framework
4. Data-Driven Framework
5. Keyword-Driven Framework
6. Hybrid Testing Framework
7. Modularity-driven testing
8. Model-based testing
9. Code-driven testing
10. Behavior driven development
[read more]

So when choosing for a test tool. This is a good starting point to take this into account.

Related blogs: 
​https://www.maveryx.com/4-steps-to-select-the-right-test-automation-tool-for-your-project/www.maveryx.com/4-steps-to-select-the-right-test-automation-tool-for-your-project/

So I was thinking about this for a while....

The approach between project teams regarding software testing is many times not the same. Then suddenly I realized there's a analogy:
In some projects they have like a high gear... they start fast, but they don't do much unit testing and it seems like they finish 1 project-item (story) after another.

The other team however writes solid and proper unit tests and automation checks. They are more like in low gear... their velocity seems a lot lower...

Nobody is talking about this, but everyone has to deal with it.

Your main process is something like Scrum, right?

And you also know what regression testing is, and why it is needed, right?
You also probably know what the TestPyramid is....

You know why you want to weed your garden, so you know why you want to regression test your software.

These are important things to keep in mind:

- Who is gonna create the regression test set? 
- When is the regression test set created? (in the Sprint? then poker the work)
- Is the regression testing done in or outside the sprint? 
- Who is gonna pay for the regression testing? (the customer or you?) (what are the rules about this?)
- When are the bugs found in the regression test session fixed? In the Sprint or outside the Sprint? By the team or by another team? 
- Is it clear who is looking at the UI layer, who is looking at the API layer and who is looking at the UNIT test layer? and if yes, if bugs are found in of of the layers, who's gonna check that fixing is needed in one of the other layers?
- Do you need a TEST MANAGER to manage all these things? The timing of the regression testing, the planning, and setting up the TEST POLICY for the company, etc?
- Who gives the signal that regression testing is ready? (who reports?)
- Who determines (or is responsible for) if a CODE FREEZE is needed? (is it the one and only tester in the team? what is the name of the person that determines if a code freeze is needed?)

In other words, does the company have a policy regarding software testing about these aspects?

Probably you don't test thin air, but an actual test object. And somehow somewhere it has to be clear what is being tested so you need a scope. 

That means you need a PRA, a Product Risk Analysis (or Product Risk Assesment).

You knew that right?

Who is gonna perform or take the lead in that? (Who is gonna manage that?)
Is that done in the regular Scrum process (or is a group of people outside the team gonna do that?)

Again you're probably not gonna test thin air, so from the scope that roled out the PRA session. You need requirements.

New questions arise:
- Who's gonna determine or control what Requirements have to be only checked once and what Requirements have to be checked everytime in the Regression test set, again and again?
- Who's gonna determine whether these (automated) checks are done in the UI test layer, API test layer or UNIT test layer? 
- Who's gonna determine what other types of testing have to be done? (examples: User Acceptance Testing, Performance Testing, Security Testing)

Things are getting complex now?
Helaas we are not there yet.

Is your test object just 1 installable Operating System related thing?
Like a PC game or a Paint tool or a Calculator tool?

Or is it a combination of systems like one web-cloud system on the customer side and (working together with) one web-cloud system that you developed?

That means all of the above mentioned questions have to be mapped, not on 1 system, but on many. Or do you want to regression test applicaton B and just ignore the regression testing of the application A it interacts with? 
No probably not, so... bigger planning, even more questions arise. More things to take into account. Again: who is gonna do that? When is it done? Who is gonna pay for that, etc?

Just doin' Scrum and not taking into account those complexity aspects of a test process?
Not an option!