作战原则

彼得.德鲁克高度评价了美军的各种制度，他提出“在充满危险和不确定性的数千年历史中，军队孕育了无数智慧，他们大多也可以在军队以外的机构发挥作用”。不少优秀的管理者都有不少从军的经历，让我对军队的战术产生好奇。期望能从战术层面对QA工作有所启发。

所以试着参考《作战行动》中的几个维度来思考工作项目上的大体原则，几个维度分别是：目标，进攻，集中，节约兵力，机动，统一指挥，警戒，奇袭。

目标

军事层面

目标原则是所有军事行动的原动力，在作战和战术层面上，通过确立目标，集部队一切行动于达成上级指挥官提出的目标。

如下图，截取自美国陆军2008版《作战纲要》

项目层面

在我们软件项目交付时，通常的目标描述是：满足sow文档中列的要求，或满足客户其他形式的需求，

针对测试同学来说，通常目标是验证系统是否符合prd文档这类需求、产品文档。

QA的职责，我理解为：围绕着测试同学是否能按时、有质量的完成目标，其所展开地从人力、能力、时间、技术、资源（如测试环境）、以及对外协助上做方向指引，后勤保障。

吴晓鹏大佬（同事）给予了简单明了答案：前期搭台子，中期看台子爆风险，后期验收。其中前期具体指：人员阵型，用例设计，缺陷管控，用例进度管控，汇报...规范，准入转出标准。

实际项目中会有些偏差，如之前的展会项目，有很大一部分内容在做具体的测试执行工作。

进攻

军事上

进攻不是鼓励形式上的进攻行动，而是要以主动的态度向敌人强烈灌输我方意志，即进攻不是形式上的原则，而是态度上的原则。《野外要务令》称其为“主动原则”

项目上

平常我们所说的项目失控，可以理解成已处于被动的防御阶段。理论上在项目越早制定质量规范流程，“进攻”的胜算概率越大。实际中因考虑到成本等因素，QA和测试团队在开发阶段，或将近提测前才介入。甚至有的项目在质量失控了才想起需要QA介入，如之前的金币项目。

在主动原则下，开发同学对提交的代码负责，主动自测，主动与pd, 测试等沟通；同样测试对质量负责，与pd, 开发加强沟通，深刻理解业务与代码的实现方式，主动对质量负责，而不仅仅只是生硬的依据需求文档，生硬的只根据用例执行，能主动得在项目过程中、测试过程中动态的补充与完善，适当添加探索性测试。

在实际项目中基本没遇到提测后需求不变更的，有的是客户原因，有的是沟通偏差原因。站在客户的角度进行探索性测试往往能发现意想不到的问题。

集中

军事上

为了达到破坏性或建设性的成果，指挥官要把战斗力的效力集中于关键的时间和地点，但是战斗力的效力不是无限的，而是有限的。

所谓集中时间，指同时对多个关键地点投入战斗力。所谓集中地点，指对一个地点投入战斗力，这是陆战的关键，自古以来一直备受重视

如作进攻作战时，需要最少3倍与敌方的兵力。

项目上

在测试人力方面，一般测试人力是开发的三分之一。当然根据不同项目阶段比例适度调整，如开发阶段，测试阶段，客户验收阶段。根据被测系统的类型不同也影响较大，如后台系统，前端产品，中间件。

项目中测试人力的投入多少，QA基本只是建议与报风险，还得有pm根据实际预算等决定与推进。

节约兵力

军事上

通过在次要战场上配置最小限度的最小战斗力，指挥官可以将战斗力集中于主要战场上。

项目上

在工作中有并行任务时，一般会有区分优先级。但要像军事上“在次要战场配置最小限度战斗力”，这点经常做不到位，或就不是这么考虑的。

1. 往往从客户角度来说，没有最好只有更好。一般都催着多测试，想要挤压出产研团队所有的战斗力潜力，如使用过程中提出些非主要模块、功能的轻微bug，经常会责怪这样明显的问题都没发现等这类话术。

2. 在项目中往往到最后阶段，实在无法按时完成交付任务了，才讨论优先交付XXX，其他XXX放后续版本。如能在早些时候，如开发前，开发过程中，提测前等定好规则也许效率会高很多。

3. 测试投入多少人力上不是QA能决定的，但某些时间段上的测试投入能灵活操作下。如之前的XX项目集成测试同学在周末加班，按以往习惯都得6点后才下班。但有的同学早已经结束任务了，让他们早点回去休息也是一种“节约兵力”（从某种程度上这样我承担了风险，做得好没关系，如果当天工作出问题得承担责任）。

机动

机动是指：在战斗中为了占据有利地形而进行的部队移动。

在XX云的原厂中有个X开发小组，在XXX项目有次接触，确实牛叉，有种特种部队的效果。

项目间的调配人力主要是pm的责权范围,在QA层面能做是, 尽量协调产品，开发，UI等项目相关方参与的质量保障工作中。

针对风险尽早让ISV（外包）提供预案，如前期测试、开发人力投入不足的风险，需要让ISV（外包）提供预案，是否能在遇到问题、风险时能及时投入新的人力。如果有人在项目关键时间请假、离职，是否能有人顶上。

统一指挥

拿破仑：宁愿要一个平庸的将军带领一支军队，也不要两个天才同时领导一支军队。

项目中通常上面是客户，下面有1个或多个ISV（外包）。涉及到多方协调合作时，是由GTS的pm拉上各方协作。

协调各方ISV（外包）测试同学协作是QA的工作之一，有问题，有风险的往往不同团队系统之间的对接部分，很容易产生遗漏、联调不通等问题。

记得之前一个XX的项目，前后端是不同开发人员，客户直接问前端开发同学，功能有没开发好，前端开发说好了。实际情况是后台还没开发好的情况下， 客户就理解成功能开发好能使用了。我对开发TM说，这些ISV（外包）的开发人员怎么责任心这么差，只管自己部分，明明功能不能用还说开发好了。开发TM说，这就是管理的问题。一下子点醒了我，不能靠自觉、责任心来要求每个人。像这件事件应该有人整体跟进，并且有人统一的面向客户汇报，而不是谁都可以面向客户。

警戒

警戒就是保护和维持战斗力（转移和机动，作战情报，活动力保持战斗力，任务指挥、防护、领导力和态势感知能力），是部队和机关为自我防护而采取的各种手段。

情报是处理后的信息，不是对海量信息原封不动的上报，不是简单地收集信息，要有自己的判断。如在一次东盟展会项目上，有个需求变更急着要上，测试负责人反馈说时间肯定来不及，使原本忙碌的节奏雪上加霜。我第一反应是要马上上报风险。还好对应人不在，让我冷静下来去核实情况，才发现需求变更没想象的那么大，实现目标还是有可行性的。

奇袭

QA比较多的还是在于技术上支持，与方向上的指引。特别是重复性高的工作，或高工作量的工作需要思考是否有好的工具、技术手段来快速高效实现。