Test results of a proper test is all there is between a development and a production problem. And testing is often one of those things for which no time is available. To present a state of mind about testing, consider the following:
Reading the signs: Has this ever happened on your project ? A few classic cases...
Tester to developer "I trust you, the change you've done will be fine" - developer "And I trust you will tell me about the problem if there is one." I've got over 20 years of ABAP development experience: trust me on one thing: don't trust me. Test the changes. Development changes have nothing to do with the developers skills or personality. If anything: they have to do with the difference in interpretation between potentially many parties. And interpretations can differentiate to the smallest detail.
"That already worked before the last change was implemented" - so how can it be that it's not working any more ? Simple: never assume a development change only has impact on the actual bit being changed. A developer will make sure there are mimimal side effects to changes - however developers are human beings and it's nearly impossible to rule out side effects all together. No tunnel vision when testing please (which is just as hard as ruling out side effects).
"Move it to Pre-Prod - there's no test data available in development"Classic!, always the case on every project. And there is no problem with this - except that it's a bit harder for the developer to iron out the last errors. For every relevant change a transport needs to be sent to Pre-prod - which is time consuming. But then: getting test data to the development system is equally time consuming. To avoid turning your Pre-prod system into a development system - make sure the "Pre-prod developments" get the right priority - don't leave half-finished developments on Pre-prod system. Solve the problem or revert to the last version...
"It used to work that way (last week)" When it is actually true, there could be very valuable information. What has changed since last week ? However - it could also mean: "We found a way to make it do what we wanted it to do - but we forgot how we did it" - which is not a nice thing to report. Or how about "We want it to work that way but we don't want it handled as a new change request". In the mean time the developer spends hours on finding out what changed since last week...
These are just a few examples on processing development changes. But the bottom line is of course getting developments to an acceptable state without first building up an arm-length history of fixes. Every fix that needs to be applied will consume more time on the development - and generally it pays off to think the development through at the beginning and to put some effort in keeping the whole development in the picture.