在软件开发实施过程中，SQA是一个独立的角色，而SQA报告也是其工作的一个重点。如何把握好SQA报告的客观性与SQA报告的合适度是一个相当重要的问题。
在SQA工作中，SQA报告有些时候很轻易失去一种效力；相信实施过SQA工作的组织中也许都碰到过类似的问题，非凡是在刚开始实施的企业中；在缺泛促进力的情况下，SQA的工作经常会降低到统计缺陷的数据，审核一些无关紧要的问题，争论一些无关紧要的问题的情况中。在SQA组织相对保守的情况下。甚至还会不敢去同意任何产品的发布与交付。在项目总结会议或更高一级会议的时候，罗列出的是一长串令人惊奇的缺陷。那么，开发人员又不得不对此花费大量的时间去修改。而结果呢，却发现这些缺陷或FINDING大部分是不影响软件运行质量或交付的缺陷，拼写错误，语句不通等。而当修复这些所谓的缺陷后，很快就可以进行交付了。
那么如何把握SQA报告一个简单的原则呢，它不应该受软件技术经理或项目经理的控制。在项目进展的过程中，非凡是对于合同项目来讲，进度总是很紧张的，而技术经理通常不愿支持诸如测试计划不完整，文档不全面，所写文档不正确，存在一些开发人员本身的问题等之类的SQA的报告。SQA应该在此情况下，有能够向更高级别治理层报告的通道。并能明确问题的优先级，争取问题的优先解决。并且确定与协商的过程中需要获得修复要害问题所需要的资源与时间。
在SQA报告的过程中，对报告级别的选反需要进行考虑与权衡。在项目整个开发的过程中，报告级低，有利于和开发及其它协同工作组保持密切的关系。而存在问题却是会降低报告的影响程度。不同的组织要根据本身组织的文化与自已项目的实际情况，定义好相关的机制与通道。
--SQA不能向项目经理报告
--SQA不宜跨越本地组织进行报告
--SQA和本地企业的最高治理层之间最多只能存在一个治理级别
--SQA和公司的高级质量经理之间应该随时保持一种联系
--SQA在实施中，有可能的情况下，要善于捕捉对质量非常关注的的现场负责人或高管人员。并及时向他们报告。
SQA的工作在国内进行的时间本身并不长，也存在着企业对SQA的一些误解等。而工作进展中的障碍，工作本身缺少的创造性等会使SQA很轻易丧失积级性。从而SQA可能会变成一种统计的官撩机构。而坚持贯彻抽象的理念与理想是很难的。在执行的过程中要寻求一种可行性，合理性。
