和Joseph的一次探索之旅


和Joseph的一次探索之旅

和Joseph的一次探索之旅

引子

前些日子整理书架时,发现了一本旧书“C++ Primer”,于是突然对C++来了兴趣,我用XCode建立了一个OS X的Project,然后从github上Down下来GoogleTest源程序,想把GTest加到我的Project中。可是一路遇到了很多坑,搞了2个小时,也没有搞定,甚是沮丧.

第二天正好要去Joseph那里练习结对编程,于是请他先帮我解决这个问题,Joseph用了约2小时(110分钟)解决了这个问题,我从旁一直观察,发现开发人员解决问题的过程与测试人员发现bug的过程是如此惊人地相似,都是一个蕴含高度智力的、不断探索的过程。

这2个小时的探索旅程,一路伴随着坑坑洼洼,我们需要去解决一个又一个未知的、形态各异的bug(问题),下文将挑选其中的一个问题进行深入讨论,希望能给开发人员或者测试人员一些启发。

问题

由于在解决上述这个GTest的问题时,需要不断的上网搜索各种可能借鉴的信息,Joseph的习惯是只用Google(而不用度娘),他首先发现我的Mac已配置的VPN有点过时了(不是很稳定),于是我们决定先修改访问网络的方式,改用Joseph现在正在使用的一个还不错的代理。

问题简单描述为:配置web安全代理的方式访问网络

第一段探索

  1. Joseph发现我的Chrome浏览器已装有代理管理扩展程序Switchysharp
  2. 打开网络偏好配置,配置代理服务器和端口信息
    • Web代理(HTTP)
    • 安全Web代理(HTTPS)
    • SOCKS代理
  3. 设置Switchysharp为“使用系统代理设置”
  4. QUESTION)打开网站比如facebook.com验证,发现无法访问网络Smaller icon
  5. ACTION-01)也许Switchysharp没有启用?检查Chrome扩展程序配置,确认Switchysharp已经启用
  6. ACTION-02)也许网络配置有问题?检查网络高级配置,没有发现问题
    • Wi-Fi
    • TCP/IP
    • DNS
    • WINS
    • 802.1X
    • 代理
    • 硬件
  7. ACTION-03)重新确认问题。修改Switchysharp为“直接连接”,访问facebook失败,访问sina成功;改为“使用系统代理设置”,facebook和sina均无法访问,说明代理设置的有问题。再次检查代理设置,没有发现问题,再次改为“直接连接”,问题依旧。

至此,约10分钟过去了,搞不清问题原因,一头雾水,于是我们打算暂时搁置这个问题,暂时使用bing来搜索信息吧,于是接下来100分钟专注于解决GTest的问题去了。

吃完午饭回来,我们打算再次尝试一下,看能否解决代理设置的问题。

第二段探索

  1. ACTION-04)删除Switchysharp
  2. ACTION-05)重新检查代理配置,突然发现Web代理的端口号为3218,其实应该为3128,于是修改端口重试,发现网络不通
  3. ACTION-06)重新下载Switchysharp,发现下载非常缓慢。这时我提议,用Joseph的机器下载,然后拷贝到我的机器上。于是Joseph打开他的Mac开始操作,突然他想到以前拆叔因为某个事情帮他修改了端口号,去掉了前面的数字5,其实正确的端口号应该是“53128”
  4. ACTION-07)修改代理设置中端口号为53128,验证网络访问,成功。

至此,前后约20分钟,问题得以解决。

探索分析

分析一下上面共计11个步骤的探索过程,方框里的文字为我的解读。

  • 发现我的Chrome浏览器已装有代理管理扩展程序Switchysharp
  • 打开网络偏好配置,配置代理服务器和端口信息
    • Web代理(HTTP)
    • 安全Web代理(HTTPS)
    • SOCKS代理
  • 设置Switchysharp为“使用系统代理设置”
  • QUESTION)打开网站比如facebook.com验证,发现无法访问网络Smaller icon
分析一下这个问题,有两个主要的数据“Switchysharp”和“代理的配置”,将它们配置正确就可以了。


DATA             | VALUES
---------------- | ---------------------------------------
Switchysharp     | “使用系统代理设置” 
                 | "直接连接"
-----------------|----------------------------------------
代理的配置         | 配置的内容(Web代理;安全Web代理;SOCKS代理)
                 | 不配置

- 前面三步为正常的操作过程,就像测试时的Given和When
- 然后我们在Then这个步骤,发现与我们的预期结果不一致
- 这是一种典型的Inconsistency Heuristic,也是很重要的test oracle,它帮助我们做如下判断:这里有问题!
- 也许有的测试人员此时会将他做的test标记为failed,然后提交一个问题单,over!继续做其他的测试
- 不过优秀的tester可不是这样,他一定会做一些followup testing
- Developer当然也不会这样,通常他会开始定位和解决问题,于是开启了下面的探索之旅
  • ACTION-01)检查Chrome扩展程序配置,确认Switchysharp已经启用
- 遇到与预期结果不一致时,首先要排除不是自己操作错误的原因
- 于是大脑很快地进行自检,发现一个之前考虑的遗漏点,Switchysharp这个数据还有第三种可能的取值,“不起作用”
- 更新数据模型如下
- 这种确认问题是否真的存在的做法,叫做“Replicate”-确认问题是否能重现

DATA             | VALUES
---------------- | ---------------------------------------
Switchysharp     | “使用系统代理设置” 
                 | "直接连接"
                 | Switchysharp没有启用
-----------------|----------------------------------------
代理的配置         | 配置的内容(Web代理;安全Web代理;SOCKS代理)
                 | 不配置
  • ACTION-02)也许网络配置有问题?检查网络高级配置,没有发现问题
    • Wi-Fi
    • TCP/IP
    • DNS
    • WINS
    • 802.1X
    • 代理
    • 硬件
- Replicate可以有很多种方式,一个方式就是检查每一步相关的操作都正确了
- 这一步就是检查网络配置,包括代理的配置
- 注意到,Joseph在检查这一步时,是鼠标在各个标签上飞快地点来点去,而不是认真地检查每一个点是否正确
- 这样做可能出于很多种原因,比如Joseph大脑中并没有清晰的上述这个数据模型;他只是下意识地在做这些操作等等
- 另外,在有限的时间内,如何从无限的可能性中迅速找到答案?(就像测试人员找bug一样。)
- 除非有特别的原因,否则不会在每一个小的点上都同等仔细程度地探索
  • ACTION-03)重新确认问题。修改Switchysharp为“直接连接”,访问facebook失败,访问sina成功;改为“使用系统代理设置”,facebook和sina均无法访问,说明代理设置的有问题。再次检查代理设置,没有发现问题,再次改为“直接连接”,问题依旧。
- 继续replicate,这个步骤试图重现问题。
- 首先回到不用代理的状态,修改Switchysharp为“直接连接”
- 然后启用代理,然后不用代理,然后启用代理。。。
- Joseph没有做明显的与之前做过的操作不同的改动,同样的操作却反复做了几遍?!
- 就像有的tester,同样的测试做过一次后,没有任何修改变化,再做一次
- 除非你心中非常明确自己在做什么,比如确认这个问题是否能稳定重现,否则意义何在?难道期望这次结果就不同?
- 在一旁观察的我,感觉此时Joseph有点进入焦灼状态了:一切可能的原因都试过了,为什么还是不行?
- 测试人员也经常会陷入这种状态,感觉复杂、混乱、没有头绪、效率低下
- 如果您注意到探索时的这种情绪变化,此时就可以应用“Follow The Energy” Heuristic
- 这是James Bach在*Secrets of a Buccaneer Scholar*书中谈到的一种Heuristic
- 它告诉我们,跟随你大脑的节奏去工作,效率最高,当感到混乱和效率低下时,不妨做些其他的事情或者休息一下
- 事实上,接下来Joseph很明智地选择了“Alternation”这个方法,搁置这个问题,我们开始转向其他的问题

至此,约10分钟过去了,搞不清问题原因,一头雾水,于是我们打算暂时搁置这个问题,暂时使用bing来搜索信息吧,于是接下来100分钟专注于解决GTest的问题去了。

- 这种规避问题的做法,我们这一天的结对中Joseph用了几次,让我感触颇深。对于我来说,如果遇到某个问题,一直没有解决,不知其所以然,就此放过了,我会不适应,这是我要学习和思考的地方。
- 从另一个方面讲,感觉开发人员遇到问题时,尽量使问题或者问题的影响“最小化(Minimize)”,无论什么样的手段,只要越过了这个问题就行,然后就可以将注意力关注到更关心的事情上去。不知道在解决bug的时候是否也是这样的思路?
- 而测试人员遇到bug时,是尽可能挖掘此bug影响的最大面(Maximize),将问题最严重的后果充分暴露出来,以便引起别人的重视。

吃完午饭回来,我们打算再次尝试一下,看能否解决代理设置的问题。 - (ACTION-04)删除Switchysharp,再次尝试,仍然不成功

- 午饭回来后,Joseph有了新的思路,删除Swithysharp这个扩展程序
- 这其实是另外一个很重要的Followup Testing技能,叫做“Isolate”-隔离问题,去除干扰因素
- 毕竟使用代理上网不一定非要用代理管理插件
  • ACTION-05)重新检查代理配置,突然发现Web代理的端口号为3218,其实应该为3128,于是修改端口重试,发现网络不通

    Smaller icon

- 这一步很有趣,有时你发现某个tester突然很神奇地发现了一个bug
- 其实偶然之中存在必然,发现别人发现不了的东西需要具备洞察力(insight),并不能全然归为运气的因素
- Gary Klein在*Seeing What Others Don't*书中介绍了很多发现洞察力的秘密路径
- 本次Joseph所走的就是一条书中称为“规律性的事件”的道路,James Bach称Joseph所做的为Blink Testing
- 用鼠标在“Web代理”和“安全Web代理”之间快速地来回切换,Joseph注意到一个问题:右侧的数据区本来不应该有任何变化的,可是他却感觉到每次鼠标切换后屏幕的闪动
- 注意到上述这个疑问很重要,这就是tester在测试中的一种feeling,很有可能帮助我们发现bug
- 果然,Joseph顺着这个疑问仔细看下去,发现了端口配置的错误
  • ACTION-06)重新下载Switchysharp,发现下载非常缓慢。这时 我提议,用Joseph的机器下载,然后拷贝到我的机器上。于是Joseph打开他的Mac开始操作,突然他想到以前拆叔因为某个事情帮他修改了端口号,去掉了前面的数字5,其实正确的端口号应该是“53128”
- 这一步问题的发现“少了一个5”,Josepgh走的是一条我们称之为“相互联系的道路”
- “我建议他先下载再拷贝”、“Joseph到自己的Mac上操作”、“Joseph联想到之前的一件事情”,“最后想到问题所在”,这些信息前后紧密相关
- “相互联系的道路”在测试中经常采用,很多情况下,tester的第一步操作看似与最终发现的bug没有什么关系,实则不然
- 这与Steven Johnson提出的一个很重要的创新模式“相邻可能(adjacent possible)非常相似,探索的过程就是不断地打开一扇扇相邻可能的门
  • ACTION-07)修改代理设置中端口号为53128,验证网络访问,成功。

结束语

测试中寻找bug的过程和定位问题时寻找解决方案的过程一样,都是高度探索的过程,占据核心地位的是具备高超技能的探索人员,或者叫做“匠人”,在这一点上,开发人员和测试人员,很多技能是相通的。

问题分析完了,我的心理却有个遗憾:实际上,在刚开始Joseph在我的机器上输入这些代理参数的时候,我已经起了疑心“他能记得准确吗?”,我一般会对照着原始数据输入这些数据。可是我竟然一直没有把这个担心表达出来! 虽然,我一直在告诉别的tester,测试中要抓住你的feeling,有疑问不要放过,我自己却放过了!如果我一开始就能问出这个问题来“你输入的这些数据对吗?”,这个问题可能只要1分钟就解决了,而不是20分钟!

But,who knows?如果真的1分钟就解决了这个问题的话,也许我们就错过了一次奇妙的探索之旅、错过了一次学习的机会呢?

后记

写完上文,突然感觉到这是一个很好的向别人解释我的工作内容之一“测试咨询”的例子。

时不时地会收到一些陌生人的求助,“xxx情况下,测试人员应该怎么办?”,“测试部门的应对策略是什么?”,“测试人员要学些什么?”,等等,问题五花八门。不会他们认为"回答别人问题",就是测试咨询了吧?!

我所说的测试咨询(也许更准确的叫法是测试教练coaching),是相对于我的另外一块业务“测试培训”来说的。测试咨询时,我很少讲测试理论,而是以实践为主,通常我会和一个tester结对完成一件事情,比如测试分析、或者测试执行。

结对的具体方式有多种,一种方式就类似本文我和Joseph的结对,以tester为主导进行测试,我在旁观察和记录,一个session过后(比如2h),我们一起讨论,我会告诉他这个session中他用了哪些测试方法、他的测试思维是怎么样的、有哪些可以改进的地方等等;另外一种方式是,以我为主导测试,tester一起参与,这样他可以体会到我的测试思路有什么不同;还有一种方式就是我们真的是一起结对、共同主导完成测试任务。这有点像Mob Programming中的Driver和Navigator的角色划分。

Smaller icon

tester在测试时大脑所想有两块内容,A和B。

A的内容是测试工作的具体内容,比如做什么测试、做什么操作等等,这一块的知识,测试人员都很清楚,每个测试人员都可以描述出来他刚刚做过了什么(WHAT DID HE DO?);

B的内容是测试思维和测试技能,一般测试人员很难描述清楚他刚刚为什么这么做测试,他是怎么想的,他用了哪些测试方法或测试技能(WHY和WHAT),而这就是我作为testing coach所做的事了。你不知道你脑袋里是怎么想的?别急,我来告诉你,你是怎么想的;你不知道你用了哪些测试技能?别急,我来告诉你都用了哪些测试技能。

下次做探索时,想知道你大脑中B这部分的内容?不妨找一个testing coach!

Comment Box is loading comments...