QA初窥

因为项目组的原因，在这个项目上是做的QA，作为应届毕业生，还是开发人员来说，没有真正意义上的接触过QA。虽说QA的起点比开发低，基础的自动化测试脚本和代码并不是那么难，注意是基础的，如果想将测试的代码写好，无论是业务层面还是代码质量角度，都做到精益，初期是比较困难的。

QA除了要从业务层面去考虑怎么保证产品的质量，保证以后的修改不会影响到现有的功能，考虑Bug的优先级，考虑Bug的价值以及修这个Bug的耗费是否值得，是否有必要。这些都要衡量，考虑。所以QA并不像开发那么容易，QA是保证产品质量的，不像开发，就算没有做好，还有QA来帮你发现问题，再改就是了。

第一周做QA的时候，因为不熟悉，尤其是对测试流程的不熟悉，因为我们的项目是和客户一起做，所以我测了以后，还有客户那边还要测试，而且第一周只是手动的去测试那些story要求的功能都是好的，还有会不会影响到其他ready的功能而没有想其他更多的。

有一天，彪妹（彪妹是这个项目组以前的QA，但是因为BA要离开我们项目组，所以他去做BA，让我做QA）给我说，你怎么保证你测的这些功能在以后的开发过程中不会被影响到。然后突然就有种醍醐灌顶的感觉，我确实没有想这么多，只是把功能测试了就是了，再看看对已有的UI没有什么不好的影响而已。

彪妹就给我讲了，测试三角（如下图）。最下层的是Unit Test，是写得最多的测试，但是需要测试数据都是模拟的，以及获得的web service返回数据也是模拟的，这样测试就不会受到其他因素的干扰，以保证代码功能和逻辑的正确性，Unit Test并不会与系统的其他service集成；位于中间的是Integration Test，是写得较多的测试，用于实际去请求远程service的服务，判断获得的数据是否正确，以确保集成是正确的；最上面的是最接近用户的，UI Functional Test顾名思义就是对UI以及流程的测试，验证流程是否正确，验证页面显示是否正确，验证页面的信息是否正确，是写得相对比较少的测试。开发每次提交代码前都必须在本地跑所有的这些测试，只有通过了才能提交，提交后也会在server上面跑所有的这些测试，以确保开发对代码的修改不会影响到已有的功能。

然后我就把所有我测过的卡都重新从这些方面梳理了下需要加哪些测试，检查开发有没有写Unit Test以及Integration Test，而我从业务价值以及功能上去考虑要不要加Functional Test。这是从技术上面的教育。

昨天给UAT的客户讲她需要测什么东西，因为Story没有写清楚，我测完了以后也没有加comments告诉她要测什么东西，也没有截图告诉她应该看什么地方。所以她发消息问我要测什么，这样就花费掉很多时间，虽然我有立马补充了comments和attachments，但是还是收到她的邮件，说如果下次再不写明要她测什么，她将会将卡移回Test，拒绝测试。这是与客户合作，沟通交流的教育。

确实是我想得不够多，所以做事之前还是要思考。不要那么想当然。

 

还有一个，关于每个story从创建到关闭的流程的问题。

1.开发在去领卡的时候，没有找我和BA做kick off，造成我测试之前还要去看一下卡的内容。这就导致BA建了一张卡，他知道内容是什么，然后开发做的时候去读一下卡的内容，到测试的时候，我又去看一下卡的内容，两倍多余的时间就消耗了，这个还是比较好的情况，如果开发和我对卡的内容的理解有偏差的话，那么这个时间成本还会增加，甚至可能让这个功能都是不正确的，不是BA写的那样的。所以开发领卡的时候叫上BA，QA一起kick off，BA讲功能，QA从测试层面思考怎么测，有没有什么其他影响，这个卡需要UAT测不，有没有业务价值，是story卡还是task卡，或者这个卡要和哪些卡一起测比较好，开发要讲他要怎么做，有没有什么困难等。这样效率和准确性更高。

2.开发做完开发工作后，需要自己本地测好以后，找我做shoulder check，在他的电脑上给我简单演示效果，我认为没有问题了后就用我的机子在其他的环境上面测试，然后要加UI Functional Test的要加Functional Test，这些都做完了以后要加comments，attachments，以告诉UAT的人需要测试什么。节约时间成本，提高功能的正确性，这样都清楚的话，给客户的印象比较好，大家工作也更加愉快。

通过规范这些，加上对项目的日渐了解，能够就一些卡提出从QA出发的问题，以及自己的看法。这是增加自己的主动性在这个项目中，能更好地有责任感地做这个项目，有我的思考在里面，才真正体现了我自己的价值。

到下一个项目的话估计还是开发，有QA的经验的话，在拿到一张卡的时候就会多一些不同的看法吧，对业务的理解，以及开发的正确性都会有所提高。加油，每天都不要虚度。