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