Showing progress in an integration plan 通过一个集成计划展示项目进展
An integration plan looks like an anatomy but is in fact a plan. A box, representing a defined set of capabilities for a defined set of configurations and scenarios is approved when all the
specified test case have been approved.
一个集成计划看起来像一个Anatomy，但实际是一个计划。每一个Box，代表了已经通过批准的一组Capability，包括定义好的配置和场景，还有被批准的指定的测试用例。
It is possible to decide to start the integration of the next(dependant) boxes before all the test cases have been approved. The condition for starting can never be a percentage of the test cases. It must always be a predefined subset of the test cases.
当所有测试用例被批准通过之前，决定启动下一个要集成的Box是可能的。但启动条件永远不可能是测试用例通过情况的百分比，而一定是测试用例中的一个预先定义的子集。
When showing progress in the integration plan I never show what percentage of the test cases have been approved. One reason for this is that one correction may make several test
cases no longer OK. Another more important reason is that I do not want anyone saying "almost ready". I always want to push us to complete everything in each box.
当在集成计划中展示进展，我从来没有展示过测试用例通过情况的百分比，其中一个原因是任何一个修正可能引起很多个用例不再OK，另外一个更重要的原因是，我不希望任何人讲“几乎差不多好了”。我总是想push我们完成每个box里的所有东西。
Some say that there are many not so important test cases. My answer to that is that if we have unimportant test cases they should be removed. If we have features that are unimportant they should be removed. If we have unimportant test cases they should also be removed!
有人说有很多不重要的测试用例。我的答案是如果我们有不重要的测试用例那就删除掉。如果我们有不重要的特性也应该被删掉。如果我们有不重要的测试用例也应该被删掉。
If we prepare many unimportant test cases because we are rewarded for having many test cases we are being stupid!
如果我们需要准备很多不重要的测试用例，是因为我们会由于用例多而受到奖励，那就很蠢了！
In my integration planning there is no verification phase after. The "breathing life into" in my projects includes verification.
在我们的集成计划中是没有后续验证阶段的。在给我的项目带来生命的过程中是包括验证的。
Each box is tested, faults are found and corrected. After all faults have been corrected all the test cases will be run once more after the last correction was inserted. This last phase I call verification!
每个box得到了测试，错误被发现和修正。在所有错误已经被修正之后，所有的用例会在最后一个修正引入后再跑一遍。这个最后的阶段我称为验证
Improving our development project management ability(1) 改进研发项目管理能力（1）
Development project capability Statement No 1 - Jack J?rkvik 20120510a
I have been asked to help improving the capability of our project managers. This blog is a beginning statement about what I think is important to improve the ability of Huawei to skillfully carry out development projects. Other consultants are working inside Huawei to set up programmers to increase the skill of project managers - not exactly the same goal I have - more about this point later!
我被请求去帮助提升华为公司项目经理的能力，在这个开篇的博客里，我要表明的是我认为对提升华为项目经理管理项目的技巧和能力而言，最重要的东西是什么，而其它在华为公司工作的顾问所提出的提升项目经理技能的计划，和我想要达到的目的并不一样，这一点，在后面我会更多地谈到！
1. I limit my statements to development projects because I believe that is what I really know.
1.我把范围限定在研发项目中，因为我相信这是我真正了解的部分。
2. The Huawei ability to successfully run development projects is not only about the skill of our project managers. Equally important is the environment that each project is run in. Huawei has a long list of issues that make successful development project management extremely difficult. In fact many project managers are doing a surprisingly good job considering the difficult environment they operate in.
2.华为成功运行一个项目不仅仅是和我们项目经理的能力相关，同样重要的是每个项目所处的环境，华为存在一大串的问题使研发项目管理成功非常困难，因此，如果把项目运行的环境因素考虑进去，很多项目经理的工作已做的足够好，甚至令人惊讶（译者：在问题如此多的环境中，项目经理做成这样已很不错了）
3. In a company where development projects can be successfully run there needs to be a good interaction between line managers and project managers. Another issue we must improve is how we set up responsibilities in each project. The worst issue is in my view that whenever there is an aspect that is considered important we assign another project manager responsible for this aspect. This is just so stupid but we do it everywhere! On the whole we seem to assign too many project managers with very unclear assignment and with even more unclear authorities.
3.在公司，研发项目要成功，需要项目经理和资源线经理有很好地交互，另一个我们必须改进的是我们如何在每个项目里明确职责，在我看来，最糟糕的事情是，我们总是发现有一方面显得非常重要的话，我们就指定另一个项目经理负责这个方面，这种错误是如此愚蠢，但是我们到处都在这样做！总体来看，我们似乎指定了太多的项目经理，而他们的职责和任务都非常不清楚.
4. IPD plays a much too big role in how project managers think. There is very little thinking about the specifics of each project. Successfully setting up and running a development project is about really understanding the specifics of the project, understanding what can be done easily and what will be difficult to do, organizing and selecting people and their interaction based on this understanding. IPD is NOT a model for successfully running development projects. IPD is a model for allowing top management to have some control over how the development resources are used. This a statement that I do not find project managers understand. To most of them IPD is everything!
4.IPD在项目经理的思维中起到了巨大的影响作用，而导致他们很少去思考项目的具体细节，成功运行一个项目的关键是真正了解这个项目方方面面的细节，理解什么是容易实施的，什么很难去实施，并基于这个人是去选择人，确定人们如何交互，IPD不是一个成功运行项目的模型，IPD是个让高层管理者掌控资源如何使用的好模型，这个观点我发现项目经理并不理解，对他们，IPD无所不能！
5. I do not think it is a good idea to set up a clear career path for project managers. I want us to have our good managers switch between line management and project management. If we did this more often the cooperation between line and project would automatically improve! It is true that some people prefer line management roles, others prefer project management. It is very much about personality. People also have different skill sets. But I do not believe the main dividing line is between line and project. Line management roles can be very different and so can project roles. I was never a universally good project manager. I believe I was good at dealing with crisis situations, I was actually used for this also as a line manager.
5.我不认为建立一个“清晰”的项目经理的职业发展通道是个好主意，我需要我们好的资源部门管理者和项目经理之间轮换，如果我们经常这样轮换，在资源和项目线的合作会自动改善，一些人喜欢做资源主管，而另一些喜欢做项目经理，这取决于个人的性格，人们也有不同的技能，但我不认为这道分水线在资源管理和项目管理上，资源部门管理者和项目经理都可以和现在完全不同，大家都认为我是个项目经理，但我从来不是一个普遍意义上的项目经理，我认为我只是善于处理项目的危机，而事实上，我经常被用作资源主管（译者注：这段话是想表达JACK不认可要把项目经理和管理者通道区分开，他们是相通的，而这种区分反而给人一个泾渭分明的界线）
This was only a beginning
这只是个开篇
How to allocate resources in development? 如何进行资源分配？
"It's not easy to do the investment combination management. It's difficult to allocate resources to different projects based on the estimation of the benefits."
“很难进行投资组合管理，很难基于收益的估计来决策在不同的项目中分配资源”。
We seem to have a practice of deciding to run development projects based on what our marketing people decide needs to be developed to be able to offer everything to all possible customers NOT considering what we are able to do! This is an extremely bad practice!
我们看起来有这样一个做法，由我们的MKT人员决定项目要开发的需求，他们总是想向可能的客户提供所有的东西，而根本不考虑我们是否能做到。这真是一个极度不好的做法！
Managers tell me this has been a very successful practice! My answer is that Huawei has been surprisingly successful considering this stupid practice and the success has happened in spite of this bad practice, not thanks to this bad practice! My opinion is that we could have been even more successful and we can become even more successful if we introduce better ways of working!
管理者告诉我说这已经是一个很成功的做法！我的答案是，华为一直以来以为自己有惊人的成功是基于这个愚蠢的做法，而事实上，华为的成功和这个做法没有任何关系，根本不需要感谢这个糟糕的做法！我的观点是，如果我们引入了更好的工作方式，我们过去可以更成功，以后也能变的更加成功！
A better practice is to allocate key people (names) already when we decide to start a project. This means at this point we have decided what to include in a project and basically how to implement the new products/features/characteristics. This means we need to do a lot of good work before we decide to run a project. When we know what to do in a project, how to implement and who will do the work we have a possibility to estimate how quickly we can do it. Estimating is still difficult!
一个更好一些的做法是，当我们决定启动一个项目时，就确定了关键人员（实名），这也就意味着我们已经决定了新项目中要包括的内容，以及大概上如何实现新的产品/特性/特征，也意味着在启动一个项目之前我们需要做很多良好的工作，当我们知道要在一个项目中干什么，如何进行实现和谁会做该工作时，我们就可能估计出要多久才能完成，估计仍然是很难的。
Our ability to deliver new products and features is not limited by the number of people we have but by the number of key people we can use for the specific project! Starting projects without access to these key people does not mean risk of delay. It means slow projects and bad quality for sure - a fact, not a risk!
我们交付新产品和特性的能力并不受限于我们拥有人员的数目，而是受限于可以投入到具体项目中的关键人员的数目。在没有获取这些关键人员的情况下启动项目，意味着一定会出现缓慢的项目和糟糕的质量，它是个事实而不是一种风险了！
Our key people should always be part of estimating the time and people (resources) needed to run a project. Most of our people are bad at estimating because we never ask them to do it! They will only learn by practicing!
我们的关键人员应该总是参与项目所需时间和人员（资源）的估计工作。很多时候我们的人员很不擅长做估计，因为我们从来没有要求他们去做过！他们只有通过实践才能学习提升！
Managers tell me we can not assign people early because we have so many changes and delays. My response is this happens because we do not plan anything at all and when we do we do it badly. This is a vicious circle and someone has to stop it.
管理者告诉我，我们不能较早的分配人员，因为我们有很多的变更和延迟。我的回答是，这个确实如此，因为我们从来根本就没有计划，一旦我们做计划就做的很差。这是一个恶性循环，必须有人阻止去这样做。
We should not allocate people to projects based on the benefits of the projects. We should start projects based on their benefits. The not so beneficial projects should not be run at all! Priorities should not be used for allocating people but for starting projects. Sometimes projects need to be stopped to allow the more important projects to run well! This I have done - very useful practice!
我们不应该按照项目的收益来分配人员到不同的项目中，而是在项目启动时就按照项目收益进行，没有很好收益的项目就根本不应该启动！优先级区分不应该被用来分配人员而是启动项目上应用。有时为了让更重要的项目良好运行，一些项目不得不停下来，我曾经这样做过，非常有用的实践！
Dealing with overload 处理过载
"In many projects, overload happens. This causes delays to those projects and lowers product quality"
“在很多项目中，都有过载发生，这会导致项目的延迟并降低了质量”。
In Huawei I get the impression those who decide what to develop think that R&D people are lazy people. They feel they need to push us hard and that means overload is the only possible situation. R&D people need to work every day between nine in the morning and eleven at night or longer and weekends. Marketing people do not believe that there is any relationship between overload and quality. Also managers do not seem to think the is any such relationship.
在华为，我得到这样一个印象，那些决策开发什么内容的人总是以为研发人员是懒人。他们感觉需要猛push我们，结果过载就成了唯一可能的结果。研发人员需要从早上9点一直工作到晚上11点，甚至更晚，还包括周末。Mkt人员不相信在过载和质量之间有什么关系，同样管理者也不认为有任何关系。
Another issue about overload and quality is that marketing people told me that there strategy is to add a lot of potentially useless features into every project. They know that many of them will never be used. They add the features into the project to be able to win contracts. Contracts are won by having the lowest price and the largest number of features.
另外一个关于过载和质量的问题是，Mkt人员告诉我他们的策略是向每个项目加入很多可能没有任何用处的特性。他们知道其中很多将来不会被用到。他们在项目中加入特性以能够赢取合同。而合同通过有最低的价格和最多数量的特性而获得。
Huawei is not customer focused - Huawei is contract focused!
华为不是以客户为中心的-而是以合同为中心！
Bad quality in the new features is no problem. The new features that the customer will actually try to use will not work well. So far that has not been a problem. We won the contract - all we do is to allocate a large number of developers and testers to make it work after delivery. We cheated the customer but we won because we got the contract!
新特性的质量很烂不是问题，客户将要尝试使用的新特性不会很好的工作。至今这还没有成为问题。我们赢得了合同——所有我们需要做的就是，在交付之后分配大量的开发测试人员来让特性运行起来。我们欺骗了客户，但我们赢得了合同！
Other companies take risks by claiming that all features are supported and they are in fact not! The customer will be told before or after delivery and of course they sometimes get angry but usually a solution is found. Very often the new features will not be used all at once. The features that will be used will be delivered later with good quality. In Huawei the marketing people can instead blame R&D who can not deliver everything with good quality! Marketing are the good guys and R&D the bad guys.
其他公司通过承担风险的方式：声明所有特性都支持，但实际上不支持。客户将会在交付之前或交付之后被告之这个情况，当然客户有时会很生气，但通常会找到一个解决方案。常见的情况是新特性不会被马上使用。特性将会被在后续以高质量交付。在华为，MKT人员不是这样做的，他们只是抱怨研发不能高质量地交付所有东西，因此，MKT永远是好人，而而研发做坏人！
To deal with heavy overload we need to become better at estimating what we can actually do and we need to stand up and not accept overload. In my earlier life the biggest problem in this area was the constant optimism among R&D people. Their estimations were never very good! I have seen a few big projects that have in fact delivered on time, not without high load but on time and with good quality!
对于解决严重过载，我们需要变得擅于更好的估计我们实际能做什么，而且我们需要勇敢站起来而不是接受过载。在我早期的经历中，这个领域最大的问题是研发人员的乐观主义，他们的估计从来没有好过！我见过很少的大型项目可以按时交付，同时又不是没有高负载，而且质量很好！
Our situation is we do not even try seriously to plan well and to resist overload. Overload because of incorrect estimations or different kinds of accidents are natural but we have made it our way of life. Constant overload is one of the main reasons why good people leave Huawei! R&D managers are too soft and they are cowards! It seems this is how top managers want things to be ! I am not impressed !
我们的情况是，我们甚至都没有严肃的做好计划来抵抗过载。由于错误的估计和各种未料到状况的发生而导致过载是很正常的现象，问题是我们已经习以为常了。持续过载是为什么有优秀的人员离开华为的主要原因！研发管理者太软弱了，他们是懦夫！这看起来好像是高层管理者所想要的！我已经感觉不足为奇！
Evaluating projects 评估项目
Evaluating how well a project has been managed can not be done by checking the success of the project, especially not in Huawei. It can only be evaluated by following up the project while it is being run. The reason is that for some projects everything is wrong or very difficult while for other projects most things are right or very easy. Truly for some projects the task for the project manager is mainly to follow and to report on the progress while for other projects it is like leading a boat through an archipelago in a storm without a correct map.
评价一个项目被管理得怎么样不能通过检查项目的成功情况来进行，特别是在华为。只能在项目运行中来跟进项目而进行评估。原因是，一些项目什么都是错误的或者举步维艰，而其他的一些项目大多数事情都是正确的而且很简单。真实情况是，对于项目经理们而言，一些项目就是主要跟进和报告进展，然后一些其他的项目就如同带领一条船在暴风雨之下通过满是岛屿暗礁的海面，同时还没有正确的地图！
Who can assign work to team members 谁能为团队成员分配工作
Doers have one team leader
团队成员拥有一个Team Leader
Team leader assigns tasks to doers - no one else
Team Leader给大家分配任务——没有其他人
Other people, fellow doers or other managers can ask doers for help (an hour or two) but the doer should say no if his main job thereby is delayed.
其他的人员，专家或其他管理者可以向团队成员寻求帮助（1或2个小时），但如果引起主要任务的延迟，团队成员可以说No。
In the OSG managers bring up issues around different projects,
like deciding to allow delaying the main project to be able to support another project in trouble or to support maintenance. The OSG can make decisions to change how we use our people
Between OSG meetings the PDU manager can change decisions made in the OSG but then he must announce this decision to all managers and team leaders in writing!
在OSG上，管理者展示不同项目的问题，比如决策允许延迟一个项目，来支持另外一个处于麻烦中的项目或支持维护。OSG可以决策变革人力的使用。
在OSG会议中间，PDU主管可以修改OSG上的决定，但他必须马上书面向其他管理者和Team Leader宣布这个决策。
第三部分：测试
Tests and numbers 测试与数据
Rewarding people based on numbers of automatic test cases
以自动化测试用例的数目来奖励员工？
I have earlier criticized our managers for basing evaluation of people on numbers and numbers only. Numbers are valid when it comes to money. More money is better than less money and it is said that money does not smell. We all know that this is not true as there is honest money and dishonest money.
我之前评论过我们的管理者，他们用数字并且只用数字来衡量员工绩效。当数字变成Money时是有效的，也总是说钱多总比钱少好。但我们都知道这不是真的，因为钱也有区分是诚实来源的钱，还是不诚实而来的钱。
I have earlier pointed out that planning and following up coding based on number of lines of code is a very bad idea. We still seem to be doing it although some have stopped doing it in our company which I think is very good.
我之前也指出过，基于代码行来进行计划和跟踪进展是很烂的主意。我们似乎还在这样做，虽然我司有的团队已经停止这么做了（我认为这样很好）。
Testing is also evaluated based on number of test cases, not on the quality or value of test cases. The reason may be that it is difficult to evaluate the quality of a set of test cases. This is however no reason to continue evaluating and rewarding based on stupid numbers. Evaluating a set of test cases is hard but doing it by checking their number is not a good way.
测试也同样基于测试用例的数目进行评估，而不是测试用例的质量或价值。其原因可能是很难去评估测试用例的质量。这样就毫无争议的成为基于愚蠢的数字进行评价和奖励的理由。虽然评估一组测试用例很难搞，但检查这些数字并不是好的方法。
Continuous Integration ( CI ) means among other things that we evaluate each software build by means of testing, preferably a good automatic test that can be run every time and that does not consume a lot of time and effort. Normally an automatic test is followed by some manual testing. I find managers give bonuses based on the percentage of tests that are automatic, not at all on how effective the tests are in evaluating each build. This is not very smart, in fact it is stupid.
持续集成意味着我们通过有意义的测试来评估每个软件build。每次可以完美地运行一次好的自动化测试并不需要花费太多的时间和精力。一般情况下，一次自动化测试后也要跟随着一些手动测试。我发现管理者根据自动化用例测试的比例来分配奖金包，而不是评估每个build中用例的有效性。这不是很聪明，事实上很愚蠢。
The test suite used to check each software build needs to make sure that existing functionality and system characteristics have not been ruined. The test suite also needs to be quick so that it can be run with no waste of time. Considering that each software package changes over time with new functionality becoming legacy features we have to continuously modify the test suites used. Automatic test suites tend to become longer as time goes by. This is not really good since it means that running them takes more time.
用来检查每个build的测试套需要确保已有的功能和系统规格没有被影响，也需要运行起来很快这样才能跑起来不浪费时间。考虑到每个软件包都随时间发生变化，之前新功能也变成了老特性，所以我们需要持续修改使用的测试套。而自动化测试套运行也会变的需要更长时间，因为每次耗时更久所以这并不太好。
Evaluating software builds should be done by using one small set of tests plus another set of tests each time chosen based on what has been changed or added in the software package. To do this well the testers must know very well what developers do in each build. I do not see us working like this. Communication between developers and testers needs to improve a lot.
评估软件build时，应该使用一小组测试用例，加上另外一组针对软件包所修改或增加的内容所挑选的用例。如果要把这个做好，需要测试人员必须非常了解开发人员在每个build中都干了什么。我没有看到我们这样工作。测试人员和开发人员之间的沟通需要改进很多。
My main comment in this text is that more test cases is not necessarily better. A higher share of test cases being automatic is not either necessarily better. Running test cases automatically is usually risk free but automatically evaluating the tests is more risky. When designing the test case one has to think about everything that can be worth checking. This simply does not happen. Checking something means it is a working test case. When testing manually the tester can choose what to look into based on knowing what needs to be checked. The automatic test case never thinks, it is only a piece of software doing what it is programmed to do sometimes long ago when everything was different.
我在这片文章里的观点是，更多的测试用例并不是必然的更好，更高的自动化测试比例也未必是更好。运行自动化用例通常是用来发现风险，但自动化评估测试结果也变的更有风险。当一个人设计用例时，要考虑到所有值得检查的地方。说起来简单但却很少有人做。能够检查什么意味着是一个有效的用例。当运行手工用例时，测试人员可以基于所知道的要检查内容而进行一些观测，而自动化测试却不会自己思考，这只是软件的一部分，是很久之前被编写的能做一些事情的一部分，但所有事情都不同了。
A large number of automatic test cases tends to give a false impression of good testing. This is a situation that I believe is common in our company. With our managers' focus on increasing the number and share of test cases that are automatic we push this development in the wrong direction.
大量的自动化测试更倾向于说明了针对良好测试的错误看法，我相信这是在我们公司很普遍的情况。因为我们的管理者只是在聚焦于提升自动化测试的数字和比例，我们把其发展推向了错误的方向。
What should we do? When evaluating how well a test case suite tests a new software package we should use the internal customer as a basis. Most projects, platform projects and product projects, will regularly deliver new software for testing by another team. Platform teams deliver to product teams and product teams deliver to solution teams. The platform teams should see the product teams using their platform as their platform and the product teams should consider the solution teams to be their customer.
那我们怎么办？当评估一个用来测试新软件包的测试套时，我们应该以内部客户为根基，大多数项目，包括平台项目和产品项目，会定期的向另外一个团队交付软件进行测试。比如平台团队向产品团队交付，产品团队向解决方案团队交付。平台团队应该看到产品团队使用他们（新交付）的平台作为新平台版本，产品团队把解决方案团队看成自己的客户。
The whole development team including system design, development and test is responsible for delivering on time, for content and for quality. However the testing part of each project is responsible for knowing, not for delivering high quality. So upon delivery to an internal customer the most important aspect of test is to be able to communicate how good the delivery is in an understandable way. The customer needs to be able to know what he can use the delivery for.
整个开发团队包括系统设计、开发和测试，为按时交付、保质保量交付负责，当然，每个项目的测试部分只对了解掌握质量情况负责，而不是交付高质量。所以一旦交付给内部客户，测试中最重要的方面就是要以一个可理解的方式去沟通交付的质量情况，客户应该知道能用新交付的版本做什么。
If the test report describes a certain functional area as being OK and some other aspects being bad this is not good but OK. If however the test report describes everything as being good and the customer finds this to be untrue on his first day of testing then the testing done was bad (or maybe the testers actually know but are lying). This is how we should evaluate the testing we do!
如果测试报告只是说一部分功能领域OK，而其他一部分不好，这样虽然情况不好但却是对的。而如果测试报告说什么都很好，但一旦交付给客户，客户第一天就发现这是不正确的，那就很糟糕了（或者测试人员知道事实情况但在撒谎）。这就是我们应该评估测试的方式。
Evaluating a system is all about finding out how well it works - how fit for use it is !
评估一个系统就是关于发现系统运行的如何-多么适合使用。
The evaluations we use to rate the efforts of our people must be value based. Where we have customers (internal or external) their judgment must be the basis of our evaluations. I do not see this happening!
我们用来评估人员成就的方法必须是基于价值的，当我们拥有客户时（内部或外部客户），他们的判断就是我们评估的基础，但我并没有看到这种方式有所发生！
Organic testing 有机测试
Making a system work following a plan based on the system anatomy I call organic integration. By making a box work I mean testing it formally and correcting all the faults we find that are real faults, be they coding faults, system design faults or requirement faults.
让一个系统按照基于Anatomy的计划工作的方式，我称其为有机集成，让Anatomy中的一个BOX工作的含义是：正式地测试而且修正所有我们发现的真正的缺陷，不管是代码缺陷，系统设计缺陷或需求缺陷
After completing a box later development work or fault correction work to make other boxes work correctly may ruin a box already approved. For this reason we need to retest all boxes already corrected. When I have done this before starting to test a new box or set of boxes a subset of test cases were run for all the boxes that had earlier been approved. The first times I ran projects this way all testing was manual so we had to choose a rather small subset of the test cases to rerun. To make this efficeint and good I always asked the tester who prepared and tested each box originally to do it again. I also asked the same person to choose what subset of test cases to use. This always worked very well and did not waste a lot of time.
当完成一个BOX晚期的开发工作或缺陷修复工作，但可能破坏一个已被验证过的BOX，因此，我们需要重测试所有已被测试过的BOX，当我测试一个或多个新开发的BOX之前，我会运行一系列的用例来检查早期已被验证过的BOX，我第一次按照这种方式做项目的时候，，所有的测试都是手动执行的，所以，我们不得不选择少量的用例集来运行，为了提高效率，我总是要求原来测这个BOX的测试人员去重复执行用例，同时也要本人去选择一些用例来重复执行，这个方法一直工作得很好，而且并没有浪费很多时间（译者注：相当于测试责任田，每个测试人员分配BOX，并负责挑选回归用例，不断重复执行）
When we use a large portion of automatic test cases it is possible to rerun a larger number of test cases. We will build a test suite that becomes longer as we approve more boxes. It is necessary to rerun already approved test cases for all boxes regularly! It is more valuable to cover a large portion of all test cases every week by running different subsets every day than running the same small subset every day!
当我们用大量自动化用例时，就有可能重复运行大量的用例了，我们将会建立一个测试套件，随着BOX的不断被验证而不断增加回归用例，必须经常地不断重复运行已通过的用例，而且更有价值的是，在每周重复运行大量用例集，当然，每周运行的用例集和每天运行的用例集是不同的
The same approach shall be used for running legacy regression test cases. It is better to cover a large share of the "old functionality" each week than running the same small subset every day.
When adding new functionality or correcting faults new faults will be inserted. We need to find them!
同样的方法可被用于遗留系统的回归测试，最好每周运行大量“老功能”的用例，每天运行少量的用例，有这样的机制，当新增加功能和修复缺陷时，如果有新的错误引入，我们会及时发现它！
