今天我辞职了,致所有测试的信
我的两年多的测试生涯到头了。我想再这里总结一下点点滴滴。以及我也会说明我为什么选择离开。在中国有着很多很多的软件测试,很多迫于环境,迫于leader,迫于很多原因,导致只是一个“执行者”。以下只是我个人的一些经历。大家可以借鉴,可以吐槽。大家随意。
首先在测试的时候需要有一些心理暗示,其实未必是暗示,可能是给自己的一些自信。
第一:产品一定是有bug的。
无论你测试什么产品,一定是需要报有这样的心态。为什么?其实就如一句说的“如果自己都不爱自己,那么就不要奢望别人来爱你”。如果连测试潜意识里面都觉得产品是没有bug的那么还能有谁认为产品是有bug的呢?
测试的历史上有两种验证方法,一种是测试是用来验证产品一定是没有bug的,一种是测试是用来验证产品是有bug的。无论哪种你都要有一种原则,要有一种信念。就如人生漫漫长路一样,我们必须坚信自己的梦想,坚信自己是能够成功的。那么才有可能,才有希望。当碰见挫折的时候,当迷茫的时候,才不会真的被打败。
一个新的feature,一个刚刚fix的bug,一个用户反馈,一个不起眼的问题。我们都需要坚信里面有缺陷的。没有任何一个产品,任何一个细节是完美的。
许多公司从上级到下属对于产品的质量根本没有概念,又或者对于质量不重视。在这种情况下,就需要测试产生力量,需要用各种事实依据去告诉公司,告诉大家这样一个产品质量的真想。国外的公司相对好点,国内有很多公司是需要有这种有责任感的测试存在。
第二,任何的bug都是能够repro的
无论你面对一个很小的功能测试,还是很复杂的场景化的测试,又或者说某个用户很简单明了的描述了一个问题。我们需要坚定不移的告诉自己,只要是一个bug就是有重现步骤的。
微软曾经有测试,一个问题的重现步骤长达50步。虽然可能不是最佳的步骤,但是依然对于解决问题起到了决定性的作用。
自然,在实际中很多情况下的确会碰见一下子找不到重现步骤的方法。找不到方法意味着什么?意味着你可以开bug,dev可以fix这个bug。但是谁都不知道到底有没有真的修复这个问题。还可能因此出现很多regression的bug。所以找到一个bug的repro step可以说是一个测试基本功也是体现价值的地方。
和第一点一样,只有你自己信念中去相信了,那么你才有可能成功。
第三,只相信自己看到的
在很多情况下,dev或者同事会告诉测试“这个功能很小,没有bug的”“简单测一下就好啦”等等的话。我主张还是不要太相信任何一个人。
面对bug,我们需要好好的理清问题的根源逻辑,在进行一个完全的测试之后告诉自己“这个功能基本上不会有很大,或者很block用户的问题”;面对一个讨论,不要听到别人说什么就是什么,任何的决定都没有完全正确的。我们需要自己亲手去验证很多决定和设计,小到你可以google,找出各种证据来证明某些事情。大到你可以进行用户数据搜集,很多企业不会去做。但是如果一个有sense的测试,我相信必须什么事情都亲手去实践去证明!
以上说了这么多,可能很多人觉得,这个还是测试么?ok,我认为真正的一个测试满足以上三点是远远不够的。以下是我认为一个有sense的测试,记住是有sense的测试需要做到的。
第一:探知精神 乐于学习
为什么我将这两个放在一起呢。两者密不可分。我所在公司是做android产品的。目前中国国内很多企业也是一样的问题,就是只是在乎自己的产品怎么样,并不会很关心你的发展。作为测试,必须有探知精神,必须乐于学习。比如你测试A平台的B产品,如果只是一味的测试,只是一味的报bug。的确你会有进步,做任何一行你都会有进步,行行都能够出状元。但是几年光阴一过去,当别人或者自己问问自己,自己真的知道了多少?可能对于自己公司做的产品很了解之外,一无所知。那么这样对于自身发展又有什么好处呢?
探知,对于任何一个design,任何一个bug,任何一个细节都需要去探知。这样无论你做了多久,无论你是否做多少个项目都会依然有进步。时不时的问问自己,对于这个产品feature真的了解很透彻么?对于产品功能逻辑很清楚么?对于这个产品所在平台了解么?业内是不是主流的tools都清楚了呢?是不是自己已经没有了进步的余地了。这样自己会明了很多。
第二:责任
这点可能很多人会说,测试最基本的不就是责任么?没有责任怎么去做一个测试呢?是的,责任每个人都有,程度是不同的。你作为一个tester,需要保证产品的质量。勿以bug小而不重视,本质上依然是不负责任的表现。
相反的,很多测试对于产品是负责了,对于自己却是不负责任的。因为他们只是一个傀儡,天天被人操控着。做这个做那个,我觉得这种是更加可悲的。
如果你作为一个tester leader,那么你的责任不是去指挥别人做事情,不是去拍老板马屁。而是自己不要忘记进一步的学习,不要忘记对于任何的细节去了解。更不要忘记如果出了什么问题,自己勇于承担这个责任。真正的leader是什么?需要在流程以及技术上面有自己的sense,需要不停的去完善项目流程,从而提高测试team的效率以及项目的效率。
第三:通过各种渠道找到bug repro step
bug会从各个渠道发现。公司内部bug bash的时候,用户反馈的问题,自己找到的问题。老板发现的问题等等。这个时候能否找到repro step就是体现一个测试的价值所在了。
测试往往碰见的问题是这样的。突然发现一个问题,欣喜若狂!但是然后问问自己“我刚刚做了什么”,基本上很多人都不知道。有的时候是有log可以取,但是log只是一个告诉开发如何dev去解决bug的。所以找出重现步骤才是王道。并非要时时刻刻保持警惕,可以有两个做法,一个就是自己在测试的时候留个心眼,养成时不时回忆自己做了哪些操作。一个就是养成一边测试一边记录log的方法,这个方法相对很保险,不过前提是自己需要有完全看得懂log的能力。
另外一类bug是从用户这里报出。用户一般是无知的,根本不会懂你产品的逻辑,可能描述出来的错误和真正的错误根本就是天差地别。这个时候就需要测试去按照经验以及各种方法去判断。判断出用户说的产品的真正的问题在哪里,然后使用各种方法(automation.etc)去模拟bug产生的环境。这样一来,bug在修复的情况下能够在公司内部马上得到confirm。这样无论是对于产品,用户,还是公司都是一种无限大的利益。
还有一类bug是公司同事报出的,或者是老板提出的。一般都是一句话“这里有个很大的bug”。木有任何细节,木有任何解释。
当然,总结一下来讲,一个测试就如同一个侦探,慢慢的寻找蛛丝马迹,慢慢的看到真相。能够找到这条路的人那么必然是一个有价值的测试。毋庸置疑。
第四:bug定义sense
bug到底是什么?是一种缺陷么?是的。那么测试产品bug这个行为是什么?我相信很多书本上面都没有定义过。
测试产品bug行为定义:是寻找产生bug过程的一种行为,是缩短人们用产品开始到产品发生bug的周期的一种行为。
所谓找出bug,无非是一系列的操作序列造成了程序的缺陷或者崩溃。序列可能是几步,时间周期也可能是一年两年十年。那么测试产品bug不就是要在项目周期内尽量多的去寻找问题么?所以,其实本质就是,如果一个用户用一个产品十天才出现的一个bug,那么测试就需要压缩这种时间,将其在很短的测试周期内发现这个缺陷。
方法有很多,模拟环境,使用各种已经有的tools,使用各种automation进行测试,甚至自己写用户的一个环境等等。缩短用户发现bug的周期其实就是一种战斗,一场无止尽的斗争!
第五:UE
UE,用户体验。很多人会说用户体验是UI team以及UE team的人需要了解的。但是往往这个sense对于测试是最最最为重要的。
所谓最高级的bug,最有价值的bug就是贴近用户的使用习惯。但是如果一个测试没有UE,那么你如何模拟用户操作?你用户是使用windows的,是用mac的,是用android的,是用dvd机的等等,而你一个都没有用过,你何以测试?你何以找到用户真正care的bug?根本就是无稽之谈。
UE的学习对于谁都是有利的,无论你是做什么产品的,你是什么职位上面的。UE的学习是永无止境的。没有UE的测试只是monkey test罢了。
第六也是最后一点:勇敢的去做
和第一点不同的是,测试这个职业在国内还是一个比较新的职业。很多测试本身都不知道测试到底是干什么的。更加不要说一些互联网产品的测试。很多领域根本就是没有被开发过。你要做的就是勇敢的去尝试。可能有一个point,开始你的潜意识就觉得level太高,根本就是做不到的。但是你要去试试,不试试怎么知道不可能,勇于去做第一人。可能你做的事情就是别人没有做过的呢?要记住!你不去做总有人去做。我相信大家都希望自己成为第一人,而不是跟着别人的脚步再踏步踏。
目前只是想到这些,原本是想写工作回忆录的,却写成了这样一篇东西。真的惭愧。要不要写回忆录呢。。纠结!!
首先在测试的时候需要有一些心理暗示,其实未必是暗示,可能是给自己的一些自信。
第一:产品一定是有bug的。
无论你测试什么产品,一定是需要报有这样的心态。为什么?其实就如一句说的“如果自己都不爱自己,那么就不要奢望别人来爱你”。如果连测试潜意识里面都觉得产品是没有bug的那么还能有谁认为产品是有bug的呢?
测试的历史上有两种验证方法,一种是测试是用来验证产品一定是没有bug的,一种是测试是用来验证产品是有bug的。无论哪种你都要有一种原则,要有一种信念。就如人生漫漫长路一样,我们必须坚信自己的梦想,坚信自己是能够成功的。那么才有可能,才有希望。当碰见挫折的时候,当迷茫的时候,才不会真的被打败。
一个新的feature,一个刚刚fix的bug,一个用户反馈,一个不起眼的问题。我们都需要坚信里面有缺陷的。没有任何一个产品,任何一个细节是完美的。
许多公司从上级到下属对于产品的质量根本没有概念,又或者对于质量不重视。在这种情况下,就需要测试产生力量,需要用各种事实依据去告诉公司,告诉大家这样一个产品质量的真想。国外的公司相对好点,国内有很多公司是需要有这种有责任感的测试存在。
第二,任何的bug都是能够repro的
无论你面对一个很小的功能测试,还是很复杂的场景化的测试,又或者说某个用户很简单明了的描述了一个问题。我们需要坚定不移的告诉自己,只要是一个bug就是有重现步骤的。
微软曾经有测试,一个问题的重现步骤长达50步。虽然可能不是最佳的步骤,但是依然对于解决问题起到了决定性的作用。
自然,在实际中很多情况下的确会碰见一下子找不到重现步骤的方法。找不到方法意味着什么?意味着你可以开bug,dev可以fix这个bug。但是谁都不知道到底有没有真的修复这个问题。还可能因此出现很多regression的bug。所以找到一个bug的repro step可以说是一个测试基本功也是体现价值的地方。
和第一点一样,只有你自己信念中去相信了,那么你才有可能成功。
第三,只相信自己看到的
在很多情况下,dev或者同事会告诉测试“这个功能很小,没有bug的”“简单测一下就好啦”等等的话。我主张还是不要太相信任何一个人。
面对bug,我们需要好好的理清问题的根源逻辑,在进行一个完全的测试之后告诉自己“这个功能基本上不会有很大,或者很block用户的问题”;面对一个讨论,不要听到别人说什么就是什么,任何的决定都没有完全正确的。我们需要自己亲手去验证很多决定和设计,小到你可以google,找出各种证据来证明某些事情。大到你可以进行用户数据搜集,很多企业不会去做。但是如果一个有sense的测试,我相信必须什么事情都亲手去实践去证明!
以上说了这么多,可能很多人觉得,这个还是测试么?ok,我认为真正的一个测试满足以上三点是远远不够的。以下是我认为一个有sense的测试,记住是有sense的测试需要做到的。
第一:探知精神 乐于学习
为什么我将这两个放在一起呢。两者密不可分。我所在公司是做android产品的。目前中国国内很多企业也是一样的问题,就是只是在乎自己的产品怎么样,并不会很关心你的发展。作为测试,必须有探知精神,必须乐于学习。比如你测试A平台的B产品,如果只是一味的测试,只是一味的报bug。的确你会有进步,做任何一行你都会有进步,行行都能够出状元。但是几年光阴一过去,当别人或者自己问问自己,自己真的知道了多少?可能对于自己公司做的产品很了解之外,一无所知。那么这样对于自身发展又有什么好处呢?
探知,对于任何一个design,任何一个bug,任何一个细节都需要去探知。这样无论你做了多久,无论你是否做多少个项目都会依然有进步。时不时的问问自己,对于这个产品feature真的了解很透彻么?对于产品功能逻辑很清楚么?对于这个产品所在平台了解么?业内是不是主流的tools都清楚了呢?是不是自己已经没有了进步的余地了。这样自己会明了很多。
第二:责任
这点可能很多人会说,测试最基本的不就是责任么?没有责任怎么去做一个测试呢?是的,责任每个人都有,程度是不同的。你作为一个tester,需要保证产品的质量。勿以bug小而不重视,本质上依然是不负责任的表现。
相反的,很多测试对于产品是负责了,对于自己却是不负责任的。因为他们只是一个傀儡,天天被人操控着。做这个做那个,我觉得这种是更加可悲的。
如果你作为一个tester leader,那么你的责任不是去指挥别人做事情,不是去拍老板马屁。而是自己不要忘记进一步的学习,不要忘记对于任何的细节去了解。更不要忘记如果出了什么问题,自己勇于承担这个责任。真正的leader是什么?需要在流程以及技术上面有自己的sense,需要不停的去完善项目流程,从而提高测试team的效率以及项目的效率。
第三:通过各种渠道找到bug repro step
bug会从各个渠道发现。公司内部bug bash的时候,用户反馈的问题,自己找到的问题。老板发现的问题等等。这个时候能否找到repro step就是体现一个测试的价值所在了。
测试往往碰见的问题是这样的。突然发现一个问题,欣喜若狂!但是然后问问自己“我刚刚做了什么”,基本上很多人都不知道。有的时候是有log可以取,但是log只是一个告诉开发如何dev去解决bug的。所以找出重现步骤才是王道。并非要时时刻刻保持警惕,可以有两个做法,一个就是自己在测试的时候留个心眼,养成时不时回忆自己做了哪些操作。一个就是养成一边测试一边记录log的方法,这个方法相对很保险,不过前提是自己需要有完全看得懂log的能力。
另外一类bug是从用户这里报出。用户一般是无知的,根本不会懂你产品的逻辑,可能描述出来的错误和真正的错误根本就是天差地别。这个时候就需要测试去按照经验以及各种方法去判断。判断出用户说的产品的真正的问题在哪里,然后使用各种方法(automation.etc)去模拟bug产生的环境。这样一来,bug在修复的情况下能够在公司内部马上得到confirm。这样无论是对于产品,用户,还是公司都是一种无限大的利益。
还有一类bug是公司同事报出的,或者是老板提出的。一般都是一句话“这里有个很大的bug”。木有任何细节,木有任何解释。
当然,总结一下来讲,一个测试就如同一个侦探,慢慢的寻找蛛丝马迹,慢慢的看到真相。能够找到这条路的人那么必然是一个有价值的测试。毋庸置疑。
第四:bug定义sense
bug到底是什么?是一种缺陷么?是的。那么测试产品bug这个行为是什么?我相信很多书本上面都没有定义过。
测试产品bug行为定义:是寻找产生bug过程的一种行为,是缩短人们用产品开始到产品发生bug的周期的一种行为。
所谓找出bug,无非是一系列的操作序列造成了程序的缺陷或者崩溃。序列可能是几步,时间周期也可能是一年两年十年。那么测试产品bug不就是要在项目周期内尽量多的去寻找问题么?所以,其实本质就是,如果一个用户用一个产品十天才出现的一个bug,那么测试就需要压缩这种时间,将其在很短的测试周期内发现这个缺陷。
方法有很多,模拟环境,使用各种已经有的tools,使用各种automation进行测试,甚至自己写用户的一个环境等等。缩短用户发现bug的周期其实就是一种战斗,一场无止尽的斗争!
第五:UE
UE,用户体验。很多人会说用户体验是UI team以及UE team的人需要了解的。但是往往这个sense对于测试是最最最为重要的。
所谓最高级的bug,最有价值的bug就是贴近用户的使用习惯。但是如果一个测试没有UE,那么你如何模拟用户操作?你用户是使用windows的,是用mac的,是用android的,是用dvd机的等等,而你一个都没有用过,你何以测试?你何以找到用户真正care的bug?根本就是无稽之谈。
UE的学习对于谁都是有利的,无论你是做什么产品的,你是什么职位上面的。UE的学习是永无止境的。没有UE的测试只是monkey test罢了。
第六也是最后一点:勇敢的去做
和第一点不同的是,测试这个职业在国内还是一个比较新的职业。很多测试本身都不知道测试到底是干什么的。更加不要说一些互联网产品的测试。很多领域根本就是没有被开发过。你要做的就是勇敢的去尝试。可能有一个point,开始你的潜意识就觉得level太高,根本就是做不到的。但是你要去试试,不试试怎么知道不可能,勇于去做第一人。可能你做的事情就是别人没有做过的呢?要记住!你不去做总有人去做。我相信大家都希望自己成为第一人,而不是跟着别人的脚步再踏步踏。
目前只是想到这些,原本是想写工作回忆录的,却写成了这样一篇东西。真的惭愧。要不要写回忆录呢。。纠结!!
感谢分享,下一份工作顺利
我们公司测试少人。。。
什么公司的说
IT体,伤不起
加油~
谢谢 。嘿嘿
加油
果然三月份开始是跳槽旺季
嘿嘿
加油。
写的很好,谢谢
leader的马屁要拍,而自身的学习提升也不能落下。因为处理人际关系是软技能,同等重要,在职场中混必备的啊。做技术不能死做技术。。。
不知为什么跳又去哪里呢?
啊,我做测试噶,谢谢了
写的很棒
做测试前景如何啊?
我搞UI,产品做完做设计,设计做完搞测试,我以为这都是我一个人应该干的,原来不是这样,瞬间被老板使唤实习生的贪婪尺度搞不高兴了。
lz只是遇到一个瓶颈期了吧,再走下去就会发现要学习的东西还有很多。如果觉得自己只是执行者,那可以试着往team leader或者DM的路上走。国内许多公司的测试环境确实不理想,但当你依然对这个领域有激情,并且有这个能力的时候还是可以去尝试改变的。
it 伤不起
说的很好,测试需要有求知精神,像侦探一样通过蛛丝马迹,发现并还原错误
任何工作都都一样,需要求知和探索精神,即便是可能结果是错误的。
序员~~~你辛苦了!
辛苦!
加油
Well done! thank you for your sharing!
哎~~~每当从TV卖场经过的时候,总坏坏的想去玩出个crash来瞧瞧!!
谁做测试啊,我们公司招测试人员,有想法的联系我,互联网产品
啊~~伟大的测试~~万能的测试~~~测试同志们辛苦啊~~~实习小策划在此膜拜!
怎么一个图也没有.
為什麼可以用中文說的詞語非要用單詞來代替呢!
猜測本文作者是是做產品黑盒測試的吧?
额。。谢谢大家的回应。。我自己现在已经是离职状态了。。并且也找了一家新的创业公司继续学习。说瓶颈期是真的。。自己毕竟工作也就两年,我想在30岁之前多学习学习,而不是在一个地方当“长者”。可能很多人理解不了我的心态。@。@
这些是初级测试员应该做的事情,要想做一个能够赢得Leader,开发人员等等各方面尊重的测试工程师,更重要的是,多学习,测试理论,测试策略,产品相关的协议,规范。
交流能力当然是重要的,但交流中言之无物,只能指出问题的现象,动不动被开发一句设计就是这样的,这不是bug顶得哑口无言,明明觉得是bug,自己的知识却不足以为自己的立场做支撑,空有交流能力有什么用呢。
很多公司喜欢招菜鸟,实习生,跑跑用例,随便测测,过两年测试员自己觉着没前途,学不到东西,走了,公司就用同样的价钱再招一批菜鸟,节省成本的同时,形成一个低技术的恶性循环,并且让各方人等,包括测试工程师自己,都认为测试是一个低技术含量的工作,有些HR甚至特意会招些女生来做,理由仅仅是“女生细心”。
其实测试,包括黑盒,所需要的技术知识,一点不比开发少,但是个自由测试,就有不少测试策略,测试管理方法值得学习和研究,更不要说像手机之类的测试中,大量的协议规范需要了解。只要有兴趣,肯去学,这一行能做的事情是非常多的。
测试,就要对产品和开发狠一点。
另外,基本上大家都曲解了“敏捷”,过于浮躁的需要快速上版本,跟踪对手或者是跟对手区别,在速度面前,质量就只能靠边站,想着后续再优化。
但通常的情况下,又缺少精良的文档和严格的流程,又会让后续的优化十分辛苦,就干脆放弃优化,或者是推倒重来。
理解lz的想法。记得我在第二年的时候也出现过这样的状况,所以尝试了一些其他的东西。很多学到的东西都是融汇贯通的,尤其对于测试来说。转一圈之后,如果觉得自己的兴趣还是测试,完全可以再回头,到时候你的视野就会更宽了。
恩。。是的。。大家说的真好~~~
Hey Testers, Let’s Be Anti-Bottlenecks http://bit.ly/xEH98A :)
虽然说的是测试,但是对我这个做产品的也挺有帮助。
嗯。。是的。。其实很多sense不见得就是tester需要知道的。。只要做项目,做产品的。。大家都多多少少要知道点,才能够互补进步的说。。
PM飘过留下一句:开发好找,测试难求。
嗯。。是的。。两年多来,我也面过很多测试。目前国内的测试的确。。哎。。。
嗯,我也做过测试,按照规范协议,按照产品的feature来设计case,因为上面的时间安排,我总觉得很多时候是在匆忙地在时间限制内完成任务,很难找到bug并有时间去研究bug。。这也是很多同事感觉到的问题。无奈。
晚了先M下
虽然我做硬件,但是看了似乎也很有收获
太正常了。。。我做了三年功能测试。
研究方向是探索性测试和手工测试。
公司新来的人都喜欢研究自动化测试和性能测试。手工测试几乎无人问津。但是我总觉得手工测试才是王道。不是说自动化不好,但是不是所有产品都试用自动化的。对于CS/BS结合的产品,基础很重要。
不过虽然功能测试看起来低端,但是能做好的人真不多。
比如我,做了三年功能手工测试。最大的兴趣就是repro客户问题。
现在为了前途 我转行去做产品了。
哎,偶也搞android,今天刚拒了三个BUG,惭愧地飘过,楼主说的很在理,我处理的BUG里,三分之一左右的复现步骤是冗余或残缺的,而且很多时间大家对用户体验的概念不一致。
在研发这边还会有一种感觉,就是大家对最终的用户体验并不关心,leader关心的是PR的处理率,不管你是解了还是拒了,里程碑节点能到就好;研发呢,没有PR的时候可能还会自己测测,但基本上这种情况很少,所以,大部分时间里除了复现测试提的PR,就是想办法说服测试这个就是这么设计的,这么一来逃避问题成了常态逻辑,基本上没人愿意把宝贵的时间花在思考用户体验上。剩下的事情大家都知道了。。。
看到最后也没有明白为什么辞职
呀。是去做产品经理了么~~?好高级!
辞职啊。这个么。。因为没有提升的空间了
我们也招测试,电表行业,有兴趣站内短。
我也要辞了
呀 。。为什么呀
写的不错啊
工作两年当leader...这...
测试中。。。感觉没什么纠结的吧 挺好的
写的非常好。 good
测试需要学习开发技能吗
额。。一般来讲。。高级的测试的对于code的见解肯定比同等级的开发 来的深
> 我来回应