What are the metrics to be followed for an any project and how could estimate that whether that metrics are pass in our test....what are the documents to be submit to the client after completion of testing.
Joel's got some good suggestions for sure. However, always keep in mind that a metric is a very subjective view and it can be difficult to express the true state of the product through a metric. I get a ton of metrics, but when it comes time for release, I'll rely more on my TL saying, "yeah it's pretty good", or "No, it's still horrible" to determine whether or not I'll push for a release. I usually request a report leading up to the end project and also periodic status reports, which outline our major concerns and recommendations.
As far as what to deliver to the client. It would largely depend on what the client has requested and, also, what you are contracted to provide. In many cases the customer will write into their agreement that they will receive periodic updates on the progress of the software. It's usually more detailed than this, but it is in there sometimes. If this is the case then there is usually a Non-Disclosure Agreement or something like that signed also. Anyway, the long of the short of it is you might not have a choice what to deliver. If the customer has asked for full disclosure, then you might show them everything. Many times this is a burden, but some times this can also be a good thing because it gives you periodic updates in the development process indicating if you're on the right track or not.
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
Agree with above but keep in mind that you only need to measure or get indicators related to the objectives of the testing. So please, first identify your testing objectives with enough detail to get an idea of what to measure, then sort them by priorities and later get the measure or indicator (KPI)
In my last UAT project I got these ones (some of them):
Objective: deliver on time
Description: Deliver test results as planned
Deviation dates (days)
#of amends needed in production spreadsheets
#issues raised to IT
#changes in testing scope