感谢一些朋友的建议。那么就提及工具的名字，当然同类软件很多（免费也不少），这里举个例子，希望大家支持正版软件。另外，A.Z提了小型软件企业混乱的地方，提到了人员流动，以及怎么构建测试团队，这些都是很普遍的问题，每个问题都很“难缠”，之所以说“难缠”是因为这些问题相互重叠，需要抽丝剥茧的解决，那么关键是找对线头。
上次讲源代码管理软件，如果公司是走微软线路的，现在一般会使用vss2005。这一类软件网上很多，使用起来都差不多。源代码管理软件可以管理源码，也可以管理文档。这类工具是太基本了，如果有公司还没有使用源代码管理软件，那么公司的形态几乎等于个人作坊。
我们使用工具本身是比较简单，但是真正用起来就出问题了。比如要求员工离开公司前都要签入代码就并不容易，代码总有几个人没有签入，拿来拿去得不到最新代码，这时会非常恼火。可是就偏偏总有几个人丢三落四，总有几个人比较有个性。那么就必须建制度和检查工具来检查。检查工具可以用每日构造工具，比如finalbuilder，每日构建概念来源于微软，它和冒烟测试配合在一起使用。每日构建工具主要目的就是从源代码管理软件里取下代码，并编译和发布代码（可能还能做些自动化测试）。我们这里只使用检查源代码的功能，用它来发现哪些代码被谁何时占领着。每天夜里2点自动检查，第二天所有人就收到谁没签入的邮件，到时来个罚款，这样就基本解决了使用源代码管理工具的问题了。这个制度是要长期性的，因为只要用了源代码管理工具，就会出现有人不签入，管理和检查工具降低了出现的机率。
缺陷管理类工具网上也很多，举例testtracker。这里还谈不上构建测试团队，因为公司刚开始，我们也就一两个人专职做,测试也谈不上规范，也就做做低级的黑盒测试，挡住一些显而易见或者是让客户看到就跟你急的的缺陷。比如，做个收费性质的网站，当发布一个新版本的时候，突然发现免费用户看到了收费信息了，那客户必定跟你急。那么针对这个网站项目，测试权限是发布前必须做的。
到这里讲到了些工具，问题才开始，而且都是头一年会发生的问题,比如缺陷工具有了，开发人员不去及时修复缺陷，缺陷谁来定义，人员流动影响开发的问题，问题员工的问题，如何绩效等等问题。有兴趣的话,再和大家慢慢回顾吧。
