软件开发团队的基本上都包含两个部门， 一个是研发，一个是测试, 这里的测试，也可以理解是质量控制， 他们并不了解软件产品是怎样实现的，当然也不需要了解。一般情况下， 软件在已经完成， 即将发布的情况下，才将产品交给测试。 测试即是产品质量控制员，又充当软件测试员，新的版本编译出来之后， 由测试部进行一轮测试，如果出现了BUG， 开发人员再改， 测试部再测， 基本上测试部隶属于研发部了（尽管所有人都认为测试部与研发部应该是平行的）。这样演变的最终结果是， 软件质量越来越差， 项目进度越来越迟缓， 为什么呢， 我认为有以下的原因
1. 开发人员越来越懒， 测试的工作一旦分离出去了之后，开发人员越来越倾向于让测试来检查功能是否正常， 对自己代码的逻辑的严密性放低要求
2. 测试人员不了解软件内部的实现，也不可能搞明白，因此测试人员所想到的测试场景肯定给研发人员要少，他们基本上只能通过用户界面，做一些用户级别的测试，导致测试不充分。
3. 在进度紧迫的情况下，开发人员在最后期限才把产品交付给测试部， 出现BUG之后，开发人员再改， 情况再严重一些，要么推迟发布，要么带着BUG发布
因此，我强调按照谷歌的测试思维：谁写的代码就由谁测试. 测试代码, 测试文档都要规范化, 不制定成规范准则, 就不会有人执行, 但也容易受到抵制,
1. 研发人员会抱怨: 没时间, 本来写功能代码压力就大, 哪有时间写测试代码.
2. 认为测试代码与测试工具的维护需要成本.
3. 认为一旦功能稳定了, 测试代码与工具就没有存在的价值, 何必去写.
4. 管理者一般重视产品进度, 特别是研发出身的管理者, 进度是绩效最直接的反映, 因从项目进度上就只分配很少的测试时间.
不过从我的经历来看, 上面的观点都是错误的, 基于以下理解
1. 程序员在写代码时, 测试代码多多少少都会写一点的, 有时是无意识的, 基本上用完之后, 就直接删除掉了, 这个其实是非常大的损失
2. 程序员很忙很累, 特别是在产品发布之后, 发现各种BUG, 有时解掉一个BUG, 又产生新的BUG, 就是因为测试力度不够, 导致越来越忙
3. 软件的稳定是不好界定的, 需求时常变化, 代码结构时常优化或更改, 在没有测试工具的情况下, 很难保证质量
阅读(1297) | 评论(0) | 转发(0) |
