如果developer return了你的defect

如果developer return了你的defect，你会怎么做？

return的原因通常有那么几种：

can not reproduce
Need more information

Scenario is invalid

Limitation
Work as designed

对策：
1）如果是can not reproduce，原因很多。最多的情况是在新的build中已经修复了该defect。根据developer返回的信息，重新验证该defect的有效性。如果该defect确实不能重现，我会选择cancel它。如果再次遇到该defect涉及的问题，reopen之，试图找到原因，将信息补充到defect的描述中。

当然这种情况，最能描述现实情况的是，developer要将该defect设置为resolved/indirectly fixed。不过我没有特别坚持过。

也有developer会认为你提出的问题，是根本不可能出现的情况，他们这一块儿的代码不可能有问题，多数会告诉你环境有问题。一半一半吧。不过作为测试人员，自然不能轻易放弃。把可能的环境问题重新确认一遍，是环境有问题呢，就cancel这个defect；不是呢，就将确认的过程和log 文件提交给developer做进一步的判断。当然，如果某个环境问题很常见，如果对客户很重要，则要么写文档让客户遇到问题可以查询；要么在程序中做出检查，做出预防。

2）如果是Need more information，说明defect中提供的信息不足以使developer明白发生了什么事，并做进一步的investigate。这个时候，多数是会根据反馈，提供更多的信息，例如发生问题的时候的环境、log文件等。

一般来说，FVT遇到这种情况比较少；SVT比较多。大概也是FVT的环境相对简单，只要是有经验的测试人员，都会根据情况提供足够的环境信息和steps to reproduce；而SVT的环境，developers自己平时也接触的比较少，可能很难立即判断出现问题的原因。

3）Scenario is invalid，也是会有的。可能在用之前release的scenario在测试，或者需求变更了，scenario就会变成invalid了。像是这种情况，经过沟通和确认，cancel即可。

4）Limitation。对于一个Web应用，limitation多数是third-party limitation，可能来自应用服务器，浏览器，rich editor，feed reader等。其实是不是limitation，是看问题的重要性，是否值得解决。如果很重要，自己会在应用中开发相应的功能或者想办法绕开；如果没有那么重要，则会说以effort、risk等来说，没有办法解决。这个时候，通常一线测试人员会提供自己的观点，而architect或者mgmt team会review之后做最终的决定。

5）Work as designed，这是最辣手的情况。有些developer会说，designer就是这么设计的；有的会说过去一直是这样的，从来没有客户抱怨过；有些会说我写个tech notes给客户好了。

我心里会说designer的设计本来就是错的啊；没有客户抱怨，也许是客户还没有使用，并不说明你现在的状态就是对的啊；事实上哪里有喜欢看tech notes的客户啊。不过我一般想想，很少说出口，顶多写在defect的comment中 :D

对于软件项目而言，质量不是唯一的标准，时间和cost都是成功的因素。我会选择寻找进一步的证据，来说服developer接受我的观点。我会咨询我信任的developer对这个问题的看法，也会在必要的时候请求architect的帮助，来界定问题的必要性和重要性。PM倒是很少找的，反正他们会定期review所有被置为work as designed的defect。我就遇到过一次，当我正在寻求证据的时候，release manager出手了，她的一句comment，就改变了那个defect的命运。