职业 测试人员的纠结之我不想打酱油!

文刀曰京木似水 · 2014年04月07日 · 最后由 思寒_seveniruby 回复于 2014年04月07日 · 56 次阅读
本帖已被设为精华帖!

测试人员的纠结

1、需求没有时,发现不合理的地方,这个到底算不算 bug?我提了会不会说我多事;不提,好难受,因为就是不合理,以后项目经理 PM 发现了肯定会问,我岂不是遭殃。

2、小 bug 是直接跟开发人员说,还是直接 QQ 或者当面说当面解决。录入 bug 系统麻烦,还浪费人力财力精力。

3、基本框架都没开发出来时怎么测试?尤其当需求也没有的时候,我测试也就是点点,其实连点点都不想点,1,开发们还在加急开发,不会搭理我;2,框架出来后还会去测试,现在测试重复测试,浪费时间和精力。

4、当开发在工作,工作量不大的时候,我要做什么?此时,测试 leader 要求我先看看,第 3 条我已经说了,心想没有意义你让我点什么?!但是毕竟是领导,点点就点点,努力找找 bug(页面开发都没完全开发,找出 bug,开发说我刚要开发,你别急,这不扯淡的吗),汗 ̄□ ̄||,一边还让我写用例,要用例评审,但是需求都不是很清楚啊,呜呜。。。 然后我还想自己看点自己的书,毕竟 IT 日新月异,而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了,不知不觉 1 星期,2 星期过去了,最后书也没看到,测试也没测试好。

唉,其实我不想打酱油。。。打酱油。。。。酱油。。。油。。。。

共收到 19 条回复 时间 点赞

第一个问题:需求不明或者需求不合理在很多公司,不同团队都有,需求不明,首先需要跟产品沟通下,确认需求,我们确认需求是在确认预期结果,所以只能产品给预期。需求不合理,首先清楚每个岗位的职责,QA 是对保证产品质量,也就是说最基本产品功能逻辑需要 OK,那这些都是根据 PRD 来进行测试的,所以当 QA(还是开发)对需求有疑问,或者不赞同的时候,通过沟通跟产品和业务,给出我们自己的建议,让他们接受你的建议,假如你的建议是合理的,而且是对产品的质量是有很大的改进的,假如产品跟业务不接受你的建议,你还是对自己的看法建议坚持,你可以找 QA manager,他会产品主管或者跟开发经理谈,通过上级去沟通。

第二个问题,首先清楚,QA 的工作是怎么量化的?BUG 数量是其中之一,那为什么不录入 BUG 系统?BUG 系统不止有 BUG 跟踪管理的功能,还是很多对项目开发有帮助的功能,而且 BUG 管理系统是可以作为以后跟开发有分歧的依据,各个 team 的老大都可以看得到,有记录可循,BUG 系统作用是很大的,不要简单理解。

第三个问题,项目一开始 PM 就会给出一个项目进度的时间表,什么时候需求评审,什么时候测试评审,都会有一个明确的时间点,那在需求评审还没有开始之前,你可能认为是一个 QA 的工作真空期,但是你确认自己在即将到来的测试工作需要的技能掌握好了吗?这个阶段可以作为你积累的阶段,至于你这个阶段提 BUG,还没进测,BUG 是不可能提的,清楚自己的工作,你提了开发也不会鸟你,可以以各种理由 reject。

第四个问题,用心,用心去看书,积累,才能积累到东西,想这里兼顾,那里兼顾,肯定会得不偿失。
综上所述,仅是给一个参考,其实我觉得根本原因还是自己不清楚自己的工作,没有给自己一个清晰的定位和规划。

  • 是 bug, 是问题肯定提。
  • 大小 bug 都要记录,可以不进 bug 系统,但是一定要记录,一定要让开发知道。
  • 在没有基本框架的时间,也就是开发人员开发的时候,可以帮忙 code review,做做 BDD
  • 很多时候,是流程的问题,改变不是一早一夕的,如果你的 leader 不想推动的话,那你就做点自己的事情呗。

#5 楼 @lihuazhang 前期开发还没有完成,发现的 BUG 可能在进测之后已经修复,当然记录是有必要的,BDD 和 code review 对于大部分测试人员来说难度大了,而且国内开发素质参差不齐,BDD 估计都很少人会了解,叫你 review code 可能不会。

#6 楼 @kevin_xu_v 谢谢你码那么多字来启发我。thanks

和我遇到的情形苟同

我很希望你能够认真的看我的回复。谢谢。

1、需求没有时,发现不合理的地方,这个到底算不算 bug?我提了会不会说我多事;不提,好难受,因为就是不合理,以后项目经理 PM 发现了肯定会问,我岂不是遭殃。

Monkey:从 bug 的定义来讲,不算。但是从测试人员本身来讲是需要提的。但是这个提并非就一定是要提到公司所谓的缺陷系统中,你可以和 pm 和 designer 一起进行讨论,再来确定到底是不是缺陷。我们始终要秉持一点,就是我们无论做什么都是为了推动项目产品往好的方向发展,而不是仅仅为了提 bug,或者为了不遭殃!

2、小 bug 是直接跟开发人员说,还是直接 QQ 或者当面说当面解决。录入 bug 系统麻烦,还浪费人力财力精力。

Monkey:必须录入系统。这个是一个测试人员最最最基础的行为。这个第二点我觉得你根本不需要考虑。

3、基本框架都没开发出来时怎么测试?尤其当需求也没有的时候,我测试也就是点点,其实连点点都不想点,1,开发们还在加急开发,不会搭理我;2,框架出来后还会去测试,现在测试重复测试,浪费时间和精力。

Monkey:首先这个问题分成两个。从项目的安排上来讲是需要测试介入吗?如果需要,那么如何介入?是 TDD 呢,还是用别的方法?如果可以点,那么就是某些模块的功能测试了。那么也是有一定的计划去测试的,如果你的测试任务就是要点点点的,那么你没有什么好疑惑的。如果是从项目角度来讲就不知道测试到底要做什么,那么你自己真的对于你要测试的产品了解吗?你真的对于你的技能那么有自信吗?如果不是,那么这个真空期你除了写测试用例,我相信你应该还有很多事情可以做。

4、当开发在工作,工作量不大的时候,我要做什么?此时,测试 leader 要求我先看看,第 3 条我已经说了,心想没有意义你让我点什么?!但是毕竟是领导,点点就点点,努力找找 bug(页面开发都没完全开发,找出 bug,开发说我刚要开发,你别急,这不扯淡的吗),汗 ̄□ ̄||,一边还让我写用例,要用例评审,但是需求都不是很清楚啊,呜呜。。。 然后我还想自己看点自己的书,毕竟 IT 日新月异,而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了,不知不觉 1 星期,2 星期过去了,最后书也没看到,测试也没测试好。

Monkey:我不得不说,你有点好高骛远。是的,大部分公司的产品(至少我去拜访过的公司)都是枯燥无味的,如果你觉得你的 leader 或者项目中的安排有任何不妥,你可以提出来,我相信大家想把产品做好的话,只要有意义的建议多少都会采纳点。另外来说你的好高骛远,学习每个人都想学,但是真的就从你做的事情当中没有什么可以学的吗?难道就只有自己看点自己的书才能够学习了吗?如果是这样的话,无论你到什么企业,什么项目你都会是这样的心态。而且从公司来讲,做好自己本份工作才是第一的,你这样的想法根本就没有人敢用你

以上

我个人说实话,我从第一个问题回答到第四个问题,要我碰见你这样的,要么滚要么做,废话多什么。我的原则很简单,有什么不爽的,觉得自己是对的话,那么就说出来,去改变。论坛上诉苦没有什么意思的。

1

1.需求没有时,发现不合理的地方,这个到底算不算bug?我提了会不会说我多事;不提,好难受,因为就是不合理,以后项目经理PM发现了肯定会问,我岂不是遭殃。

发现问题就要提出, 不要过虑, 多跟队友沟通可以增加很多的了解, 沟通有助于你了解产品, 也让所有人目标更明确.这是个成长的过程, 所以不要闷着. 在质疑和挑战中会出现很多有价值的思想火花.

2

2、小bug是直接跟开发人员说,还是直接QQ或者当面说当面解决。录入bug系统麻烦,还浪费人力财力精力。

小 bug 要提的 需要录入系统, 当小问题逐渐累积的时候, 就会发现一些规律, 比如这些小 bug 的分类是如何, 属于什么方面的问题, 如何针对性的解决, 如果这些问题不录入系统, 将来也就没法发现瓶颈了, 包括你的 leader 也不能发现产品质量的瓶颈是什么, 是界面, 接口, 亦或者是需求不合理等等. 这些数据对公司评估产品发展是非常有用的.

3

3、基本框架都没开发出来时怎么测试?尤其当需求也没有的时候,我测试也就是点点,其实连点点都不想点,1,开发们还在加急开发,不会搭理我;2,框架出来后还会去测试,现在测试重复测试,浪费时间和精力。

你应该学学分层测试, 在各个层面都有测试点, 过早介入可以评估需求和理性和产品设计的合理性,可以开展 TDD BDD 和 ATDD. 也可以做更多的辅助测试的事情, 比如前期就尽量要求研发提供状态日志和监控, 需要提供什么样的接口才可以让测试更容易. 其实越往前, 对个人的能力要求越高, 所以这么早就介入测试, 你应该感到高兴才对.

其中现实中会越来越多的出现这种摸索式的开发方式, 希望开发直接提供个成品给你测试的方式是上个世纪的产物了. 拥抱变化, 学习敏捷和精益思想吧.

4

当开发在工作,工作量不大的时候,我要做什么?此时,测试leader要求我先看看,第3条我已经说了,心想没有意义你让我点什么?!但是毕竟是领导,点点就点点,努力找找bug(页面开发都没完全开发,找出bug,开发说我刚要开发,你别急,这不扯淡的吗),汗 ̄□ ̄||,一边还让我写用例,要用例评审,但是需求都不是很清楚啊,呜呜。。。 然后我还想自己看点自己的书,毕竟IT日新月异,而且我是新人想多学点东西涨工资啊。一天天时间就在这么纠结中度过了,不知不觉1星期,2星期过去了,最后书也没看到,测试也没测试好。

前面回答了这个阶段是有很多工作可以做的.
关于学习, 这点我觉得你做的不够好啊,
因为就算工作很忙的时候, 我们也能抽出时间学习, 很明显你竟然还没有不忙的时候...
学习的方式也是多种多样的, 工作中也可以融入学习, 页面没完全开发完的时候, 模块代码, 接口都已经完备了. 这个时候就可以做很多的工作和学习了, 比如去读研发的代码, 学习部署, 研究接口调用关系等等. 测试的事情就更多了, TDD BDD ATDD, 估计你都做不过来的.
实践就是最好的老师和学习方式了

总结

你很有自己的态度和想法, 这点很赞. 不会像大多数人那样按部就班而不去思考其中的意义.
从问题中可以发现你目前还是新手, 很多你不了解的地方其实是有很重要的意义的. 多思考和解决你会进步很快.
实践是最好的老师, 希望你多珍惜这样的好机会. 工作和学校是两回事.出学校后就基本没有了那种上自习的机会了. 一切都是工作驱动的. 从工作中学习和成长才是最快的.

加油.
.

#10 楼 @monkey 你偏激了, 他只是个新手.一旦打开疑惑, 会进步很快的. 新人总是需要开导才行的.现在测试行业都是 90 后的天下了. 90 后有自己的思维方式.

#12 楼 @seveniruby 只是说的很现实,客观了点。至于将来是不是 90 后或者 00 后的天下,这个得看他们努力得程度了。

#13 楼 @monkey
#12 楼 @seveniruby
关于为啥不直接跟 leader 提出觉得不合理的地方,
1 是在快速开发的过程中,你提出些许建议,不会因为我的建议改变流程(也有我的建议只是很小或者很浅薄的原因),有的时候我提出建议,测试 leader 也说 “目前我们公司就这个情况,没办法”,而且有事情也是直接问开发,没有主动,测试很被动,我就觉得提出也没意思,也不再提了,就这么闭口了;2 是本人我也是内向的人,做事情是那种要有准备,不准备好就紧张的不得了,提意见这种事情,有几次就不错了,我的性格也令我很被动。我以后要逐渐改。
看了 monkey 的回复,我看一句,心里冷汗就滴一滴,确实自己很浅薄。
还有 seveniruby 的回复,很感动,多谢。
我觉得我发这个帖子还是很有用的,起码我内心得到震撼,这跟看别人的帖子是不一样的,就像是老师打屁股,打在自己屁股上才知道疼,疼是什么滋味,才知道继续前行。

以后少说话,多做事。

#14 楼 @jakewendao 我与其他人不同的是,只是接触这个行业事实太多了。我曾经一直说这样一句话 “测试在说别人看不起自己之前,先自己看得起自己”。也就是这个道理。只是对事不对人哈~~我和@seveniruby 以及@lihuazhang 他们反正正反都评论过,不能一味的只听赞美嘛,是吧

#15 楼 @monkey 是的,你们的话我都听进去了

我觉得这句话说的不对,少说话多做事,测试这个职位如果不说话会更加被动,这也就是为什么招聘测试的时候都需要沟通好些的原因。

这几个问题在我刚做测试的时候也都有过困惑的,从个人经历来看:
1、发现了需求 bug 是要提的,跟设定、se 沟通,自己理解错误,设定考虑不足都是有可能的,尽管刚开始开口有点困难,但只要秉着 “我在做正确的事情” 的想法,把问题说清楚了,最终都会发现:原来也没那么不好沟通,并且纠结也就消失了。
2、bug 录入有时候确实会话费一些时间,但却是很有必要录入的。时间充沛的就直接录入,时间紧的时候可以先 QQ 等报告给 SE,有空再整理录入。很多公司对测试的绩效是会通过 bug 数来评定的,bug 信息可以作为自己工作的一个记录,分析总结后也能让自己提高的更快。
3、测试对象的熟悉也是需要花费时间的,何不趁机好好熟悉一把呢,SE 没空搭理的话,可以先把问题记录下来,看他有空的时候再找他集中问下。其实有些时候 SE 不是不想理你,而是他自己正忙的焦头烂额,只是不想思路被打断而已。
4、工作中领导交给的任务,有时候确实是会让人模棱两可,如果有十足的理由说服领导这件事情没必要做,那你大可以找他谈谈,如果不行那最好还是说服自己的心情,想想看怎么处理这个任务比较好。关于学习:有些人用挤挤出来的时间做了很多事情,大多数人大把的时间纠结中度过,要不要做某件事情以前,重要的是先想清楚自己想做什么,想清楚了再去做。接受现在,不放弃努力,这就是我们要做的事情。
以上只是个人现在的一些感悟,希望能够与你分享。共勉

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册