测试的价值从问题单开始

        当测试开发沟通是否可以提问题单时总会遇到开发这样那样的理由：

（1）问题太小

（2）不可重现

（3）没有相应的标准或规范

（4）实际情况不太可能发生

（5）只会发生在非常特殊的配置时

（6）改正风险太大

（7）不会影响实际用户的使用

（8）对业务影响不大

（9）和某些问题是同一个问题

（10）不在设计师的设计范围内

（11）参考以前的版本

当然还有其他的说法，这些说法看似合理，但事实并非如此。

没有相应的标准或规范的情况，曾遇到通过网页配置数据会在命令行界面打印内部调试信息的问题。是否应该打印这些信息？暂且不说是否存在相应的标准。这里要指出的是如果不存在这样的标准是不是就无法做出决定了？没有标准，我们有经验，编程经验，解决类似问题的经验，与客户打交道的经验；没有标准，但我们有以用户为中心的视角。这一点至关重要，这要求我们提供的信息准确、清楚、有用，来引导用户发现并解决问题。对比一下这样的打印信息，它给用户展示的是什么？是我们的疏忽或者不专业？

至于是否算功能问题，这个真的因客户而异。有的软件测试著作中将易用性纳入功能性问题，因为会直接影响用的功能体验。我个人的建议是：1、参考公司的规范，如果有。2、不妨做一些假设：用户对功能的验收要求很高，会将内部的调试打印信息和功能缺陷同等对待。

不影响业务的情况，曾有这样的提示信息：“伙计：……”。很明显这个提示信息对于不同经历、不同环境、不同教育程度的用户理解起来是不一样的，有时比业务影响更深远。软件质量除了满足用户和企业自身的需求外，还必须考虑一些本地化的需求。）

不在设计师的设计范围内的情况，测试的范围远大于系统边界，这个是测试的共识。漏测问题的分析结论也证实了这一点，总会有分析不全的情况。一个项目或一个产品就那么几个研发人员，而产品是面向全世界的，考虑不全面很正常。

参考以前的版本的情况，这个似乎很有说服力，而且确实有些情况下看似正确的处理不一定是客户想要的。特别是平台测试至少需要做到“可以不知道怎么用（实际应用场景有其复杂性），但知道什么是对的（可以引导用户）“。同时不妨多问几个问题：客户的认识是否在不断的变化？客户这段时间是否有新的业务发放？客户网元有无新增？新客户的环境有什么特殊性？系统这段时间的新增需求是否对其有影响？

测试该如何应对这些各式各样的不认为是个问题的理由呢？提升自己的能力和见识是基础，借助测试的有力武器——质疑（不懂难道还不能问了，认识事物总得有个过程），唯一不变的是变化作为指导思想。具体可以尝试如下操作：

（1）多问问题，多让开发陈述理由

（2）行动：收集问题影响正常使用的证据，如：破坏数据、给用户带来麻烦；证明以前版本没有问题；找到以前类似的问题给用户带来了不良的影响；分析问题出现的概率，预计会带来的影响；了解一下友商的类似产品是否存在该问题；进一步测试会引发更严重的问题、更广范围内的错误；

（3）明确坚持提问题单意义，提问题单的意义在于：提示大家注意缺陷并帮助开发定位内部问题；提示规格说明、文档或工具的问题；为用户指导书的编写提供指导（如存在某些约束）；有据可循

实际上测试也希望系统设计师能站在客户的角度设计、开发站在客户的角度实现，开发在否定问题时能说出合理的理由。例如：该现象在某些客户的某些场景下会低概率出现，会对某些功能带来微小的影响，即使出现后也可以通过某些操作来规避。