测试参与项目的时机

天天被测试人员叫过去定位一些软件本身不支持的功能。

目前项目的测试用例非常简单，简单到只有一句话。

全凭测试人员的思维发散来测试。发散的多了，故障单就多。发散少了，故障单就少。

项目的测试用例，用一个项目用例库，还是这个项目刚开始的时候写的。都2-3年没有更新。

心里的感触是非常深刻的。

项目在需求开发过程中，一定要有测试人员参与其中，制定好测试用例。研发人员、系统工程师、需求工程师、测试人员一起参与到需求开发中，从需求确定后，测试用例也要写好，制定好，并及时更新到测试用例库中，做到实时更新、常常更新；有很多测试人员的测试思路是非常好的，而且符合用户的思维，要时常让这样的员工给大家适时做一些培训，让其他人员也能分享到/学习到这样好的测试理念。

不要为了测试而测试，这个是测试的禁忌。

为了产品而测试/站在用户的角度测试，按照实际应用场景去测试，这个是测试的目的。

测试完成后，能够发现：客户需要的功能都能够保质的实现，客户不要的功能，能做到不给用户添麻烦，不出错。

相信很多公司都是这样的，测试人员无法理解到底测试到什么程度算是合格的，用户的使用范围是什么。

考核测试人员的标准不能只以故障单为标准，更重要的时候以测试的模块中客户需要的功能是否测试完备--以需求开发过程中制定的测试用例为标准，不能测试人员的发散思维来确定。

为了达到这个目的，要从项目的大领导到具体实施的人员来灌输这种思维。关键是如果大领导只说不干，不考核这个，或者干脆不说这个，下面更没有动力来实施测试参与需求的功能了。