困惑一、测试人员或测试团队是否能保证软件的质量？
测试小兵：
        做了一段时间的软件测试工作，一直被一些问题困扰着。比如以保证软件质量存在的测试人员或是大型、独立的测试团队是否
可以真正保证软件质量？很多时候感觉测试人员很弱势，开发人员可以无视你，业务人员常以命令的口吻让你做与自己职责无关的
事情。我们按照测试流程日复一日的找BUG、提交BUG、做回归测试，终于项目上线了。我们觉得测试做的很全面，但是项目在生
产上又总是出问题，需要测试组处理故障。有些时候，开发小组开发出的东西质量很高，测试组没有发现什么严重的BUG，且项目
在生产上也未出过问题。是否是以发现、修复BUG数量来考察软件质量，异或是以开发组成员的素质来做考量。我们测试人员是否
能够保证软件的质量呢？如何保证？若非保证质量，我们又是在干什么呢？若要保证质量，我们又该如何做呢？

测试老兵：
        长久以来，测试人员总是被当做质量保证人员，但作为一个测试老兵，凭心而论，测试人员或团队却不能保证高质量的软件产
品。举个例子，软件产品的最初版本，通常都是有很多质量问题的，这是一个非常普遍的现象，小公司的软件产品是这样，大公司
的软件产品也是这样的。难道是这个版本的软件产品没有测试人员么？还是测试人员的水品不行？显然都不是。另外一个现象就是，
很多成熟的软件产品也会出现很多质量问题，例如很多大型软件基本上每个月都有补丁以及安全漏洞。那么到底是什么原因呢？其
背后的根本原因是测试人员无法保证软件产品的质量。有了测试团队，并非一定能够解决质量问题，并非一定能够保证软件质量。
有了好的测试团队，也未必能够百分百保证软件的质量。比如，现在所有的楼房建设都有质量监理，但是楼房质量问题仍然层出
不穷，显然监管机构不能绝对保证质量。所以，单凭测试人员也是无法保证软件产品质量的。测试人员从事测试活动是对软件产品
的质量做出系统、全面、有效的反馈，开发人员依据这些反馈信息，进一步完善软件产品，进而提升软件的整体质量。


困惑二、测试人员的价值在哪里？
测试小兵：
        如果测试人员不能保证软件的质量，那么测试人员到底在干什么？价值如何体现呢？

测试老兵：
        既然测试人员不能保证质量，那么测试人员的价值又在哪里呢？我也曾多次问过自己，最后总结出测试人员的价值在于为产品
或项目的开发提供有价值的质量反馈。这里面的有价值，应该体现为深入的，系统的和犀利的见解（Insights），另外这些见解应该
和软件质量息息相关，这些都是质量保证的一个重要环节。而质量保证本身是由整个项目组共同努力的目标或结果，而绝非测试人员
能够独自保证的。对于日常的测试活动，例如功能测试、性能测试、易用性和安全性测试等，这些活动的目标都是为软件质量提供有
价值的反馈：其包括不同的层次和类型，例如产品缺陷，设计优化建议，用户体验反馈等。从大类来说可以分为产品属性，用户体验
和流程优化三个方面。 
　　测试人员提供的价值和医生为病人提供的价值很相似：医生为患者提供了关于健康的有价值的反馈（医嘱、处方），但是不能
保证病人一定能被治愈。医生做了很多检查工作（望、闻、问、切），就像软件质量的度量指数（质量的六大特性）；医生开的处方
就像测试人员提供的质量反馈（提交BUG）一样，病人根据医嘱、处方改变不良的生活规律、状态，重返健康，开发人员依据测试
人员提出的BUG列表对软件产品的质量做进一步提升。 另外，优秀的测试人员往往是产品的专家，同时也是非常了解客户需求或是
精通业务的，所以测试人员若能够站在这个高度对软件产品提出建议，那一定是非常有价值的。


困惑三、小型团队的开发测试流程如何设计才能达到高效？
测试小兵：
       有人说，在稳定的项目团队中，测试和开发是配套的。是否真的是这样呢？
       组织（人）、技术（工具）、流程（过程）是影响质量的主要因素。那么，在小型团队中如何制订合理高效的开发测试流程？

测试老兵：
       稳定的团队中，各种人员的配备肯定是配套的。不合适的人会自己离开的。       
       以前在一家公司做测试，感觉做测试太难了。为什么这么说呢： 
           1.没有需求分析的概念，一边开发一边熟悉需求。需求变更不做管理（需求变了，功能变了，代码变了，测试员还不知道）；
           2.开发很少自测代码，没有开发文档、也没有数据库设计文档。随意修改代码，无测试版本、无测试环境；
           3.研发人员修复已发现缺陷时引入新的缺陷的比例很高；
           4.项目流程不严谨，没有节点或里程碑的概念。做一个小项目，开发成本高、测试成本高。
       总之就是各种痛苦。下面详细说明：
       第一点：需求做的不好，最后出来的东西（水杯）和用户期望（保温杯）有较大差别。需反复修改，才能达到可用的程度。
       第二点：不注重代码质量。系统集成测试压力大，且修复BUG时修改代码引入新的缺陷往往难以及时发现。
       第三点：测试、开发、需求分析、用户（需求提出方）的沟通成本高（测试很难接触到用户，需求不易把握）。
       第四点：人为因素。需求文档，测试环境，有效沟通。

解决办法：
        项目流程大体上是参考瀑布、V模型等标准模型，再结合具体项目或产品的实际情况，以实际情况为出发点来设计。流程设计
的好，项目整体成功就更有把握（或者说，出大问题的可能性就小）。在此基础上，结合人员安排、工具使用，最终保证项目的
成功。

质量的三要素：
    人员：即组织。组织的目的是最大程度的释放工程师的生产力，而不是限制他的创造力；
    技术：即适用工具。在哪个层面关注质量，着眼点是什么？使用什么测试工具？标准是什么？
    流程：即过程管理。不应该只关注入口、出口。更进一步，应该抓好测试的过程；

总结：
        松散的测试组织、管理一定会带来一个差强人意的结果。不是测试流程不完整，而是测试过程不可控，项目或产品质量的不可
控。其实，小型团队中比流程更重要的是人员的素质（一切伟大的人类活动中最重要的因素就是人），最基本的就是质量的意识，
负责任的态度，不断学习、不断反思、及时改正的工作作风（推卸责任和踢皮球是团队的毒药）。
        法制和法治是迫不得已的做法。中国人很聪明，法制只能是一段时间有效，而法治则是组织失败的标志。团队组织是一门艺术，
应该以目标、使命、价值观来凝聚人心，综合起来就是企业文化的概念。目标、使命、价值观总是在公司遇到争议性问题的时候
起到决定性作用。公司向什么方向走，用什么人，不用什么人，这些都是由公司的文化所决定的。
        有句老话：治大国如烹小鲜。什么意思呢，就是告诉你（管理者）不要老翻，翻来翻去，鱼还没熟，可能就让你翻烂了。如果
用的火又很大，那么抱歉，你不仅鱼肉吃不到，可能连鱼汤都喝不上了。中国人有老祖先传下来的朴素的智慧，我们期望的是垂拱
而治，无为而治，什么都不做，却什么都做好了（关键点就是无为而无不为）。


困惑四、到一家新公司如何开展工作？
测试小兵：换工作到一家新的公司，做为一个测试人员如何开展工作？

测试老兵：一方面，尽快熟悉人员、熟悉流程、熟悉业务、使用的技术、工具等；另一方面，多沟通交流。主动、积极的去做事情，
                    如果沟通少、比较被动，结果往往很不好。总结起来就是快速进入那种by default的状态（默契配合，通力携作）。


困惑五、领导说：“给你一个月的时间测（代码开发完成后）这个项目，你能不能给我保证质量！”  这句话是否正确？
测试小兵：我的疑问是只做系统集成测试（涉及覆盖度的问题：需求文档还原用户原始需求的程度、代码实现覆盖需求文档的
                    程度、测试设计覆盖需求文档、代码实现的程度、隐性需求的覆盖度），是否能够完全保证软件产品的质量？

测试老兵：首先说保证质量是一个什么概念？我觉得满足需求规格就可以了。至于需求规格是否忠实于用户原始需求，那不是这个
                   场景里tester考虑的范围。其次，只做黑盒测试完全可以满足软件产品对于质量的相关诉求。  




  

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试管理频道！