总能听见有人说“
手工测试没有技术含量”,“做测试,还是
自动化测试,
性能测试比较有前途,能学到东西”等等。
首先,我想的是,什么是“技术含量”。我觉得,一般指的有“技术含量”的,就是你能做别人不能做,或者你完成目标比别人快的多的事情,如果随便一个人很快能上手完成你所做的
工作,就不算有技术含量。就好像只把伪代码转换为语言的程序员,有多少“技术含量”?从这个角度上看,很多人觉得“手工测试没有技术含量”就不足为奇了,因为如果按照用例去执行,给出明确的预期结果,谁都应该知道用例执行是通过还是没有通过。那如果不是用例的执行而是去设计,而是编写用例呢?给出一个功能点,每个人是否都能快速的设计出有效的测试用例呢。答案一般是否定的,最少同一个公司,有的人写的快,有的人写的慢;有的人考虑的周全,思路很清楚,有的人写用例和不写用例一样,想到哪写哪。测试用例的设计总该算是有“技术含量”了吧,不懂业务的,熟悉业务要很长时间,不晓得逻辑方法的,肯定先要把逻辑弄清楚。
再次,不管什么工作,什么事情,只要能持续的做的深入,总会有能力上的提升。(个人认为,能力包含技术,还有技术以外的东西)对于测试来说,如何定位一个问题,就可以做的很深。这一点可以举两个例子来说明,第一个例子是在浏览器中登录QQ空间,输入密码时输入“m”、“w”等输入到一定字符后就会换行,而输入“l”“i”时就不会换行,加入我们把这种现象直接报给开发,还有一种做法就是对问题进行细化,找到原因,即是计算字符宽度的原因,还是计算“*”的宽度的原因等等。第二个例子则是上传或下载文件失败时一是直接把失败的结果报给开发,另外一种做法则是将问题细化,是网络的原因,是格式的原因还是文件大小的原因等。这两个例子中如果都是后一种,对问题解决起来也快,开发也愿意配合,自己也能提升技能。的确,一开始细化问题的时候,会很费力,但是“火车刚发明的时候比马还慢”,当你能力提升了以后,会发现处理问题会越来越顺手。(如果碰到无法理解的问题,肯定要给开发,不能自己转牛角尖,但是开发修正后,可以去问是什么问题,怎样修复的。)说句比较考张的话,把平凡的测试变为不平凡的分析去做~
最后,说
其他方面的成长。我们肯定很明白一点,测试不是凭想象,想怎么测,就怎么测的,总是在开始测试之前,先把思路理清楚,测试的策略想清楚,于是锻炼了思维。我们总是在描述bug的时候,担心开发看不懂,每次以他人的眼光来审视写的bug,是否有歧义,复现的步骤是否更直白,语句是否更简练而清楚,顺带着,是否有截图和图上重点的标示,于是锻炼了文字描述。我们总是会和开发确认缺陷问题,于是我们锻炼了沟通。也许有人会不认同这也是一种收获,那可以问问自己,我们有没有测试到一半,发现漏了功能点,重新回头进行测试的情况;我们有没有写bug后,开发看不明白,打回的情况......
任何工作,当想有没有前途前,想想自己为此付出了多少。如果做自动化或性能,只会简单的入门,而不去深入,结果又是什么呢?