There's more to it than that. There is a very significant portion of managers, who oversee either programmers or managers who do so, to whom testing is a "waste of time and money" because "it doesn't add value" to the code. Their concept is that there is a right way to write code and, since they're paying a large sum of money for the programmers, they should get it right the first time. And, in a weird way, that position is a fair one.

However, that position is only defensible if the programmers have the following characteristics:

1. Intimately understand every business requirement, including how they might change
2. Are involved in the project from the initial design phase through retirement, especially in timelines
3. No new programmers join the project
4. No one else is involved in any way with the project

None of those four requirements are ever real-world. Ever. Someone else always writes the requirements (which are impossible to fully comprehend). Someone else always writes the timelines, and then pulls them in. No programmer is ever involved with a project from pre-design to retirement, and staff is always rotating. And, you're lucky if as many as half the people on a project are the programmers.

So, testing, especially regression suites, become extremely important. However, to write a solid regression suite is a project in and of itself. By its very nature, you cannot have the programmer(s) write it. They don't know enough about the requirements and they know too much about the implementation.

You should never have the programmer(s) sign off on the testing, anyways. They know too much about the code. Testing, imho, should be (primarily) black-box testing. Programmers, by their nature, do white-box testing, which is good, but isn't stringent enough for release sign-off.

That said, upgrading should be easy if the programmers were able to write the application in a modular enough fashion. Upgrades very rarely affect more than two or three logical sections of an application. The problem with upgrades is that those logical sections have historically never been separated out. Not even with OO code. (I worked on a project which had objects, but encapsulation was violated left and right.)

There needs to be better design and requirements. If that is done, better coding will necessarily follow. Bad requirements => Bad design => Bad code => No upgrading.