At my company, we don't have enough resources to hire a product owner to do this job (deliver the product to the client). Now, the PM is the responsible for this. But, if the SQA team (or one of its members) know the customer needs inside the company and gather its software requeriments, we suppose they have to participate in the delivery too, so we think is something that can be achieved through the SQA Team. Is a good policy? How must to be the relation between the SQA team and the customer?
I believe QA should be involved in all aspects of the software design and development process.
I believe that if QA is involved early enough in the process, bugs can be avoided rather than merely detected and fixed. In the best situations, I've had my teams participate in all Requirements and Specs reviews. They were trained experts at spotting inconsistencies and omissions - highlighting these and having them fixed during reviews meant that the product owners, product managers and developers were more in synch. This resulted in fewer bugs in the eventual code.
When configurations and migrations occurred during the installation process, I believe that QA can play a significant part in checking the results of the installation - ensuring that they meet expectations.
I believe that it may not be necessary for QA to specifically meet customers, although I have seen it be a useful adjunct to more effective testing. In one early-stage startup, we got to meet the first Beta customer and see how she actually performer her job. That allowed us to imagine how her job could be simplified/enhanced as we developer the software her company would eventually use. We even had a way to look at features and issues that we called "The Barbara Test"
I don't think QA can be a de-facto Product Owner. Nor do I think QA can take the place of a real Product Manager. I don't think QA should own responsibility for gathering product requirements. But I do think that QA can aid by participating in much of the product development cycle.
Software quality has a broad scope. Just like Joe says I believe QA should be involved in all aspects of software development. Each person/company just has to find out how much effort and which is appropriate for their situation.
Is a good policy?
Probably not. As an SQA person that has a lot of dual roles in the past I have learned that a lack of focus hurst both roles. Also it hard to decide where your priorities should lay. In your case what is more important delivery or preventing defects. This switches all the time. Someone with a dual-role needs to continuously look critical at their workload and evaluate if they are taking the right actions.
Can it be done, surely. If you're at a small company it is common that people have a lot of dual-roles. Making stuff happen is important skill as well.
How must to be the relation between the SQA team and the customer?
However the team sees it fit. There is not a single best practise you should follow. Experiment, retrospect and adapt. Find a cycle where you keep questioning if this situation is still optimal and improve in small steps.
I'll take a risk and disagree with Joe ). As it seems to me in a well-built process QA should not participate in release delivery (as per your definition of this term) however this might depend on what your release looks like and what your QA looks like.
I do not think a usual QA-man should be an expert in customer relations or release implementation. Participating in activities which are non-relevant to their skills might give them an extra headache and decrease productivity in their skill-relevant things.
I vote for just a logging of release delivery phase what can further be analyzed by a project manager who can then communicate some QA-relevant moments to the team.