<p>This seems to be an overlooked area that could really use some insight.  What are your best practices for:</p>

<ul>
<li>making an upgrade procedure</li>
<li>backing out in case of errors</li>
<li>syncing code and database changes</li>
<li>testing prior to deployment</li>
<li>mechanics of modifying the table</li>
</ul>

<p>etc...</p>

In general my rule is: "The application should manage it's own schema."
This means schema upgrade scripts  are part of any upgrade package for the application and run automatically when the application starts.  In case of errors the application fails to start and the upgrade script transaction is not committed.  The downside to this is that the application has to have full modification access to the schema (this annoys DBAs).
I've had great success using Hibernates SchemaUpdate feature to manage the table structures. Leaving the upgrade scripts to only handle actual data initialization and occasional removing of columns (SchemaUpdate doesn't do that).
Regarding testing, since the upgrades are part of the application, testing them becomes part of the test cycle for the application.
Afterthought: Taking on board some of the criticism in other posts here, note the rule says "it's own". It only really applies where the application
owns
the schema as is generally the case with software sold as a product. If your software is sharing a database with other software, use other methods.