关于软件质量的思考 - Introduction

做软件测试的工作有几年了，有时会反思一下工作给自己带来的改变，除了生活上的，发现
也有一些其他的改变。其中的一点是对质量（Quality）更加敏感了，生活中遇到的一些不够quality的东西时很容易联想到软件质量上面。这大概是
某种职业病的先兆 :)

经常和同事开玩笑说，说QA做久了，人品变差了，bug会主动找到你。比如今天去交行转账给帮忙带ipad的同事，就发现
一个不能接受的ATM的bug。我没有交行的卡，就把招行的卡塞进去准备取现再去柜台转账。输完密码，提示我可以取1200元，觉得有点奇怪，英文叫
smell a
rat。为什么是1200？可能因为这个ATM剩下的cash不多了，好吧，那就先取1200再说。确定了之后就听到机器里面响个不停，屏幕上一直在显示
秒数倒计时，大概过了几十秒，也没有把钱吐出来，招行的提示短信倒是到了，扣走了1200.
然后屏幕显示ATM出错或者没有足够的现金，然后把卡退给了我，顺便给了个凭条。真是有点被搞晕了，明明钱扣走了，又说里面没钱了。机器里面没钱就早说
嘛。旁边的保安给我解释了一通，说让我拿着凭条去找招行要钱，觉着不靠谱，找了他们主管，问了一通，又让我查余额，发现钱居然没有扣走，或者按他们术语是
冲账了。

大概是bug见多了，遇到这种事情也还比较冷静，但是还是觉得很不可思议。ATM里面现金不够应该是个很常见的scenario，以前也
常遇到过，有些银行ATM的做法是直接把取款的菜单隐藏了，这样第一次遇到觉得奇怪，后面也就明白了，没钱可取就不开取钱这个门，也算OK。难道这样
basic的error handling的case他们也没有测到吗？真想记个tracker给他们的ATM软件研发部门，大概写成这样。

Title： ATM现金不够时处理他行卡取款交易不合理

Severity：
2

Priority： 2

Description：

重现步骤如下。

这个缺陷并不会给用户和我行带来
直接的经济损失，但是它会使得用户的使用体验变得很糟糕，造成一种钱已经被扣走，但是没有出钞的假象，引起用户的焦虑和投诉。同时这也增加了我们服务的时
间和成本。同时也会损害用户对我行的信任。特别是如果在非营业网点的ATM机上，使得用户不能及时了解真实情况，疑问不能得到及时解决，浪费用户的时间并
造成不满。

Re-produce steps：

1. ATM里面没有现金可取

2.
插入一张其他行的银联卡，输入正确的密码，按屏幕提示取款1200元

3. 确定并等待结果

Expected result：

1.
在没有现金可取的情况下，隐藏取款菜单或者提示用户无法取款。

2. 不真正从用户卡上扣款。

当银行业还是在垄
断的时候，这样的“小”case没法计较，就好像若干年前装个固话要花2000块还要请人吃饭的年代，停机一个小时也投诉无门。可是我想现在不一样了，当
你选择很多的时候，突出的优点是选择的依据，突出的缺点可以帮助来做排除法。这样的case，就可以直接影响到business，至少我没有意愿再去多办
一张卡了。

我们经常讨论QA的value在哪里？内部测试的时候遇到这样的问题坚定的指出来要求改正。

这个小故事其实可
以联系到很多。比如如何把自己放到用户的角度来思考问题。也许内部测试的时候，我们也可以认为这样的case可以不修，反正钱也没有扣走，或者扣走了又转
回来了，用户和我们都没有损失。但是，如果把自己放在一个普通用户的角度就觉得这是一个MBF, Must Be
Fixed。不是吗？如果你试着想想和我有一样的经历的话。

在刚开始做QA的时候，我被教育说测试就是验证实际开发出来的软件和
spec（软件规格或者详细设计）是否符合。很多时候我们确实是在做这样的事情，对着developer的SRS （Software
Requirement Specification）或者Detail
Design，来验证产品的功能确实如上面所说。这样的工作有value吗？应该有吧，至少可以保证做出来的东西是之前觉得要做的东西。

但
是，显然这样已经很不够了，因为

1.
只是按照spec来work的产品并不一定是质量好的产品，如上面的ATM，我相信应该也meet他们的spec。

2.
这样的验证spec的工作在现在或者以后的开发流程中要求developer更多的来保证。unit
test，TDD，或者很多公司的practice是developer就应该做这样的basic function test。

这关乎
QA这个工作的发展和出路。

最近我常常在想，或者可以换个角度来思考。根本来讲，QA这个工作是为了让产品的质量更好。那么首先，什么是质量，怎
么样是质量好的东西？然后再来看看我们可以做点什么。