敏捷中的软件测试的出路

以敏捷开发的模式做软件测试已经将近一年了，敏捷实践让项目和团队成员获益颇多，但是在敏捷的过程中，作为一名功能测试人员，感受到了一种危机在逼近。因为在标准的敏捷团队中，里面是没有很明显的角色区分，团队成员应该都可以成为对方的backup。开发做测试上手容易，但是让没有代码基础的测试从事开发的工作，就有点困难了。以前瀑布模式的时候，客户，功能测试，开发三个角色可能对相同描述的功能会有不同的理解，导致很多缺陷都是需求上的缺陷或者是推翻重做。所以在瀑布模式中，测试技能和熟悉业务这两项能力，使得测试人员的存在对团队来说意义还是重大的。可是做了敏捷后，在需求上的理解偏差不大，所以需求的缺陷并不多，另外AC（验收的标准）几乎都是PO （product owner）写的，而且写的很详细，基本上涵盖了大部分的场景，以我们公司的情况，PO 写的AC几乎跟我们平时写的test case 相差无几了；另外在迭代中我们也尝试做了角色交叉，让开发也帮忙做测试，但是在实践的过程中，让测试做开发的工作，真的很难实现；另外，在一次次迭代，一次次 retrospective meeting 之后，团队的工作模式不断改进，开发人员代码不断提高，缺陷越来越少，当然这是好事。但是如果人员统计每个迭代出现的缺陷，发现缺陷越来越少，老板哪一天会不会想开掉全部测试？但如果敏捷团队中，如果没有测试人员会怎么样？开发负责编码，负责单元测试，负责功能测试，看起来都能做，可是之前迭代的回归测试谁来做？在敏捷中，反复迭代，但是要保 证 软件是一直可交付的状态，所以每次新迭代，都要保证之前迭代所做的功能是正常的，如果说在每次迭代之后，人工去做回归测试工作量太大了，人会疲乏，效果不好，所以自动化回归测试这时就起到一个很大的作用。测试人员对业务熟悉，能更好的设计回归测试用例，同时做自动化测试也能提高测试人员的代码能力，这样也能使部分开发人员改变对测试能力的见解。我相信自动化测试是一个不错的发展方向。