从微软的转型看软件测试的发展 (2)

 

在实际工作中，大部分公司使用敏捷开发（agile development）, 软件项目的构建被切分成多个子项目，各个子项目的成果都可以测试，
且可以集成和统一运行。它是一种以人为核心，人们可以先做想要做的的模块，可以修改流程，可以变更和修改当前的功能； 同时又是一种迭代，循序渐进的开发方法。即使有多年的敏捷开发应用经验的团队，测试都是一种挑战，人们很容易的说，
我们自始至终都做测试， 但是很难把它做好。有时测试影响了这个项目的时间进度，质量得不到保证。

经常听到团队的人说：“为了实现新的功能， 代码到最后一刻才做好，怎么能完成测试呢？”

“我们试图用自动测试代码来完成验收这个新的编译，可是十有八九要失败，因为程序代码改变了，而自动测试没有及时更新那些调用。”

“我想许多缺陷没有发现， 因为我们重点测试已有的功能，新的功能，对软件系统没有仔细的测试。”

现在人们普遍认为，测试人员测试，程序员写编码，把二者分开是很重要的。独立的测试队伍才能保证软件的质量。现在我们来分析一下为什么程序员不能测试。

也许你会说，”当然， 程序员可以测试”, 但是， “他们不会找出他们自己的编码错误，也许他们可以测试其他人的代码，
但不是他们自己的。”

但是，同时作为程序员和测试员， 时间不够是比上述问题更重要的问题，至少我个人认为是这样。当我的时间不够时， 我匆匆忙忙完成任务，因此就容易忘记或漏掉去测试一些功能。后来，
当缺陷从最终用户哪里反馈来了， 这个缺陷就发生在我忽略的那一部分，或者我忘记的那部分。测试其他人的编码不能发现由于时间的压力，忽略的那些功能而导致的缺陷。