“质量”一词，再来谈谈这个老生常谈的话题。当然，都是个人的一些观点和总结，不同意可以拍砖或者来探讨。
　　“质量”这个词用得太普遍以至于混乱，有时候它表示质量这个指标，有时候它隐含质量好的意思。而且不可避免的，好的质量常常和它的反面联系在一起，好像《中国质量万里行》，或者《央视3.15晚会》，列出的都是质量方面的问题，好像很少宣扬质量好的产品。所以很多时候，我们看质量是从反面(缺陷，或者质量不好的地方)来看的。这跟我们总喜欢听成功人士怎么成功，却不喜欢听失败的人士怎么失败一个道理，容易产生判断偏差。因此，在下面讨论的时候我也会用或正或反的例子来论述。
　　Quality scope 1： 实现与需求一致
　　这一点蛮好理解，即实现客户要求的功能。这是一个很基本的要求。但是这是一个可以轻松实现的目标吗？显然不是，面临的困难有很多，诸如：
　　需求真的清晰吗？客户真正想要的跟表达出来的一致吗？项目经理理解的跟客户表达的（或真正想要的）一致吗？
　　需求实现有技术难度吗？
　　项目时间足够实现所有需求吗？
　　以上三点我们一一道来，首先是第一条需求沟通、传递的问题：
　　我们的做法：
　　编码前用AXURE原型图跟客户沟通、确认
　　需求沟通后，整理需求说明书给客户签字确认，以此确定我方理解与实际需要无出入
　　这种做法的优缺点：
　　通过提前项目可视化（所见即所得）和用户签字确认的方式，可有效避免返工，大幅降低项目风险，并可在项目验收结算时提供必要证明。
　　不足之处是，UI设计时更多的从页面美观性出发，可能会设计出客户没有提的需求，或逻辑上不合理的功能字段，或者技术实现难度较大的呈现方式， 导致其他成员对需求产生歧义， 甚至导致项目范围定义不清、项目严重拖期、预算偏差过大等严重后果。
　　应对策略：
　　n  需求沟通时项目经理、UI、测试人员共同参与；
　　n  UI设计完成后，项目经理、技术骨干、测试人员对UI进行仔细的沟通评审；
　　n  评审完成后制定专人编写需求说明书。
　　第二条--技术实现的难度：
　　这一点也好理解，是客户想要某种效果或功能，但我们没做过也可能不知道怎么做，短期内也难以通过学习来找到解决方案。举个例子来说，客户想要做一个产品类APP，客户想要产品可以按多种样式来排列，比如下图：
　　这是一个普遍需求的功能，但如果我们没有相应的技术积累，项目周期又短，那么我们可能无法去实现，无形中降低了项目的“价值”。如果必须去实现，可能项目要拖期。。。
　　我们的做法：
　　开发自己的框架，建立框架培训体系，完善公司的组织财富库。
　　这种做法的优缺点：
　　as u know，一般而言产品是比项目的利润高的。因为项目每次都需要重新开发，而产品某种程度上可以说是“一劳永逸”。项目常常担心项目会不会拖期，而卖产品不用。其实框架也是一个产品，一个好的框架可以为项目的成功提供多大的助力，相信不用我再赘言。
　　我们需要做的：
　　开发并持续完善java、.net、Android、IOS、PHP框架，微信管理平台。
　　Android：
　　给大家提供一个链接：http://download.csdn.net/album/detail/2225，这是一个开源的Android空间库，上面有可变布局、左右滑动删除item效果、listview动画效果、聊天表情实现及刷新聊天记录、加载网络图片、testview自动提示输入的源码。
　　微信管理平台：
　　我这里也有一整套方案和源码，需要的可以问我要。
　　ps 在缩短项目周期方面，我部门的要求和建议还有：
　　系统测试阶段开始，对数据库结构的改动须用sql脚本进行。并在版本发布时将脚本一并交于测试员--该阶段以后数据库结构变动较小，因此不会给开发人员造成负累。
　　对测试的要求：bug的描述需附加截图，并给出清晰的修改期望--减少因bug描述不清而耗费的时间；
　　对开发的建议：bug解决后，建议给出问题根源和解决方案，这是一项利人利己的工作--测试人员可以通过BUG的来龙去脉决定是否做一些bug预防措施，即使没法做预防，测试员在遇到类似的bug时也可以“凭经验”快速定位问题根源，进而降低bug修复时间。
　　Quality scope 2： 一些不言自明的要求
　　为什么说是不言自明呢？比如，一个人买洗衣机的时候，可能只会问一下品牌、价格等，可能不会问耗电多少、噪音多少分贝。这并不代表他没有这方面的标准，而是“不言自明”。 如果事先没有说明，这可能会带来一些纠纷，但是终生产这样的洗衣机的厂家一定是这些问题的受害者。因为大家都会知道这个牌子的洗衣服超耗电，而且噪音大。而如果只按照第一个scope的要求，它可能是一个很合格的产品，而且或许衣服还洗得挺干净的，通过了QA的测试。
　　对一个软件系统来说，这方面的要求有安全性、性能、外观、稳定性、兼容性等等。
　　我们的做法：
　　GUI：已制定相对完善的《设计、开发测试规范》。以后需加强容错性的处理。
　　安全性：已制定《安全测试指南》，发现了问题以后即对系统或框架进行完善。
　　性能：需要在需求中做出更明确的要求，并积累性能调优策略。在典型的系统中建议添加用户行为记录，为该类系统的性能测试提供精确的数据积累。
　　兼容性：目前已经积累了不少《兼容性常见问题和解决策略》，以后继续补充。
　　稳定性：系统上线前，采用压力临界点进行7*24压力测试。这样可以发现大多数内存泄露和数据量积累后暴漏的问题。
　　Quality scope 3： 设计符合用户的需求
　　在scope #1中，我们提到好的质量的起码的条件是实现了宣称的功能。那么引伸出另一个问题是，设计本身是合理的吗? 也可以说，用户想要的是合理的吗？
　　我们或多或少的都遇到过这样的情况：客户提出一个需求，我们也跟客户确认了，但是过了几天客户又提了一个新想法，可能新想法还跟之前的想法是冲突的！而终我们觉得客户一直在变想法，需求改了一遍又一遍。后费了九牛二虎之力终于交付了，客户还总会抱怨我们的系统质量不够好，会给售后服务部门提一个case过来，提出他们的合理(从他们的角度确实是)要求。
　　我们的做法：
　　目前来讲，地产全流程方面的业务，或许还算不得专家，但相信我们的产品拿出去，也可以当得一个解决方案。现在跟商派达成合作，不久的将来在电商领域也能迅速积累起自己的口碑和客户。但是在其他方面呢？我们做过不少堪称行业典型的项目，但却算不得“解决方案”--个人觉得如果想叫解决方案，起码得用同一个系统服务过至少两个客户。
　　对于我们测试人员来讲，要解决这样的问题，可能有两个方面的要求
　　1. 应该更多的从用户的角度来考虑问题。也是常说的customer insight，从这个角度我们不是完全被动的按着设计走，而是可以挑战它，质疑它为什么做成这样，至少要知道为什么。
　　2. 需求阶段介入（具体工作请查看我写的《如何做好系统测试》）。一开始应该参与到产品的设计中，并且从用户的角度给出自己的意见。当然，这一部分也依赖于行业知识和个人的经验。
　　以上两个方面，对测试人员来讲，是挑战，因为要求更高了，也是机会，因为工作更有value了。
　　举个近我做的项目--日日顺大盈家APP来说吧。
　　项目简介：这是一个B类APP，主要是做产品分销。客户希望将日日顺商城中的商品，结合时下流行的分销模式进行售卖。具体模式是微店主（分销人）在APP中选货添加到自己的微店，然后通过分享到微信、QQ等平台，买家看到分享链接后即可点开进行购买。客户下单后由日日顺（或体验店）直接发货。每售出一单商品，微店主可获得不同的佣金。
　　针对这个APP，我们在调研阶段，获晓了客户的需求之后，得考虑如何才能让微店主如何喜欢并“依恋”上我们的APP（在上一期《质量简报》中我们提到一个APP成功的标志是让用户“依恋”）。以此对微店主展开痛点分析：
　　对微店主而言，需求阶段可以分为朴素的需求和进阶的需求，这是一个递进的过程。朴素需求是选货、拿现货（有库存、未下架）。一方面寻求高利润的货，一方面是寻求高品质的货，有些线下体验店和线上C端店铺可能只做高端货，只做高端用户，这个时候对品质需求相对会更高。同时，微店主（买家）也会自寻求一些高品质、口碑比较好的实体店（微店主）对接并把关系沉淀下去。