测试的价值从问题单开始

上一篇 / 下一篇  2020-09-25 20:47:26 / 个人分类:测试杂谈

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

1)问题太小

2)不可重现

3)没有相应的标准或规范

4)实际情况不太可能发生

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

6)改正风险太大

7)不会影响实际用户的使用

8)对业务影响不大

9)和某些问题是同一个问题

10)不在设计师的设计范围内

11)参考以前的版本

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

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

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

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

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

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

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

1)多问问题,多让开发陈述理由

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

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

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


TAG: 问题单 测试 价值

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

我的栏目

日历

« 2020-11-19  
1234567
891011121314
15161718192021
22232425262728
2930     

数据统计

  • 访问量: 1212
  • 日志数: 5
  • 建立时间: 2020-04-19
  • 更新时间: 2020-09-29

RSS订阅

Open Toolbar