软件QA如何避免软件质量过程控制的悖论

软件QA如何避免软件质量过程控制的悖论

　　软件怎么编程,国外设计软件,上网管理软件5月28日，宋老师的网安加社区线下沙龙活动，华为与腾讯系的高级项目经理，潘老师，莫老师，还有2位美女学员，是我第1期软件质量训练营的学员，在开放、放松的环境下，大家交流项目管理的经验和心路历程，还有社区提供的免费美食哦，与大家交流的非常开心。也欢迎大家报名下期的活动！！

　　我想这也是很多SQE同学从管理硬件到管理软件时遇到的难题，SQE通常管理供应商的方法也是：选、育、用、留，常用手段就是审核，延伸各类审核，然后是推动问题改善辅导，当然重点是对各类质量特性的管控。汽车行业的5大工具，在对硬件和生产环节，还是非常有效的，但是应对软件时就感觉不适用了。

　　因为，软件与硬件生产制造过程，有很大的差异。我们针对硬件的生产制造过程，其实主要就是控制变异，使得过程保持一致性，生产过程重复度更高，追求的就是可重复的过程生产出一致的产品。

　　1、软件的每一次生产过程，生产的产品绝对是不同的，因为完全一样的产品，对软件生产而言是没有意义的。因此，而结果决定过程，因此每次过程必然也不一样；

　　2、软件生产的各环节，主要是靠人的复杂的脑力活动完成，相比较生产工艺环节，不确定性更强，而且难以控制，自然导致过程的波动性会越大。你如果用MSA/SPC，这类工具来看，可能会发现，过程系统根本就不可能处于传统定义的统计过程稳态。

　　3、软件的可视化程度低，与硬件的直观相比，软件显得很不直观，入眼的全是代码与字符串，但代码之间却存在逻辑上系统分层关系、互操作，如果没有软件技术背景，根本没法从一堆字符中去理出他的结构，更别提关键特性了。因此，也导致做硬件FMEA得心应手，一到软件FMEA就难以入手。

　　4、通过审核方式来确保供应商质量，在软件会形成悖论。因为，软件质量过程变异较大，因此，对于该过程的QA而言，主要对研发贡献在于赋能以及提供更多的信息，从这些变异中学习，协助快速调整过程执行的方向。

　　如果，通过强监管保证执行的完全一致性，会导致研发过程丧失“适应性”，而适应性对软件过程而言是更为重要的。也导致了，过程监管的悖论。

　　5、对软件过程审核，也没法保证执行的一致性。在生产工艺中，我们可以直观检查，一线工人执行与工艺的一致性，但在软件上是没法去确定的。即使，你坐在他旁边，看他写代码，所有的编码规范、设计规范都符合，也没办法确定生产出来的代码就符合要求的。

　　当然，针对软件质量体系化要求，目前也有CMMI与ASPICE这些体系可以借鉴参考，但这些体系都是只要求做什么，并没有给出具体应该做什么，即使严格按这些体系要求做到了，也没法完全保障质量。

　　宋老师在软件质量课上讲过，软件的缺陷空间是未知的，我们实际在以有限的已知去应对无限的未知，所以，质量保障的方式，也需要从收敛向发散转变。

　　我们要认识到，软件质量问题最底层原因是，逻辑的复杂性、组织沟通的复杂性，因此解决软件质量问题应该回归到这些最基本的要素。

　　Ken写了一本他在苹果职业生涯的书，名为《创意选择：乔布斯黄金时代的苹果设计流程》写道：

　　我看到很多关于敏捷、epics、Scrum、故事点等的推文，但这些都不重要。之前，我们在苹果没有使用其中任何一项，我们照样能交付最好的产品。

　　我在推特上读到的那些最常见的方法都没有帮助我们开发出最初的 iPhone。哦，我们甚至连产品经理都没有。

　　你知道什么帮助了我们吗？一个清晰的愿景，以设计为主导的开发，每周向决定下一步做什么的人做演示，跨职能团队之间的清晰沟通，真实的反馈，为实现目标根据实际进度做的风险管控。

　　大概在这些简单的想法之上加上各种涂上猪油的过程是很诱人的，我的建议是：不要这么做，简单的流程,才是最有效的。不要忘了目标是交付出色的产品，而不是构建最复杂的流程。

　　大家有种思维惯性特别QA，一遇到问题，最先想到的就是在流程上打补丁，但这在规避一部分问题同时，也使得流程复杂性在上升，反而会导致流程复杂度提升，软件的环境系统出错概率加大了。

　　因此，软件QA，要时刻记住，保证过程的简洁精益。审核的目的，是学习和纠偏，而不是为了强监管，控制变异。

　　基于此前1.3版，PPQA过程中的问题，在CMMI 2.0关于QA的实践域有两条新增的实践：

　　这条实践是要求，质量控制重点在此前容易出问题的地方，而不是拿着一张通用的检查单去检查所有的项目。

　　也就是说，要求QA需要从过程执行的差异信息中，识别出不适用或更好的过程实践，作为过程改进的来源之一。

　　知识星球已积累精品资料2600+，已经有560+星友加入，内容还在持续更新中，欢迎加入！！