Quality to software is not as sugar is to coffee.
One does not simply add “two teaspoons” of quality at the end of development and suddenly have a sweet, high quality product. If testing is left for the end, it means there is only time for the checks that merely verify that the software works. Many times, Gantt diagrams show "testing" as a task to perform in the last two days, but what if someone were to find grave errors in that small window of time? Scott Barber says something about this, specifically related to performance tests, but it could be extrapolated to testing in general:
“Performing the tests at the end of a project is like asking for a blood test when the patient is already dead.”
Testing and coding should be considered two tasks of the same activity, and should start together. In fact, testing should begin even before anything else, so when the time comes to start coding, it’s already been decided how to go about testing. This is especially useful for preventing errors, not just looking for them.
Speaking of test management, it’s closely related to project management because testing is highly connected to several areas, therefore everything must be planned together in a well-coordinated manner.
Some typical questions to ask to know if a team is managing testing proactively (or if at all) could be:
The list of issues related to risk management and a team’s knowledge of the product quality could go on and on.
In continuous testing, testing activities must be considered from the first day of the project and thereafter. Testing shouldn’t be regarded as something done in case there’s spare time, or in isolation. It should be planned and executed deliberately, in order to meet business objectives.
Everything teams need to know to shift-left testing and reach the level of maturity in their quality engineering processes to enable CI/CD.