Software Quality Assurance

如果你在逛街时，发现有件款式非常流行的衣服，看了觉得十分满意，可是衣服破了一个洞，还有一些污痕，你觉得有点讶异，找来卖衣服的小姐，想要问个仔细，她却对你说：『这件衣服虽然这里有一个洞，那里的颜色也不太对，不过你既然急着要，那就先拿回去穿吧。过两个月以后，我会把针线放在我家门口，你自己到这里来一趟拿回家自己缝一缝吧。虽然是这样，这件衣服，还是不二价。』你会怎么做？

1.乖乖付钱，两个月后很高兴地去拿针线

2.杀价

3.叫会杀价的人去买，再叫别人补好了以后，再拿来穿

凡是在这个性向测验选择1的人适合当软件工程师，选择2的人会在企业里面担任采购，选择3的人，则是可以顺利当上主管。至于会把售货小姐痛扁一顿的人，可以考虑到反微软联盟工作。

这种莫名其妙的事情，在购买一般的消费品时，是不会发生的，最少在已开发国家不会。可是软件公司赶时间做出勉强可以运作的软件，接着靠着好奇又喜欢尝试新鲜事物的使用者的奉献与测试，再靠着强势手法行销，就不断地推出更新版，升级版来赚更多的钱，这好象已经变成了这个业界的常态。经过多年的洗脑，大部分的人都已经默默地接受了『只要是人开发出来的软件，就必然会有bug』这样的观念。

遇到这种状况，有些人就会想要把以往流行过的品管观念，像是TQM(Total Quality Management)，拿来用在软件开发上。不过依照这个业界的特性，头字语怎么可以采用其它领域的名词呢？我们应该自己发明一个。所以就有了类似SQA 软件品质保证(Software Quality Assurance, SQA)这样的名词出现。

关于Software Quality Assurance呢，我个人并不是这方面的专家。所以关于SQA跟TQM，或是其它各个令人头痛的头字语之间到底有什么细微的差异，我是一概不知。不过没关系，根据统计数字显示，大多数的读者也不是这一个领域的专家。这就让我有机会可以扮演先知的角色。如果你刚好是这个领域的佼佼者，建议你快快翻过去，不要看得太认真。

对于很多人来说，Software Quality Assurance指的就是软件测试。以我看来， Software Quality Assurance最少还包含了怎么去做review，怎么建立一套良好的标准开发流程，怎么进行相关档案的版本控制，遇到高severity(优先权)的defect时，要怎么进行处理，建置开发与测试的环境时，又要考虑什么，以及怎么样去收集并解读defect的资料…等等。

(※作者注：defect跟bug不太一样，例如有些人可能会觉得屏幕上的字不够大，想要叫你把字型调大一点，像这种状况就是一个defect，可是这并不是程序有什么错误(bug)。不过呢，除非你想要考状元，否则大部分时候你可以不去管它们有什么不同。以我来说，我觉得最大的不同是当你在讨论项目的状况时，如果用了defect这个字，会让你看起来非常的专业。)

不过不可否认，要把Software Quality Assurance做好，最重要的工作还是测试。所以我会从软件测试这个主题开始聊起。

***测试***

我开始从事软件工作时，我以为软件公司的主管，应该都是这个业界的资深前辈，所以对于软件应该要怎么发展，应该有很深刻的了解跟体认。不过经过了这几年，我发现好象全然不是这么一回事。至少在测试这件事情上来说，我遇到的主管真是形形色色都有。

最天真的主管，通常会像是发现新大陆一样的问我这样的问题：『我们为什么要做测试呢？我们要的东西不是软件吗？只要程序设计师够努力，够小心，应该就可以做出没有bug的软件，为什么还要花钱养人去做测试呢？把钱省下来，我们去养超级优秀的程序设计师，找超强的骇客嘛，干嘛花那么多心血去做测试呢？』

我总觉得，为什么要做软件测试其实就跟人类为什么要戴保险套，是同样的道理。男人会戴上保险套，并不是这个动作会带来什么快美难言的愉悦，我们要的是性。不会生小孩，不会得性病的性。做软件测试也是一样。我们会做测试，并不是我们喜欢测试带来的感觉，而是我们怕小虫虫会带来我们不想要的结果。测试并不会让一个本来已经正确的软件，变的更为正确。所以总会有人认为，干嘛要养专门的测试人员呢？

主张不用测试人员的主管，还是只要请程序设计师自己测试就可以的主管，其实就像是主张透过性交中断法来避孕一样。会有这样思考模式的主管，基本上就跟想要哄骗女朋友上床，却有没有准备保险套的十五岁少男一样。『我的自制能力比较强，只要我们小心一点，在虫虫快要跑出来之前，就先把它抽出来，就不会怀孕了。』同样的道理，只要程序设计师小心一点，就不会有小虫虫了。

下回你遇到这样的主管，你就直接想到十五岁的思春少男就对了。采用这种策略通常都要付出可观的代价，就像避孕失败就得选择堕胎或是当小父母一样。当然，当你发展的软件没啥价值时，有没有测试人员其实都没差。大自然会自动淘汰不适合生存的物种。

另外一种天真的想法是，只要我们用了超强的程序设计师，就不会有bug了。相信这种论调的人，或许也会认为下面的推论很有道理。

甲  ：医师，怎么可能？我女朋友怎么会怀孕呢？这一定不是我的孩子。

医生：怎么说？

甲  ：我每天坐在计算机前面超过十二个小时，又长时间的熬夜，每天还都
      穿著牛仔裤，依据医学报告，我应该会不孕才对啊。怎么有可能怀孕呢？

医师：……

相信拥有良好的天赋，再加上长时间接受辐射线的照射，以及超长的工作时间，小虫虫就会比较少。如果这个理论成立的话，我们也不需要避孕了，只要转行来写程序就好了。写程序的功力比较好，并不表示就没有小虫虫。况且有很多问题，并不是来自于程序设计师本身，从使用者到系统分析师，以及系统设计人员，每个环节都可能有问题。就像不孕并不一定都是女方的责任一样；凡是长时间在计算机前面工作的人都有可能要负点责任。

关于这个问题，其实程序设计人员也要负一部份责任。主管的愚蠢，多半是因为无知所造成的；可是程序设计人员的自我膨胀，却是让这个问题更加恶化。我不只一次遇到所谓的超级程序设计师，他们的特点是动作很快，或是脑筋很好，每个人都自信可以移山倒海：『如果有人写程序会有bug，那一定是他们能力不够好。像我们能力这么好，写出来的东西一定不会有问题。所以我写的程序是不会有bug的。或者因为我比较强，所以我写的程序bug比较少…你找任何测试人员来挑战我的智商，简直就是在侮辱我！』

很多人写好程序以后，就自以为天衣无缝，根本就不想继续测试。所谓的单元测试，常常都是虚晃故事。说来惭愧，我小时候也是其中的一分子。像我还很年轻的时候，每次写完一篇文章，总是觉得自己真是妙笔生花，文思泉涌。任何人要是尝试修改我完美的遣词用句，必定会遭到我无情的奚落与鄙视。

后来长大一点以后，就发现用新注音用久了，有时候计算机还是会胡乱组字，我没有在第一时间改回来，就把文章寄出去了。害我每次印出来看到自己写错字，都会想要叫计算机用微软新注音罚写一百遍。打字习惯了，写起字来也是鲁鱼豕亥，多所舛误。随着年月的增长，隔了一段时间回去看自己的各种议论时，慢慢也领悟到自己所学还是有所不足。所以现在对于各方的指正，就会比较虚心接受。

写文章都已经是这样了，更何况是写程序？程序发生错误，并不是因为智商的关系，也不尽然都是因为一时的粗心。大部分时候，是因为design没做好，或是在开发时想法上不连贯，或是对于要解答的问题没有想清楚。很有可能写程序写到一半，心爱的女友忽然打电话来说要分手，以致于心神丧失，无法专心致志的把程序写完；也有可能是房东临时打电话来要收房租，得要跑出去避难；也很可能是隔壁的猫咪在思春…反正造成bug的问题很多，没有一样跟你们的智商有关。你们自己编。

而一个负责任的程序设计师，就应该体认到写程序时，可能会面临很多干扰，所以任何时候要把程序release出来前，都应该要自己做好把关的角色。没有经过自己的单元测试，验证你的程序确实是work的，不应该把程序release出去。

当主管也认知到，超强的程序设计师所写的程序也会有bug以后，就已经往上成长了一层。毕竟软件需要测试，这跟人需要买保险是一样的道理。可是测试到底包含什么呢？他们的了解就不是很深入了。所以他们唯一会做的就是：『不断地重复一些陈腔滥调，可是没有任何实际的动作。或是想出一些不太有用的把戏。』

『品质非常重要。所以CEO对于品质非常重视，他特别把今年定位成品质年…』

『Quality is number 1.』

『测试非常重要。所以你们要努力地测，用力地测，想尽办法地测。』

『品质是所有东西的根本。只有良好的品质，我们才能获得客户的认同…』

好吧，对这些主管来说，反正测试就是一件很重要的事情，你可以为这么重要的事情设计一些标语，印在马克杯上，还是做做海报贴在墙上，平时训话时，加强宣导测试或者是品质的重要性，或者是把测试跟品保，指派给一个专门的人，这样子主管的工作就告一段落了。

每次遇到这样的主管，我就会想起下列连续剧的对白：

父亲：你怎么这么不小心？怎么会把人家的肚子给搞大了？我不是一再跟
      你讲，要小心吗？我不是一再跟你讲，要记得戴上保险套吗？

儿子没有说话，可是音响要传来他内心的声音：『你每天只会讲这个，可是
我连买保险套的钱都没有，怎么戴啊…』

或许这个儿子并不了解何谓reuse的真谛，他应该要多加了解使用OOAD的好处。不过很多主管，就跟这个父亲一样。总是觉得测试或是任何品质保证的工作，应该只要加强宣导就可以了，并不需要另外花钱，或是花太多资源来做这样的事情。这应该是写程序的人，应该要负起的责任。毕竟问题就是你们造成的，你们自己不找出来，自己不解决，还要推给谁呢？

另外一种很有趣的观念，就是测试虽然很重要，可是我只要安排人去测就好了。而且最好测试人员就是实际的使用者。毕竟，还有谁对这个领域更了解呢？所以他们的想法，就是请这些测试人员，用力的测，大力的测，想尽办法的测。反正就是做monkey test就对了。下回遇到这样的主管时，记得买些香蕉。

好吧，我们并不是生活在蛮荒时代，这个业界还是有很多了解为什么要做测试的主管。只是通常测试在台湾不怎么被重视，连带地也比较少人想要往这个领域钻研与发展。结果常常就是测试人员严重地编制不足，地位低落。

测试人员的不足通常有两种现象，一种是程序设计师要兼着做测试，另一种则是程序设计师把测试的责任，通通推到已经不足的测试人员身上。

让程序设计师兼着做测试(不是只有unit test，是连后面的integration test, system test喔。)其实是一种最笨的做法。众所皆知程序设计师的薪水很高，人数很少。所以是一种稀有的资源。请程序设计师兼着做测试，就跟拿纯金去打造一只马桶刷一样。除了不好用以外，价钱一定很高就不要提了。

请原作者去找出自己的错误，是很困难的。因为每个人思考都会有盲点，那就是为什么需要由不同的人从不同的观点进行测试，才有办法找出潜在的问题。

另一个现象则是程序设计师把测试的责任，通通推到已经不足的测试人员身上。这是因为有很多公司，除了测试人员严重编制不足，连程序设计师也是严重不足。所以程序设计师的心态就是，我只要写完就好了，所有的测试，都不是我的责任。

测试是需要程序设计师与测试人员彼此紧密配合，密切沟通的活动。如果
一个程序设计师的心态不正确，就会让这个工作很难顺利地推展下去。

软件测试其实是一门很高深的学问，要进行测试之前，需要先做出详细的规划，把要做哪些种类的测试，要收集哪些资料，怎么收集，遇到问题要怎么判定，怎么追踪问题…通通都规划好写出来，写成测试计划。接着则是需要依据分析或设计文件，仔细去想想要怎么测试，要用什么样的资料来进行测试，要用什么程序来进行测试…。把这些都想好了以后还是要写下来，写成测试个案。接着除了去执行原先设计的个案以外，还得要针对问题进行分析与追踪，并且要管制好各个版本的系统…还好我在这本书中，只想提提我所看到的一些问题，至于每件事情该怎么做才比较好，那是下一本书的课题。

测试其实是确保品质的最后一道防线。众所周知，越晚发现问题，解决的成本越高。早期发现，早期治疗，治愈的机会越高。要怎么样才能早期发现问题的征兆呢？那只有靠review了。

***Review***

早期发现，早期治疗，听起来非常有道理。然而开发软件牵涉到心智思考模式的交换，这也让review这件事，变得相当困难。很多人对于review的看法，就是找超人帮忙用X光眼睛看一看，就可以早期发现问题。问题是如果超人这么管用的话，为什么他不是一开始就加入这个项目？为什么有这么多的超人，还是有这么多失败的项目呢？

或许我们可以看看下面的例子。

客户甲：布鲁斯，为什么你们在项目组织里面列了超人的名字，可是我们
        一直没有看到超人的出现？

布鲁斯心想，(那是因为吉娜为了让项目的组织看起来称头，才列了超人的名字，超人这么忙，要对抗邪恶拯救整个地球都来不及了，怎么会有时间来拯救我们呢？)于是布鲁斯说：超人会在需要帮忙的时候出现，我想，除了一开始在设计系统架构时，会需要超人的指导。我们会请超人来参加review，帮我们先期找出系统潜在的问题。

客户甲：能够这样当然是最好了。

三个月后。

客户甲：布鲁斯，为什么超人还是没有出现？我们review了这么多次，超人
        还是没有出现！是不是我们这个项目比较不重要？

布鲁斯(超人本来就没有时间了，这该如何是好？)：我想超人会在我们需要帮忙的时候出现。目前我们的成果应该还算可以。

客户甲：谁给你这种错误的印象！我觉得我们这个案子已经陷入很大的危机之中。我会跟吉娜好好讨论这件事情，是不是你们觉得我们这个专案比较不重要？如果你们的resource调度有问题，我来帮你解决。

办公室内，吉娜正在跟客户甲通电话。

吉娜：是，是，是。没有问题。我会负责解决。您客气了，好的，好的。没
      有问题。拜拜。(挂掉电话。)布鲁斯，客户甲刚刚打电话来。你说该怎么办才好？

布鲁斯(还不是你捅的纰漏？还问我怎么办？)：我想我们还是得要请超人去露露脸，不然这件事可能不容易解决。

吉娜：不可能，超人现在正在全力对抗邪恶的外星坏蛋。我目前可以提供的支持就只剩下灵犬莱西。

布鲁斯(陷入极度的恐慌)：可是他是一只狗！而我们没有人懂得小狗在叫什么！

吉娜：这就跟你从美国找consultant过来一样嘛。上回我们找那个拿美国护照的俄国佬，他的英文不是没几个人听得懂？客户甲不是也被唬的一楞一楞吗？

吉娜显露出智商突然下降至90以下的表情。布鲁斯无法抵抗没有逻辑的思考，只好屈服在吉娜的淫威之下：我还是觉得要想办法请超人过来露露脸？

吉娜：如果超人有空的话，当然没问题。(是啊，如果太阳从西边升起来的话。)

三天后。

布鲁斯：我知道超人会用光速飞行，不过他现在因为照射到克卜顿星球陨石
        的光线，所以身体变得非常虚弱。目前正在调养身体之中。(有本事
        ，你杀到医院去抓他出来啊。)没关系，为了支持这个项目，我们公
        司还是派遣了相当资深的顾问，这位是灵犬莱西，它具有多年的专
        案经验。

灵犬莱西：汪汪汪。

布鲁斯：我想灵犬莱西可以参加我们的review。如果我们讨论的过程，他发
        现了任何问题，他会随时提醒我们。

灵犬莱西：汪汪汪，汪汪汪，汪汪汪。

客户甲：……

一般在进行review时，有分为形式上的审查，以及实质内容的检讨。形式上的审查，多半在于审查文件格式是否符合标准的格式？开发流程是否依据标准的流程？除非你相信，因为你写的文件格式不符合标准格式，所以跟你共同开发的伙伴们就没有办法看懂这些文件，否则这些审查最大的意义，只是在于把review这个法定的程序给走完。本身当然没有什么立即的价值。

实质内容的检讨，当然会有意义的多。可是这里就牵涉到，参与review的每个人，事先必须对于要被review的事物有足够的了解，要被review的文件要事先发给所有与会人员，并且各个review的人最好要事先将意见写出来，提供给其它参与会议的人。

光这一点就很难做到了。所以一旦进入这么细节的讨论，无可避免的是开发时间一定会拖的很长，而要找到这么适当的人选，并不容易。而这些人是否有时间可以仔细地推敲，详细地审阅，来找出潜在的问题，都是蛮关键的因素。要能达到有效的review，人选其实是最关键的因素。你要找的人，是否拥有足够的能力，如果这个人有这样的能力，在时间上又是否可以配合？这其实都会影响review所可以达到的效果。

大多数时候，所谓的review都是在盖橡皮图章。很多人就是想找个强人背书，表示这个案子有被强人看过了，也提出一些问题，不过大致上看起来还好。然而对于真正有问题的项目来说，不是找不到适当的人来review，就是这些人没有时间。有时候则是整个review流于形式上的审查，并没有什么真正的发现。不过这还不是最令人惋惜的结果。

即使你找到对的人，也发现了问题，这样就达到了review的目的吗？当然不是。Review除了要找出问题，最重要的还是要针对问题来提出解决方案。然而有很多时候，解决方案并不是那么容易可以实行。

超人：经过我用X光眼睛照射，加上我从克卜顿星球所学来超越凡夫俗子的知识，我觉得整个架构都有问题，整个high level design跟low level design都需要重新来过。不然就算是现在开始implement，以后问题还是会层出不穷。

吉娜想，(我们已经花了十二个人月在做design，这个穿著内裤的家伙在开玩笑吧？)：

超人，难道你不可以看出最关键的问题，我们针对问题来解决就好了？可不可以不要动架构？

超人：我会用光速飞行，可是要不动大架构，就可以解决这个问题，这只有上
      帝才行。

吉娜心想，(这种只懂得技术的人，果然脑筋比较死一点，让我来点醒他一下)：
超人，其实客户现在只是想要你帮忙看一下。你的想法我已经知道了，可是这个问题如果要这样解决的话，公司会受到很大的打击。你要不要在review的结果这里尽量地轻描淡写，反正现在问题很大我们已经知道了。详细该怎么做，我会跟project team讨论过以后，再请布鲁斯好好规划以后再跟你讨论。毕竟你这么忙，有这么多事要去做。(等老娘把你摆平了以后，就赶快找人去implement了。我又不是被吓大的。Design重新来过？怎么可能？我今年考绩不就完蛋了？听说ERP部门正在找主管，我跟Michael好好谈谈，赶快调过去，这个烫手山芋就可以丢给别人了。Design做完了，超人也背书了，剩下有问题，就是implement的人做的不好，跟我是一点关系都没有。)

超人：好吧，整个文件的格式看起来还是不太对。我会请整个design team在
      每个文件之前加上一张比较好看的封面，跟详细的目录，最后要加上一个漂亮的封底。这样才符合我们公司定出来的文件标准。

从上面的例子看来，review的时机还是很重要的。如果解决方案的成本太高，项目经理很有可能会采取比较没有效果的方案。因为这看起来可能对于目前的冲击比较小。只是对于目前冲击比较小的方案，不见得对于整个项目的冲击比较小就是了。

跟review相同，系统测试一样与很多执行面的细节有关。设计出来怎么进行测试，或是找了人来负责进行测试，并不会保证你的问题就会就此解决。我认为测试的成败，会跟下一节的主题很有关系。 (待续)

Defect Tracking, Version Control and Environment Setup
======================================================

要做好测试，除了要设计出好的设计个案以外，怎么样去追踪你所找到的问题，并且确定版本的控制如你所预期，这里面就有一些学问啦。

对很多主管来说，要做好问题的追踪，以及版本的控制，其实就是看你在这几个方面，是否使用了先进的工具来进行管理。只要学会了怎么样使用这些工具，并且也真正地在项目中使用了这些工具，这些工作就必然会做的很好。

所以我们会在很多公司里面看到，defect tracking的系统是上了，可是整个开发团队里面没有人会针对defect进行剖析；Version control的系统是用了，可是感觉起来好象就是变成了一个档案的备份工具，并没有实质上带来什么惊人的效益。

这就牵涉到了为什么要使用工具了。其实工具是为了帮助我们来解决问题。使用任何工具，就都会跟为什么要使用这个工具有关。只有在了解我们要解决的问题是什么，并且知道工具会扮演的角色是什么，而我们的作业还有什么要跟工具互相搭配之后，才能够真正解决我们想要解决的问题。

拿问题追踪系统(defect tracking system)来说好了。Defect tracking system其实就是一个纪录defect，以及纪录这个defect相关的处理纪录的系统。这里牵涉到的会是谁可以决定这是一个defect？这个defect是在哪个环境下发生的？要怎么reproduce？谁要负责把defect分派给适当的programmer？defect的严重程度(severity该怎么判定)？defect的状态有哪些？谁又要负责重新测试programmer已经解决的问题？如果这不是一个defect，那又应该要怎么处理？每个阶段该观察哪些指针，才知道现在quality到底好不好？

大部分的问题，都不在于工具要怎么使用，团队内部要怎么一起建立共识，并且分工合作，这才是重点。这就跟我们学习使用保险套一样。学习如何戴上保险套，这绝对不是重点。重点在于要怎么透过保险套的帮助，让两个人可以琴瑟和鸣。不要两个人之间我退你进，我进你退，你正兴致盎然时，我却是垂头丧气，这样就会很难切中要害了。只有在双方你情我愿时，这个小小的薄膜，才可以帮助双方达成彼此共同的快乐。

对于defect来说，最重要的关键是，要怎么样reproduce这个defect。也就是说，tester要帮助programmer，找到问题可能会发正在哪里。所以要怎么重回案发现场，就会是最重要的关键。

有很多时候，programmer会强调，在我的环境里面不会发生这种事情啊，为什么在你们的测试环境里面会发生这种事情？这就牵涉到了environment setup的policy。

一般而言，你会需要至少一个开发环境(development environment)，一个测试环境(testing environment)，以及一个正是上线运转的环境(production environment)。如果这是一个更新现有系统的项目，你需要的环境可能会更多。

很多人可能都搞不清楚为什么我们会需要这么多的环境，老实说，我一开始也不知道。一直到我做的项目越来越多了，我才明白，不这样做，很难解决我们会面临的问题。

开发环境是为了将大家的程序整合在一起，确保多人共同开发时，不会因为程序的修改，因为彼此的不一致，造成开发上的问题。例如改掉了程序的接口，或是在共享的档案上加了一些东西，或是增加了数据库里面，某个table的字段…这种事情一发生，就会有人哇哇叫。所以很多人为了避免这种问题，就建议每天把大家的东西通通丢在一起，看看会有什么结果。这就是daily build的由来。

可惜的是，很多资浅的程序设计师只听过daily build，就以为每个环境都是要daily build。事实上，daily build仅在于开发期间以及测试工作刚开始，版本还不是很稳定的状态下，才需要在开发环境中进行。

测试环境则是为了让测试人员在进行测试时，可以有一个不会受到干扰的工作环境所建置的。这个环境里面呢，最重要的是版本的更新，必须要接受测试人员的控制。

虽然我不懂射击，不过我猜想要射中一个正在高速移动的飞靶，应该比射中一个固定不动的靶子，来的困难的多吧。测试环境的版本，其实也是建立在这样的思维上。稳定的版本是最大的考量。在进行测试时，如果发现了问题，只要问题不是太严重，那就把问题纪录下来，继续测下去，不要去更新测试环境的版本，即使programmer已经把bug修好了也一样。

很多人可能会想，如果我找到了问题，那不是应该要赶快把问题解决吗？为什么不赶快更新版本呢？主要的原因有下面几个：

1.你把版本更新了，你就没有办法reproduce这个问题了。这样子在需要reproduce给programmer看时，你就没有办法办到。

2.如果你测试正做到一半，还有一半的test case还没有测试，你不把原先的test case全部测完，你就不知道系统在这个版本时，会有什么反应。可能旧的版本，比起新的版本会来得好。可是你如果没有全部测完，你并没有办法确定这一点。

3.你会没有办法比较修改前，跟修改后之后的差异。这跟减肥的广告需要留下减肥前的照片或是影片，才有办法跟减肥后的做比较是相同的道理。很多时候我们为了怕新的版本会造成边际效应，所以会需要把两个版本之间进行比较。拿来看看，这个修改到底有什么不一样。

我只有在一种情况下，才会决定要更新一个还没有完成全部测试个案的测试环境。那就是遇到了severity 1的bug。如果不去更新环境，整个测试根本就做不下去。真遇到这种状况，不更新版本也不行了。

Production environment就比较单纯了。原则上就是一个神圣不容侵犯的东西。(这跟娶了公主回家当老婆一样，你如果太粗鲁，一不小心把它弄坏了，可是没有人可以担待的起喔。)

任何关于production environment的更动，都需要先在测试环境中演练。(任何你想在公主身上使用的特殊招式，最好先跟丫头演练一下。)

在更新production environment之前，最好先把东西备份下来。万一出了什么差错，你还可以把环境恢复成原有的状况。(要跟公主上床之前，最好先拿到免死金牌。)

关于版本控制的话，其实我的认知就很简单。版本的编号要怎么样编？同一个版本的原始码要怎么样抽在一起？除了原始码以外，还有哪些东西也需要版本控制？(例如test data的initializing scripts，database initializing scripts…)什么时候要rollback一个版本？每个人要怎么check out，check in原始码？code freeze以后应该要怎么作业？…

只有defect tracking、version control以及environment setup这几个环节扣在一起后，进行测试才会有意义。

当你对于怎么处理一件事情的经验越来越丰富了以后，你就会想要把你的心得传承下去，这时候你就会试着去建立一个新的制度，或是针对原有的制度提出修正。这时，通常就会写出一套又一套的standard procedure and guidelines。

Standard Procedure & Guidelines
===============================

建立一套标准的开发流程，以及作业指引，可以说是许多工程师梦寐以求的目标。这种高档的工作，看起来就是在职场金字塔顶端的人应该要做的事情。想想看，让所有的小齿轮，都臣服在我惊人的脑容量，以及睿智的思考之下，是多么令人兴奋的事情。

然而，有这种想法的人通常不只有一个。你也觉得你的经验丰富，我也觉得我的看法具有洞察力，为什么我就要听你的？况且如果我没有在订定标准的工作上，表现出我卓越的贡献，那我怎么展现出我的绩效呢？多种政治考量的结果，通常就让所有的Standard Procedure与guideline的订定，蒙上很多层的阴影。很多人为了摆平政治上的阻力，会来个脑力激荡，或是来个集体讨论。

当你观察很多这种集体讨论会的话，你会发现通常会被找来开会的，不外乎下面这些人。

*满腔热血，怀抱理想的菜鸟
*一知半解，被抓来充数的米虫
*经验丰富，莫可奈何的老江湖
*不知所云，异想天开的上级指导员

满腔热血，怀抱理想的菜鸟
========================
很多年轻人，特别是刚出校门的人，通常抱持着满腔热血，总会想要依据书上的理论，来订定这样的典章制度，所以会参加这样的讨论。这些人的特点是缺乏工作经验，可是很喜欢读书，所以会发挥高度的想象力，来补足他们经验上的不足。因为没有实际的经验，所以总要找个靠山来靠，所以你看他们所发表的言论，言必称大师，动辄引经据典，好象当他们在苦心钻研UML、RUP、CMMI、还是第五项修炼时，别人都在看电视睡觉。好吧，这还算好的，因为这些人虽然搞不清楚事情要怎么做，可是最少还算具有理性，可以经得起理性的思辩。而因为经验不足，所以他们的发言虽然会影响方向，不过不会是影响决策的主要因素。

一知半解，被抓来充数的米虫
==========================
有时候有些人会参与讨论，多半是因为他们年纪较长，看起来经验丰富。不过年纪较大，或者曾经参与过成功的项目，并不表示他们就是成功的关键。当我们强调团队合作时，其实只要你有够好的同事，只要一人得道，你一样可以鸡犬升天。所以呢，总有一些其实并不是十分了解状况的人，会被抓来开会，反正他们也是抱持着当一天和尚撞一天钟的心态。

这些人的特点就是他们在职场上打滚多年，已经练就一身开无聊会议的功夫，所以可以一边聆听菜鸟漫无边际的高谈阔论，一边神游太虚打瞌睡。最厉害的是每次请教他们的高见时，就可以突然从恍惚状态惊醒，然后以他们先前参与的伟大项目当例子，开始言不及义的谈话。

比较伤脑筋的是，对于高阶主管来说，这些徒具工作经验，却没有从经验中汲取任何教训的人所发表的言论，跟其它的人看起来没有什么两样，主要也是因为高阶主管自己也不懂。所以通常在讨论的过程里，高阶主管就会用这个人的政治影响力，来决定要采纳多少他的意见。

经验丰富，莫可奈何的老江湖
==========================
每个团体里面总有一些知道事情该怎么做的人。不过事情总是很难往他们所期望的方向发展。所以每次开这样子的会议，这些人都是一副莫可奈何的表情。语带讥刺跟反讽，就是标准配备啦。

这些具有丰富经验的老江湖，一方面要引领菜鸟们的讨论方向，一方面要跟米虫们进行论战。可是最无力的，就是要忍受上级指导员们神奇的结论。

这些人因为战功彪炳，所以通常讲话会很有份量。不过遇到思考方向神鬼莫测的高阶主管，多半意见都会被打个七八折。

不知所云，异想天开的上级指导员
==============================
官大学问大。好象是一种政治上正确的真理。高级主管的人，常常都会想要提供宏观的看法，或是企图在各种不同的意见中，扮演仲裁者或是协调者的角色。然而大部分的高阶主管，都不是这个领域的专家，所以常常不是对于问题有错误的认知，就是提出很奇怪的指示，例如：

* 让我们折衷一下：当会议上有不同的意见时，例如一个人说要做A，另外一个人要做B，所谓的折衷就是A做一半，B做另一半。(这个字我可不会写。)即使这两件事是没有办法只做一半就连起来，或是根本毫不相关也不管。

*这些建议都很好，我想我们就分头进行：当会议上有不同的意见时，例如一个人说要做A，另外一个人要做B，所谓的分头进行就是你高兴怎么做都可以。遇到这种结论，我们就可以鼓鼓掌了。

*这些建议都很好，我想我们应该要兼容并蓄：当会议上有不同的意见时，例如一个人说要做A，另外一个人要做B，所谓的兼容并蓄就是A跟B都要做，即使这两件事之间互相重复，或是属于完全互斥的两件事。

*这些建议都很好，可是我想跳脱出大家的思考方式，用更宏观的方向来思考：这一个杀手锏在冗长的会议后施展出来，所有防御力不足或是生命点数不足的玩家就只好等死吧。搞了老半天，原来高阶主管早有定见，开会的目的只是想要走完民主程序。每次遇到这种状况，我都会想到斗鸡、斗蟋蟀…这种观赏其它动物互相争斗的活动。可能我们在开会时的争辩，也提供了高阶主管类似的娱乐吧。

民主不应该是在企业内部解决问题的方法。开会通常会获得的是共识，是妥协的产物，并不是一个比较好的结论。偶尔也会有三个臭皮匠，胜过一个诸葛亮的状况。是啦，诸葛亮都已经死了那么久，三个活人还赢不了一个不会说话的死人吗？透过这样的参与，多半可以摆平政治上的争论，让大家心服口服。

妥协的结果通常就是这些所谓的standard procedure以及guideline，会产生过多的文件。只要有人觉得重要，就要多写一份文件。除了听到濒临死亡的森林在悲泣以外，好象也没听到什么反对的声浪。企业总需要一些事情来消化过多的时间以及冗员，以免把太多精力花费在真正具有生产力的事情上。

先把事情变多，变得复杂一点，再要求每个人都要照着做。当文件过多了以后，还要另外贴卷标，写文件，告诉别人我们这件事情该怎么做，又是在做些什么。原则上，这就是ISO认证的精神。嗯，听起来果然跟quality有关。我差点忘记这一章的主题是什么。

当然，如果standard procedure and guideline是从实战上的best practice推导出来的话，就会有完全不同的价值。要能够达到这一点，需要在项目前进的过程里，找些时间回来review，并且做做分析，看看问题通常是从哪里出现的？特别是在一个项目告一段落以后。只是人们通常都急急忙忙的要赶下一个deadline，要做下一个project。却忘了要好好看看，在这样的过程里，到底大家学到了什么？

走笔至此，不禁要问在这个充满了缺陷的软件世界里，到底零缺点的软件有可能存在吗？

Is Zero-Defect Possible?
========================
看了很多书，做了一些项目，慢慢的就有了一些自己的体认。我觉得大部分的问题，都是出在整个开发流程的前端。不是需求没有收集好，就是设计出了问题。

1.review发现的过晚。最强的人不是在一开始就进来。

2.发现design错误时，不能下定决心。所以最多的心力在于补破洞，越补越大洞。

3.design不够solid就开始coding。

4.requirement认知不同。使用者没有办法帮忙review requirement。

5.当你发现一个坏掉的零件，你会把零件丢掉，还是尝试着去修理零件？

我们常常会为了meet中间的milestone，而miss掉最后的deadline。这种事情在项目开发的过程里面，层出不穷。如果在装配线上，遇到有瑕疵的零件，技术员会停下他的工作把零件修到正常，才继续组装，还是换一个新的零件？

当我们发现一段写得很差的code时，通常不会决定重写，因为这些人的工时跟心力已经花下去了。最典型的决定就是把它改到对。所以你会花加倍的时间，去把它改对，而不是把它丢掉。

更多时候，因为我们要赶schedule，这时候Pipeline好象是个不错的选择。所以design还没有做的很确实，就开始努力写程序。先写好的东西呢，很有可能下一个阶段就要再大幅度的修改。所以凡是强调用OO方法开发的软件，都会强调要用iterative的方法来开发程序。在开发共享组件时，的确是应该用iterative的方法，可是那并不表示，每个iteration都应该在design还没做完之前就先下去coding。我认为在任何时候，做了这种决定，企图争取到时间，最后都会浪费更多时间。

那是否意味着『等到design做完了，才开始coding；如果开发出来的东西有太多的defect，就做个design review；如果某段程序的bug太多，就干脆丢掉重写。』这样的开发模式会比较好呢？

我不知道。项目开发只有一次，就如同生命只有一次一样，你没有办法找到同样的team，在相同无知的情况下，重头用不同的方法，跟相同的user再重新做一次。接着比较两个不同做法的结果。

很多时候我们都是在已经看到结果时，才去想想如果当初我们如何如何，现在可能会怎样怎样的问题。很有可能站在现在这个山头，会觉得远方的山头比较怡人，可是等你翻山越岭到了那个山头，又觉得不过尔尔。

只是依据现在我微薄的经验，我觉得这样的方法，比较有可能达到我们的目标。

一开始想要描述software quality assurance，居然会扯到zero defect software development。我不禁对于自己漫无边际的漫谈能力感到惊叹。大脑Run到这里，也不知道怎么继续写下去了。这一章可能算是我的脑袋在运算时，遇到了一个severity 1的defect吧。嗯，这一定是因为detailed design没有做好的关系。

System Halt…… :-)                                 (全文完)