小型团队的测试该何去何从

很不幸，我不知道自己应该不应该谈论这件事，“小型团队的测试该何去何从”，我没有十足的经验，更没有十足的理论，然而回想起昨日大家一起的讨论结果，我到现在依然沉浸在失望和苦闷的滋味中，究竟是增强开发人员的自测能力以及自我驱动力还是增加测试人员来做问题的过滤？ 首先，我们先抛开需求分析，为什么这么重要的环节要先抛开，因为国内的小型团队面临着无法避免的严重问题： 1. 客户压根不懂需求，遇到一个稍微懂一些需求的客户，那都是上天对你的恩赐。 1. 时间太过紧迫，经常在客户眼里，这个什么功能简单的很，实现起来不就是一会儿时间的问题，都不需要什么技术。 1. 迫于市场压力和成本考虑，前期做大量的需求分析压根无从下手、也容不得你多做考虑。 当然，我们小型团队依然会做需求分析，只是占比太少，我们必须快速迭代，交出产品，让客户依据我们的做出的产品衡量他的需求。那么问题来了，在快速开发的过程中，如何保证软件质量呢，也就是所谓的测试，如何进展。 我在会上提出了自己这样的观点，从开发人员做起，而不是从需求分析处找问题，更不是留到测试人员找问题。怎么从开发人员做起，那就是增强开发人员的自测能力，使开发人员的效率最大化。在小型团队中，开发人员才是团队的核心竞争力，开发人员必须具有强大的自我驱动力，并且要海纳百川，需要做的不是照着可能已经存在问题的需求分析书敲代码，也不是自我感觉良好不进行代码的自我review，更不是极不情愿的不去做代码测试、集成测试。然而我这样的观点在会上受到了严重的歧视或者反对，有如下观点： 1. 你所处的产品环境和我们组有着巨大的差别，你所处的环境中，你们组每个人对自己的模块很清楚，而我们组每个人对彼此的模块不清楚；你们组的代码量加起来不及我们组的十分之一，你所能看到的问题不能和我们组相提并论。 1. 我们开发人员无法做太多的测试，因为在我测试的时候，可能数据库表结构都不存在了，其他人压根不会告诉我，你让我怎么测试，我只能留到测试人员发现。 1. 由于需求经过多次传递，需求在开发人员处已经不再明确，开发人员必须按照自己的理解去做出结果，开发人员没有责任，需求分析也没有责任。 1. 测试人员其他工作过多，导致不能把所有的时间用来做测试。 而所总结出来的解决方案是，开发人员自测虽然是个好观点，但是可实施性不大，减少测试人员的其他工作，专心做测试，如果一个人员不够增加人员。 对于以上观点和理由，我不做过多评价，我想是我自己鼠目寸光，见识短浅，没有去体会别组的难处。也许在他们眼里，我们组的情况是这样的“项目复杂度远远不够，人少问题就少，并且每个人都懂得其他人的模块”。 我很失望，我失望的不是自己的观点得不到认同，而是我们项目组的很多成员无法意识到自己的问题，这样久而久只会积劳成疾。我不是说自己有多优秀，我自己从前也厌恶做测试，测试不就是测试人员的专利嘛，我干嘛要自己测试，况且很多人开发的模块我也不清楚，我干嘛去了解其他人的开发内容，况且那么复杂，我根本了解不到，况且很多问题都是需求上出现了问题，又不是我自己的责任。 在现实中，是这样的。就我自己而言，我接到我目前的项目马上就有一年的时间了，在这期间，领导给予了我很大帮助，我的同仁们也给予了我很大帮助，时至今日，基本上能够把控整个期货交易平台的开发以及质量。我们组从一开始就没有需求分析师，更没有所谓测试人员，如何能做到问题越来越少呢，我想这多半和自己的些许努力是分不开的。我刚接手项目时，项目虽然已经上线运行，但是存在问题我都不敢回首。期间两个原来开发的核心成员都早早的离职了，我必须承担很多角色，以前别人说，我们小组人员少，所以在敏捷开发中的角色定位也就不存在任何问题，一人身兼多职理所当然。我要做需求分析，和客户讨论，自己琢磨方案，自己参与调查，参与架构，参与大量的开发工作，尤其是还有大量的测试工作，然后还有不停的修改bug，我曾经很痛苦为什么我要帮别人擦屁股，为什么我的成员对自己的代码如此不负责任，几乎都是一遍开发，能够自测是我不能太多奢求的。那么这就要求我，要做好自测，同时做好其他人的测试，当然我自己开发的也曾在上线后出现低级的问题，这也更加锻炼了我的自测能力。 我认为，小型团队，如何调度开发人员的效率最大化，才是公司发展的最强生命力。很多时候，很多成员抱怨自己时间多么紧迫，任务多么积压，但是我所看到的现象是，大多数时间成员无所事事，也许如果我们组一开始也有一个测试人员，那么我也会形成一种他人测试的依赖症。虽然我不能说我们小组的测试有多么好，成员的自测能力有多强，我只是想让团队推广“自测”、“自我驱动力”的意识，然而这种观点并没有多少人认可。 **总结**：说了上面这么多废话，有些话也不知道自己应该说不应该，把这些事情记录下来，不是抱怨团队，而是为自己立下警钟，无论以后身处何地，必须高举“自测”、“自我驱动力”的旗帜，而不是抱怨需求分析没做好，然后把问题留给测试人员，更不是归咎于项目的难度而去规避开发人员的责任。