When releases were quarterly, a test phase before each one made sense. There was time, and the cost of finding something late was a delayed release rather than a broken one. Shipping weekly removes that time, and teams that keep the old shape end up either slowing down or skipping the testing.
Move the checking to where the change is made
The cheapest place to catch a defect is next to the person who wrote it, while they still have the context. Tests that run on every change, fast enough that nobody avoids them, catch more than a thorough pass a fortnight later.
Fast matters more than complete. A suite that takes forty minutes will be skipped under pressure, and a skipped suite catches nothing.
Decide what you will not test
Testing everything to the same depth is how suites become slow and brittle. Rank by consequence: a fault in billing or authentication matters more than one in a settings page, and the depth of testing should say so.
Make releases reversible
At weekly cadence, the ability to undo a release quickly is worth more than another day of testing. A release you can withdraw in minutes changes the cost of being wrong.
Keep somebody looking at the whole thing
Automated checks confirm what you predicted.
Exploratory testing finds what nobody thought to predict.
Both are needed. Teams that drop the second tend to ship software that passes every test and still feels broken.
The aim is not more testing. It is testing arranged so that the slow, careful parts happen where they are cheap, and the release itself is routine.