关于软件质量的思考 - 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这个工作是为了让产品的质量更好。那么首先，什么是质量，怎么样是质量好的东西？然后再来看看我们可以做点什么。