第一问：测试团队的工作也依赖于业务和开发，如何有效提高与业务团队和开发团队的合作默契？
解答:1：
测试团队与开发团队和业务团队的沟通，都是难点，这个难点，一方面是沟通机制的问题。但是更为重要的是各自的知识积累，比如测试人员的业务知识积累，以及对软件系统的全面了解。
因此，对于复杂的产品，比如业务性很强的软件，比如复杂通讯系统，复杂的金融系统，测试工程师的测试效果，可能三分靠测试技术，气七分要考对测试金融、通讯具体业务的了解和掌握程度。测试人员的职业寿命比较长，与这一点也是密切相关。对于复杂的业务来说，培养一个测试专家不难，难事培养一个对业务全面了解的业务专家是很难的。这也是测试工程师职业竞争力的一个积累点所在。
解答2：
测试团队和开发团队的关系时上下游关系，测试的进程依赖于开发的进度，测试的结果需要开发承认。需要注意的是双方的关系要融洽。开发和测试容易形成敌对关系，这需要开发和测试的主管要具备协调对立关系的能力和缓解对立情绪办法。
第二问：团队如何考虑平衡质量和速度的测试策略？
解答1：
测试本身就是在成本和质量之间找的平衡点，如果投入的财力和工作量是有限的。那么必须对被测试对象的功能点划分优先级，优先级高的优先测试。
另外，一个要考虑产品遗留bug会产生后果的严重程度。如果是公司内部IT系统，功能对业务影响不大，又着急上线，那么跑完正常功能和正常流程，以及少量异常流程，基本就可以上西线了。如果，是银行、电信这类系统，没有办法避免投入。目前，中国的银行在IT方面的投入，可能是世界之最，超级就，超级的投入，产生超级的应用和质量。大家可以对比国外的金融IT，基本上都不是中国的对手。如果是产品，或者系统不断迭代升级的软件系统，那么就需要考虑自动化了。一般来说，同一产品，五轮以上的手工测试，就可以考虑自动化了。这是提升效率的好办法。
不同的项目，对软件的质量要求是不一样的，公司的领导层必须对产品质量的要求要有理性客观的定位，否则，会出现测试资源投入不足，造成既要马儿跑，又不让马儿吃草的局面。所以说，测试工作的定调，首先是研发的老大要做好的。如果一旦做不好，可能工作开展就比较麻烦。我对这个问题，就阐述到此。
解答2
移动app举例解答下这个问题，app要求全质量（功能、性能、易用性、安全和兼容性，一样不少），考虑到发布要求尽量做到分层测试，第一种分层考虑是先考虑接口功能、UI功能和性能测试，再考虑兼容性和安全测试。第二种分层考虑研发阶段、系统测试阶段和上线回归三个阶段任务分层，研发相当于功能集成测试，尽量做到接口功能自动化测试，用例和自动化保持在基本覆盖用例集，内部测试团队独立承担；在系统测试和上线验收阶段，可考虑众测、灰度发布用户中组织并承担测试。
对代码质量检查和持续集成活动是自动化测试活动、接口测试是自动化测试活动、UI界面功能也是自动化活动，迭代最多还是版本持续集成这个环节。
系统测试和验收测试阶段，倘若用例质量高，建立众测能力也是不错的选择发，用例覆盖有保障，执行层面参与的人多了，手工比自动化测试效率更高。
第三问：敏捷模式下，如何平衡快速发布和客户对质量的期望？
敏捷指的是内部迭代的敏捷，不是鲁莽的把一个没经过充分测试的产品直接推给客户。客户对质量的期望需要在销售阶段就做好引导，测试人员在后期面对客户去平衡客户的期望就太晚了。
第四问： 团队的人测不出问题 ，上线后问题又很多，主管只能抽测一些重点的 ，这种情况怎么解决？
解答1：
团队的人员测试不出来问题，这是很严重的。那么，首先要找到原因所在。既然主管，做了一些重新测试，如果主管发现了问题，针对这些问题，要与测试工程师一起分析为什么测试工程师没有发现问题。也就是做缺陷分析，缺陷分析是提升测试人员测试效果很好的手段。
解答2：
如果系统的使用环境很复杂的话，这种情况就不是自己能避免的了。某公司，他们内部测试团队能力已经比较强了，但是系统部署到客户那里依然会出现各种问题，归根到底是因为客户是多样的，而自己的测试环境变化是有限的。 解决方案只能是自家的测试队伍努力提高测试用例的完备性，利用其它力量在不同的环境下做充分验证。
解答3
我觉得测试测不出问题，工作量评估、工作环境评估不准也是原因。
应需充分调研客户的具体需求，实际运作环境，然后做测试工作量的准确评估，提出合理的人力、测试时长诉求。如果人力、时间给足了，Case也覆盖到了，还有遗漏，就是严重的工作态度问题，属于测试遗漏。我们的做法是所有跟用例无关的缺陷，后续都必须维护回测试用例里，不求用例百分百覆盖，但应尽可能趋近于百分百。
未完待续.....................
【原创文章 转载请标注此出处】