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! 

right-click mouse, open in new browser tab to watch in full screen:

eeey, suprised to see you in here? Haven't I seen you here before? busy with 2 things at the same time?

I've talked about layers and test syllabus topics before in other blogs. Well the thing is, I can present you a 2D Powerpoint image, I can even show you a highly advanced holographic.
But the real more then 3D holograpic images...? They life in our minds.
We create them with our own imagination. They originate from scratch and evolve sometimes like a Pokémon with a lucky egg (which doubles all experience points earned for 30 minutes).

The real gems in life are sometimes hard to find and reserved for the ones with the best endurance or the best (exploring) skills. 

The same apply's to software testing. Dedication, genius, creative, smart...
Many time's it is the combination of things that leads to the revelation of the root cause of a bug. "Glad to be of service dear programmer!"

I know this website hasn't thousand and thousands of visitors on a daily basis. But some gems must not be found by everyone. They wouldn't be special anymore if everybody would have them.
Just like some Pokémons are ultra rare... some "5D images" are only destined for a special community of people. In this case you!
Remember that a combination of factors can lead to the trouvaille of a huge bug. Don't forget to think on several levels. And it doesn't even matter if you found the gem yesterday or tomorrow, the most important is that you found it, and now that you earned it, it is yours to keep!