《QA是个技术活》由会员分享，可在线阅读，更多相关《QA是个技术活（5页珍藏版）》请在金锄头文库上搜索。
1、QA 是个技术活 质量是旅程，而不是终点实践篇 做 QA 应该是水无常形，兵无常法。Checklist 、指标仅仅是冰山一角，最关键需要建立的是人对产品质量态度和责任感。我们经常分享结果（模板、流程），为什么做和如何思考做这个事的思维方式更加值得分享，明白当初为啥做这个事，才可以促进态度和理念的复制，否则只能模仿形而失去了最重要的神。当然，各个优秀实践， 可以作为一种案例可以进行货架化知识管理，便于查询。 Ascend P1 是我司的第一款旗舰机， 高层期望开始创造华为的品牌，责任重大，同时 AP+modem 第一款商用， HAP 5.2 首款商用，首款 LCD/TP一体式来料，华为最薄设计，
2、N 个固件新器件 困难重重。最要命的是， Ascend P1 半路接手，同时要求项目提前计划2 个月上市，跟着项目组走过了最疯狂的一段时间，本着找到关键的20%，重点突破，小循环逐步改进的工作思路，做了不少尝试，有好的结果（我们赢得了100 万，），也有不好的结果（改版次数多，VS 试制流程执行不到位），回首看看，有的也有失，简单总结一下给大家分享，欢迎各位方家批评指正。一、确定项目质量工作的思路：认清现状 :1、 上海团队第一次做智能机，能力不足（北研团队软件人均问题单修改能力是1.5 个/天，上海团队最多就是1 个/天），项目团队对项目保质按期交付还是存在疑虑。2、 Ascend P1 是
3、华为公司第一款旗舰机，余总及其重视并且要求提前上市，提出提前2 个月交付的要求，并许诺200 万项目交付悬赏奖（100 万/月），版本经理比较狂热。换位思考，明确工作思路：“ 项目团队不是不希望改进和提升，更多的时候是他们遇到问题不知道如何去改进。” 终端是强项目交付牵引，但是项目运作又是强资源矩阵（至少目前是），项目交付应该还是第一位的，整个项目团队的成员都还是希望能够按期交付，按质量要求交付。新软件平台，新硬件平台，新项目定位，一定会遇到问题，而且是一堆的问题，拿着质量的要求、标准去要求团队达成，是一种质量人员的做法；融入到项目运作中，切实的协助项目组识别关键问题，解决运作过程中的问题，也
4、是一种质量人员的做法。项目按期交付，拼命往前冲的大势无法阻挡，那我宁可选择融入到项目团队中，实实在在的将产品质量做好，切切实实的将项目运作过程中的问题解决。虽然将面临一堆的问题，但是我阳光总在风雨后，不经历痛苦，哪能感受幸福。_ 找到问题关键的 20%，集中优势兵力重点突破，采用小循环的方式逐步改进，成为和U9200 一起奋斗过程中的主要工作思路。二、扮演好几个角色： 1）刹车人（狂热队伍中的冷酷者）如果说质量中最不愿见的是“ 变量 ” ，项目管理中最不乐见的是“ 变更 ” ，那么项目运作过程中最害怕的是 “ 狂热 ” ，团队一旦开始狂热，如果不及时的刹车，那么项目运作必然失控。前段时间我们H
5、R 祈宇，和我交流时说：“ 如果别人离职，我可能还会想法挽留一下，但是你小子太冷酷了，要么不干，要干就一定想清楚了，而且是无法被动摇的。” 没错，在狂躁的项目运作过程中，你一定要冷静，甚至冷酷，要仔细观察，认真分析，拨开迷雾看到本质，因为真相只有一个。 音频 TDD 改版 TDD 是系统性问题， TR4A 后出现了反复，修改音频问题，结果导致射频性能出现了下降，因为需要提升射频性能，达到公司要求的余量要求，急着要改版。要保证修改的有效性， 因此直接回的邮件 “ 不同意改版，需要将修改方案评估清楚”（可惜原邮件找不到了_） ,拉上射频有线、天线、音频、硬件基带的人一起评估修改方案，现场讨论中发现
6、了几个新问题，重新进行方案验证 Tips ： 各部门的研发兄弟都有一个向上的心，都希望自己的领域没问题，往往容易犯顾头不顾腚的毛病。我们希望各领域优秀，但是我们更加希望产品是优秀的，因此就需要取舍和平衡，作为PQA 应该系统的去思考问题，要引导产品达到最佳的平衡，当然建议在平衡的前提下，也可以获取某方面的最优化（卖点、亮点）。在交付压力的牵引下，一定会想方设法的去赶试制，但是多次试制更多的可能是带来资源的耗费，毕竟华为公司每个项目上的资源并不充分。要冷静对待问题，珍惜和把握每一次机会。心若冰清，天塌不惊；万变犹定，神怡气静；尘垢不沾， 俗相不染；虚空甯宓，浑然无物；无有相生，难易相成；份与物忘
7、，同乎浑涅；天地无涯，万物齐一；飞花落叶，虚怀若谷；千般烦忧，才下心头；即展眉头，灵台清幽；心无罣碍，意无所执；解心释神，莫然无魂；水流心不惊，云在意俱迟；一心不赘物，古今自逍遥！ 风云中聂风的冰心诀丰田的案例：大家都知道丰田汽车公司，可能这家公司是当今社会被人研究最多的企业之一。该公司的经营和管理哲学独树一帜，其中最著名的管理模式是 “ 丰田生产方式 ” （TPS），业界称为 “ 精益生产 ” 。“ 丰田生产方式 ” 的核心是 PDCA 。有人说，当一个典型的美国公司遇到一个问题的时候，如果这个问题必须在一年内解决，该企业会用3 个月来做计划，用另外3 个月来执行，再用6 个月来做微调，处理
8、遗留问题。而丰田在面对类似形势的时候，会用11 个月来做计划，用1 个月来实施（根本不会留下任何遗留问题）。这种说法虽然比较夸张，但是它体现了丰田对于PDCA 的独特理解和经验总结。丰田人认为：计划至关重要！只有彻底的计划（从多个角度全面了解了形势、准确地发现了问题产生的根本原因、考虑可能发生的各种变化、以及参与者的认可或者上级的批准后），实施、检查、处理的结果才能高效达成预期的目标。2）公正的中立人 (公正公平，但是一定要保持中立)质量人员在华为的定位是中立的，因此总会有这样那样的纠纷问题要质量人来仲裁，希望得到中立的评价意见。当然在研发内部出现类似情况仲裁还可以，因为我们毕竟还呆在研发区。
9、但是对于出现跨研发领域的时候，和大供应链体系（制造 采购）交流的时候，供应链体系经常认为我们是属于研发体系的，容易存在略带敌对的和我们交流。如此情况下，我们应该如何的处理？Tips: 我分享一下我的做法：1、首先是澄清具体问题，不要和对方陷入到度量指标，考核指标的漩涡中去（影响产品的具体问题都已经解决了，指标不满足要求也难）。2、对于问题要制定应对措施和具体责任人，从问题后续的实际表现去评估活动是否有效和相应的进展（避免出现活动做了，但是没有效果）。3、该踢一脚的还是要踢一脚（忍无可忍无需再忍），当时言辞要客观，避免采用主观类的语言（这个时候就需要体现质量人的专业素养了_）。 U9200-1
10、TR6直通率问题案例： TR6 的时候最容易遇到的就是因为直通率问题，制造体系和产品较劲。U9200-1 爬坡后，为了解决直通率问题，研发体系一直是有人制造现场的（具体的派兵布阵也有一个小实践，在后面和大家分享），组装段的一次直通率从爬坡的20% ，一直稳定到了 85%以上，而且还有不断上升的利好趋势。当时因为SMT 段的一次直通率低，而且不稳定，直接导致全工位一次直通率就被拉到了 80%以下，而且极不稳定。客观公正的给制造体系的各位老大分析了一下U9200-1 的直通率趋势，和TR6 的一些要求， SMT 段的问题很快得以控制和解决。我发的邮件：制造体系回复的邮件：邹总的邮件：制造代表主导直
11、通率提升: 三、 一点点实践，一点点认知： 1） 关于产品质量评估：产品质量评估是QA 是一定要做的，但是如何做，各地有各地的模板，各人有各人的习惯，我的思考和写作方式分享给大家，请各位方家拍砖。质量评估对于领导们来说，是希望看到一份产品质量状态的全貌，能够包含产品各方面的完整信息，它除了用于领导的监控，其实也应该是很够很好的引导版本经理规划后续的重点工作，因此可以联合版本经理一起来写，在写的过程中，同时也是对项目状态的一个梳理。第一期可能比较困难，当时后面的只要逐渐更新即可。我们写一份报告，首先需要列清楚需要体现的维度，然后是收集写作素材（往往会有现成的素材），最后再用客观语言来表述。原始的
12、素材不一定需要重新开始，往往周围的领域已经有人在做了，因此要注意积累渠道和信息源。积累人脉和渠道的最好方式是分享，将你的工作成果和他人分享（包括业务部门的人），尤其是提供信息给你的那些兄弟，并且要心存感激。 有感于李志其实你不懂项目管理对于产品质量状态，我通常会从如下的角度思考，当然针对不同的项目背景，所处阶段进行调整，这个需要从实践中积累经验。需求实现：在TR4 之前需要重点关注，尤其是软件需求。可以联合SQA 做些事情， Ascend P1 就很感谢于姐姐，组织软件、测试、SE 等领域做了三次需求实现梳理 排序，明确下来哪些必须在啥时间点完成，哪些需要CCB 裁剪。因为需求的颗粒度不同，很
13、多细节上把握不到，Ascend P1 需求评估会上明确哪些可以裁剪、哪些必须实现后，对于实现过程中的细节问题，允许通过CCB 的方式进行裁决。 （对于渠道销售的可以参考操作，对于运营商定制的，一定要和运营商PK，北京这点应该做的挺好，上海火候还差点。）软件单元测试：现在项目都敏捷了，单元测试如何做，如何评估充分性，没有啥心得，我一般都咨询SQA。 硬件单元测试：主要关心没有测试通过的项目，对于新器件的验证情况也需要重点关照，我没有现成的Checklist ，更多的是和开发人员、器件组负责人交流验证方案和结果。建议多看看硬件组器件相关的案例，测试对于器件替代的方案，供应商器件出厂的测试要求，带着
14、疑问去和器件组的兄弟们交流（我作为QA 参加过 LCD 、音频的器件组工作，梳理过音频流程、整理过音频小组的运作方式。），花点功夫在平日，积累交情的同时也能学到不少东西。硬件测试（含可靠性测试）：除了关注测试的结果和发现的问题以外，我更关心的是测试的覆盖度（所有用例是否都覆盖，V 试制和 VN 试制是否都完成应该的测试覆盖）和问题发现趋势（如果前几次测试没有问题，但是后面有问题，一定会追问一下为什么），历次修改方案也需要和测试用例进行一个比对，防止方案遗漏。Ascend P1 这个工作其实是我提供想法，工具表单的支撑，数据整理工作基本上都是硬件测试接口人做的，需要感谢一下陈雪蓓MM。 软件测试
15、：前期更多地都是关注DTS 上的问题，Ascend P1 因为和 Ascend D1 是同软件平台，所以修改问题评估的时候一直是一起评估的，尽管工作量大点，至少避免了遗漏。其实还有一个不同软件版本的关系树可以参考，软件组兄弟应该是有在维护的，我前期基本上是通过交流获取方法，去确定评估方案，最后看到这个树的时候，后悔了好一阵子。这个树可以帮助QA 理清楚问题评估方案，以及关键问题的修改合入策略，简单有效。准入测试、Beta 测试、现网测试：这个是测试经理制定的，只是在方案确定的时候，需要和测试经理交流一下，我是借用的信息。就是在识别和评估发现的主要问题上和测试经理交流了不少。Ascend P1
16、测试这块的信息基本上都是测试经理钱群JJ 总结的，非常全面 完整，我就是应用 提炼。试制问题： DFx or 试制代表手上有非常完整的试制问题清单，最好Review 一下，根据经验判断一下那些是TOPn 和必须解决的。我有几年制造端产品质量管控的经验，所以判断相对比较容易，其实就是判断此问题是否影响产线效率，因为产线进行的是机械的、重复的操作，简单的才不容易出错，高效的才容易落实，对于产线问题处理要记住“ 简单就是美 ” ，所以解决方案重点要思考工具 方法的辅助，尽量减少配置或者选择。其他的问题比例、危害度之类的需要辨证的看，不要被数字欺骗，PQA 有机会还是多去产线转转，经验还是需要积累的。Ascend P1 有一个关于返工的优秀实践，对于产线上出现的故障机维修后，统一升级软件到PT 测试之前，然后直接往下走流程，深得制造兄弟的喜爱，因为没有那么多状态需要控制。对比北研的返工升级方案，每个测试工位的工具都有返修流程设置，我们研发的角度想，是给了你很多的选择，可以从不同的工位进行返工，但是我们似乎忘记了，产线玩的是海量制造，不是手工
