为什么和为什么不这是一个很有趣的问题。

　　我们在测试工作中，尤其是需求不明确，公司没有一套规范的情况下，常常面对一些自己完全不知情的程序，比如，一个WEB测试，一级目录有五个，其中有一个目录的风格和另外四个的不一致，这个时候不要立即去将这定义为BUG，而是去询问开发人员为什么这个地方要特立独行。

　　这种做法是对的，然而也不是最好的，简单的来讲，这个过程你只是去提出了一个问题，然后开发人员回答了这个问题，最后就没有了，我们试试下面这个方法。

　　当发现这个问题的时候，我们先自问，为什么不能这样呢？要解答这个问题，就必然要考虑这五个一级目录的特点，是不是这个风格另类的页面是有一定的功用的？

　　然后，我们去问开发人员，为什么不是统一的？这个时候开发人员除了会告诉你为什么之外还会去思考为什么不统一？

　　最后的结果是测试人员和开发人员都有思考的空间，同时你为什么不所得到的消息，会比为什么得到的消息多，而消息越多，我们测试起来就更为细致和容易，盲点和漏测的地方就会减少许多。

　　现在有一个小项目，是对一个文件执行跟新和回滚操作，开发人员提供的UI是这样的方案A：

　　Test.dll     1.0.0.0   button(update)

　　Class.dll    1.0.0.1   button(rollback)

　　当系统检测到有新版本的时候，button按钮自动转变为update按钮，更新后，则变为rollback按钮，即这两个按钮不能同时存在。

　　如果这个时候我们去问为什么这样设计，那么得到的解释会是这样设计的理由。

　　那么我们如果要问“为什么不”就需要自己设计一个方案B：

　　Test.dll   1.0.0.0    button(update)  button(rollback)

　　Class.dll  1.0.0.1    button(update)  button(rollback)

　　若系统检测到版本为最新版本，那update按钮就是灰色不可用状态，反之则是黑色可用状态。

　　这是我们根据需求自己思考得到的一个设计，我们认为这样的设计会简单一些，并且会减少许多潜在的威胁性的BUG，比如，检测到新版本，按钮还是rollback或者想要rollback时只有update按钮。

　　这个时候，我们可以去提问“为什么不用方案B呢？”那么开发人员给我们的答案除了会告诉我们为什么用方案A，还会告诉我们不用方案B的理由。

　　在项目当中，用什么方案，不用什么方案，绝不会是个人的主观原因，不用的理由和用的理由必然都是项目真实存在的问题，我们要做的是虚心去凝听，思考，“为什么不”并不代表争吵，辩论，只是两个人对需求的不同理解，就项目本身而言，也许测试人员比开发人员更为熟悉，但这种熟悉是指全局来讲，即对整个项目的熟悉，若是单独的对某个功能模块来讲，是不可能比开发人员更为熟悉的。

　　要学会去认可开发人员的合理话语，尝试站在开发人员的角度去思考，对于你不能理解的地方，不要盲目的贴上Bug的标签，而要去考虑这样设计的用意，并提出你认为的可行的建议，在沟通中，去掌握更多的有关项目的信息，一旦你学会这样提问，那你得到的将不只是界面层次的内容，还有代码层面，设计层面，逻辑层面，部署层面等多方面的信息。

　　我一直认为，开发人员很容易沟通，我从来没有和开发人员有过负面争执，大家都是为项目出发，并且没有利益冲突，开发和测试，一荣俱荣，一损俱损，这样的联系之下，我不明白为什么会有很多人埋怨开发人员不好交流，不好沟通，每次都要吵得面红耳赤，实在很难理解，有些时候，我觉得测试人员比开发人员更难沟通，毕竟你上去了，他就下来了，这种矛盾是建立在利益冲突之上的。

　　关于这一点，我会在另一篇博文上阐述，测试行业前路坎坷，没有办法估算还有多少弯路艰辛等这我们，加油吧，一切都是为了明天。