今天就“质量”一词，再来谈谈这个老生常谈的话题。当然，都是个人的一些观点和总结，不同意可以拍砖或者来探讨。
“质量”这个词用得太普遍以至于混乱，有时候它表示质量这个指标，有时候它隐含质量好的意思。而且不可避免的，好的质量常常和它的反面联系在一起，就好像《中国质量万里行》，或者《央视3.15晚会》，列出的都是质量方面的问题，好像很少宣扬质量好的产品。所以很多时候，我们看质量是从反面(缺陷，或者质量不好的地方)来看的。这就跟我们总喜欢听成功人士怎么成功，却不喜欢听失败的人士怎么失败一个道理，容易产生判断偏差。因此，在下面讨论的时候我也会用或正或反的例子来论述。
Quality scope 1： 实现与需求一致
这一点蛮好理解，即实现客户要求的功能。这是一个很基本的要求。但是这是一个可以轻松实现的目标吗？显然不是，面临的困难有很多，诸如：
需求真的清晰吗？客户真正想要的跟表达出来的一致吗？项目经理理解的跟客户表达的（或真正想要的）一致吗？
需求实现有技术难度吗？
项目时间足够实现所有需求吗？
以上三点我们一一道来，首先是第一条需求沟通、传递的问题：
我们的做法：
编码前用AXURE原型图跟客户沟通、确认
需求沟通后，整理需求说明书给客户签字确认，以此确定我方理解与实际需要无出入
这种做法的优缺点：
通过提前项目可视化（所见即所得）和用户签字确认的方式，可有效避免返工，大幅降低项目风险，并可在项目验收结算时提供必要证明。
不足之处是，UI设计时更多的从页面美观性出发，可能会设计出客户没有提的需求，或逻辑上不合理的功能字段，或者技术实现难度较大的呈现方式， 导致其他成员对需求产生歧义， 甚至导致项目范围定义不清、项目严重拖期、预算偏差过大等严重后果。
应对策略：
n 需求沟通时项目经理、UI、测试人员共同参与；
n UI设计完成后，项目经理、技术骨干、测试人员对UI进行仔细的沟通评审；
n 评审完成后制定专人编写需求说明书。
第二条--技术实现的难度：
这一点也好理解，就是客户想要某种效果或功能，但我们没做过也可能不知道怎么做，短期内也难以通过学习来找到解决方案。举个例子来说，客户想要做一个产品类APP，客户想要产品可以按多种样式来排列，比如下图：
这是一个普遍需求的功能，但如果我们没有相应的技术积累，项目周期又短，那么我们可能就无法去实现，无形中就降低了项目的“价值”。如果必须去实现，可能项目就要拖期。。。
我们的做法：
开发自己的框架，建立框架培训体系，完善公司的组织财富库。
这种做法的优缺点：
as u know，一般而言产品是比项目的利润高的。因为项目每次都需要重新开发，而产品某种程度上可以说是“一劳永逸”。项目常常担心项目会不会拖期，而卖产品不用。其实框架也是一个产品，一个好的框架可以为项目的成功提供多大的助力，相信不用我再赘言。
我们需要做的：
Android：
给大家提供一个链接：http://download.csdn.net/album/detail/2225，这是一个开源的Android空间库，上面有可变布局、左右滑动删除item效果、listview动画效果、聊天表情实现及刷新聊天记录、加载网络图片、testview自动提示输入的源码。
微信管理平台：
我这里也有一整套方案和源码，需要的可以问我要。
ps 在缩短项目周期方面，我部门的要求和建议还有：
对测试的要求：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端店铺可能只做高端货，只做高端用户，这个时候对品质需求相对会更高。同时，微店主（买家）也会自寻求一些高品质、口碑比较好的实体店（微店主）对接并把关系沉淀下去。
