ROI (return on investment) for investing on Test Process Improvement

I am sure every organization will have project analysis after a major release and followed by a formation of a  task team to implement some set of actions resulted out of project analysis meeting. Some of them which will always appear in the list are
1. Improve unit testing and define some criteria for integration and system testing team to accept build for their testing
2. Automate many of our tests which are used at various stages repeatedly (nightly build test, regression test)
3. Regression test automation % should progressively grow release after release
4. There should be clear production release criteria and risk assessment before release
5. Improve estimation
and so on

Many will finally agree that test process improvement seems to cover majority of the list  in the action items coming after project review.

Let me also share from my experience who will get the advantage investing in test process improvement. You need to answer "YES" or "NO" to following questions. It may look common sense but we ignore these patterns.
1. Are you able to make your last release with exact number of planned test cycles?
2. Can you assure that majority of the tests done by development team is not repeated again in next level of testing?
3. Number of patch releases made after final production release is under control therefore support team and customers are not cribbing?
4. You have a well defined maintenance team which work on customer issues and enhancements and none of your product next version road map plan are impacted due to maintenance release pressure?
5. When you analyse the defect found after release majority of them were not traced to "missing test case" or "incomplete regression test" due to lack of time?

If your answer is "No" to any two of the questions above I feel you must look at formal test process improvement in your organization. Some TIPs on how to go about it.
http://slidesha.re/MCN-Quick-TP-Assess

Like to hear from our software engineering community on their views.

Managing stakeholders - Test Manager perspective

Test manager will be addressing on day-to-day basis questions like:

• Why actual QA effort was more than planned?
• Why are we exceeding from number QA cycles planned in the project plan?
• Why do we need to do so much testing for few changes done to the code?
• Why are we still doing unit level tests at system level tests?
• What can we do to test cases attributes to qualify which helps us to decide on priority, during test execution cycle?
• How many defects logged are not traced to test cases? What are we doing about this?
• What risks were anticipated during test plan? How they were mitigated?

I feel these can be addressed better with focus on following:

• Good test case architecture where all levels of test cases fit and with right set of attributes defined helps test case selection on need basis
• Quality gates or levels of testing better defined with defect types to be uncovered as focus than use same old Unit, Integration and System testing as levels of tests
• Introduce escape tracking at each quality gate
• Define criteria to move testing from one level to another level and improve the definition continuously
• Introduce better tracking report to look at progress aspects, cleanliness aspects, test coverage aspects
• User lessons learnt and fix the gaps for future cycles of testing
• Use defect centered activity breakdown during planning phase

Take a look at http://slidesha.re/HBT6of6

I like to hear any comments or different views from the community