navytest 发表于 2012-7-26 16:11:37

先准备一次充分的与领导沟通,看领导态度

我每天坐27路 发表于 2012-7-26 16:32:41

我这边虽然有测试流程,有规范,有文档,但我觉得把关不严,测试太粗糙,不够细腻,出来的产品肯定粗糙。国产机这样子什么时候才能做出好东西

lichunmei 发表于 2012-8-3 16:32:40

我们公司就我一个测试,往往没有任何需求文档可以参考,都是软件完成后,交给测试,很多时候程序直接把产品发给项目了,我不知道这样子要怎么提升和完善。

andyyoung 发表于 2012-8-3 17:11:51

我觉得有一下几条路:
1、争取领导的支持,落实规范流程和标准,即使团队能力有限,也能做好。
2、提升团队对业务和测试的理解力,做到不用文档也能测得八九不离十,甚至超越开发对业务的理解,进而征服领导。这也不用去搞什么流程。
3、走人。

readboys 发表于 2012-8-6 10:34:41

我这里只有6个人,负责全公司所有产品的软硬件测试,性能测试,软硬都得干,

wuliangye 发表于 2012-8-7 13:48:16

这个情况在很多企业中普遍存在,尤其是小企业中,没有流程,没有规范,测试人员工作千篇一律每天干类似的活。。。长期下来后果很明显,测试人员越来越没有兴趣,领导越来越不满意,开发人员越来越不信任,如此恶性循环。看到了问题想要解决,我觉得才有进步,最怕就是得过且过无所谓混日子,根据我的经验,这个时候明确测试流程非常重要,一定要让领导明白流程的重要性:

1 需求不明确,往往都是产品开发完了,才提交我们测试。提交的时候基本上没有什么开发文档,有的话也是和新系统基本不太一致,或者写的很粗,基本上能看出来的就是有哪些功能。细节性的内容基本上没有。
需求也是说变就变。因为需求没有定义的很细,最多算是一个功能性描述说明。测试人员也经常与开发人员争执。
---------需求不明确是测试碰到的第一个难关,不管是瀑布开发还是Scrum模式,测试人员一定要参与前期需求的讨论,越早参与越好;
2 领导总说测试很低级。很不充分。
-------领导说测试很低级,是不是因为你们一直在做手工测试,而且测试理论知识和实践知识匮乏?给领导的感觉是谁都能代替你们?领导觉得测试很不充分,是不是因为你们从来不给领导回报一些数据,比如测试覆盖率,测试通过率,bug统计报告?有了这些数据,我相信你在跟领导沟通的时候就不会存在测试很不充分的想法了。
3 时间充裕的时候是先写测试用例,基本上写的也很粗,都是一些测试点。开发人员也基本上不怎么看。基本上都是在测试过程中完善补充测试用例。时间紧迫时就不写用例,测试完再补。
-------时间不充裕导致测试用例编写问题,这个其实也是可以通过流程改进的,当了解了需求,开发在做设计的时候,测试就可以编写测试用例了,如果等到开发代码都提交了,这个时候再去了解系统写测试用例当然来不及;
4 测试组对系统功能的预期结果都是未知的。都是结果出来了,在人为去判断对或者不对。
-------同样由于需求不了解系统不熟悉,导致预期结果根本不知道,又没有充足时间去和开发沟通,无法知道功能的预期结果;
5 作为负责人的我,每一个项目都要去监管,协调,部署测试环境,管理测试版本,项目多的时候,自己也要负责测试。所有的测试的出口都在我这,2个测试组员就是测试,没有积极性,甚至一点都不爱去多想再测测细节问题。因为之前测试设计过程没有,都是在测试过程中逐渐熟悉系统,尽可能去挖掘新的bug。两位老员工也不爱多想。
------一般来说,测试leader是不需要参与测试的,主要工作是流程规范,环境管理,任务分配和一些协调工作,在你们组,只有3个人,而且其他两位还没有积极性,作为leader,是有责任调动组员积极性,协调测试任务的;
6 个人也认为测试很不充分。能力有限呀。但是不知道该怎么去管理,去提高测试质量。对于开开始介入的测试项目,怎么能设计出充分的测试方案和用例呢?

-------这个问题和第二点类似,你自己都认为测试不充分,那领导当然认为测试不行了,建议给自己充电,学习测试流程,测试理论知识,在实践中运用理论知识效果是最明显的


一点拙见,抛砖引玉,作为测试leader,一定要规范流程,并运用于实践,当流程确立并实践一段时间后,你就发现上面的6个问题其实都不是问题了:)

momang 发表于 2012-8-8 11:02:38

回复 2# piaolingxue423

当企业有了市场,有了一定规模后,就需要流程

lz的情况,目前三个人(不知道开发有多少人),这样的情况下,要建立一套规范的流程,比较困难

在流程的执行上那就更困难了

所以小型团队,我觉得以敏捷为主

主要还是要求各环节积极、主动、负责 去做

开发人员是否自测,这个有责任的开发,会对自己的程序进行测试

没责任的,即使自测,没有任何监督和检查, 质量同样好不到哪里去

momang 发表于 2012-8-8 11:02:48

回复 2# piaolingxue423

当企业有了市场,有了一定规模后,就需要流程

lz的情况,目前三个人(不知道开发有多少人),这样的情况下,要建立一套规范的流程,比较困难

在流程的执行上那就更困难了

所以小型团队,我觉得以敏捷为主

主要还是要求各环节积极、主动、负责 去做

开发人员是否自测,这个有责任的开发,会对自己的程序进行测试

没责任的,即使自测,没有任何监督和检查, 质量同样好不到哪里去

momang 发表于 2012-8-8 11:06:02

回复 11# haven6


    这个不是给老板洗脑的问题

看看老板想要什么

短期内完成产品,满足业务的需要?

还是想打造一款伟大的产品?

若老板只关注眼前, 别说洗脑

就是每天坐在他脑子里

一样没用


另外 老板在不同时期关注点不同

前期关注市场

半年后,市场有了一定基础

或是 市场上有了竞争对手

这个时候,老板的侧重点 就不一样了

找好时机,适时与老板沟通

若感觉没有希望了   老板对这方面完全不愿意投入

那你再纠结也没用

momang 发表于 2012-8-8 11:08:23

回复 11# haven6


    这个不是给老板洗脑的问题

看看老板想要什么

短期内完成产品,满足业务的需要?

还是想打造一款伟大的产品?

若老板只关注眼前, 别说洗脑

就是每天坐在他脑子里

一样没用


另外 老板在不同时期关注点不同

前期关注市场

半年后,市场有了一定基础

或是 市场上有了竞争对手

这个时候,老板的侧重点 就不一样了

找好时机,适时与老板沟通

若感觉没有希望了   老板对这方面完全不愿意投入

那你再纠结也没用

momang 发表于 2012-8-8 11:09:11

回复 11# haven6


    这个不是给老板洗脑的问题

看看老板想要什么

短期内完成产品,满足业务的需要?

还是想打造一款伟大的产品?

若老板只关注眼前, 别说洗脑

就是每天坐在他脑子里

一样没用


另外 老板在不同时期关注点不同

前期关注市场

半年后,市场有了一定基础

或是 市场上有了竞争对手

这个时候,老板的侧重点 就不一样了

找好时机,适时与老板沟通

若感觉没有希望了   老板对这方面完全不愿意投入

那你再纠结也没用

mainer 发表于 2012-8-14 14:47:23

网上搞一份测试的规范,根据你公司的实际情况进行简化,然后跟你老板聊,跟他讲实际的东西,,
收益!!!告诉她如果出一次以外那么损失是多少,跟他算个帐。
然后就是要提起测试人员的积极性,制定日常测试规范,严格执行,不执行给予惩罚,做得好的奖励。
其次就是跟开发负责人沟通测试的必要性和介入方式,至于说需求总是修改,这个没办法,大部分公司都有,所以你一定要产品人员在进行需求讨论的时候叫上测试人员,以便了解需求变化。

mainer 发表于 2012-8-14 15:30:46

作为测试主管,就算你不参与测试,但是你一定要熟悉项目业务需求,否则在沟通的时候你会很难受。

耗子砍猫 发表于 2012-9-12 16:12:40

小公司就不要在意什么复杂严密的测试流程。很同情你,兄弟。看来我幸福很多了,程序和策划的那帮人最开始也不愿意进行规范的流程,后来在我的坚持下,被我收拾得服服帖帖的。
流程的控制不光是你们测试的,包括整个项目的推进,以及各个人员的整体质量意识。
如果老板不重视,建议换一家吧,别纠结了。这种扯淡流程下训练出来的心理素质和对复杂事物的处理方式的思维以后会很有用。
我们公司的测试部是属于独立部门,由老板单独领导。我个人认为,公司对测试的重视和地位决定了以后的发展规模甚至竞争力。如果公司都不重视,比较难办。

耗子砍猫 发表于 2012-9-12 16:20:20

测试主管级别的人物是不用参与测试的,但是必要的几点:
1.了解你的产品定位。
2.知道研发部门的流程,包括版本发布流程和各个功能接口之间的衔接关系以及整个项目的架构。需要你清楚的认识到项目潜在的风险点,这些信息是帮助你进行测试一些死角和多个模块之间交替产生并发问题的依据。你要了解手上的项目最大的风险点和盲区,并调整测试方向和力度。
3.熟悉你手下人的性格和做事风格。不能一视同仁,有的测试员在某一方面极强,某一项测试能力可能不是很好,都需要你的引导。
4.沟通并不能完全解决所有问题。但是不能不沟通,沟通的方式可以是书面或者口头。相信你的项目有很多口头约定,如果这些约定多了,慢慢时间长了你会忘记,程序员会忘记,设计者会忘记,项目经理更会忘记。就需要你的记录和整理。虽然很繁琐,但是有用。
5.BUG管理工具一定要用。哪怕很简陋,每天都要花时间整理。BUG从发现到修复这个整套流程需要匹配你的项目特点。
6.如果遇到项目其他人员不配合的,向上级反应。不要生闷气或者自己扛着。

耗子砍猫 发表于 2012-9-12 16:24:45

还有。测试用例
测试用例给予一种安全感,在你测试的时候可以帮助你尽可能全面的测试,如果没测试用例,测试可能很不充分。如果觉得测试用例写着很费时间,能简化就尽量简化吧。我们项目是个大型的MMORPG游戏,测试用例单说条数已经接近5万多条,45个大功能点。还不包括性能测试的。维护测试用例的痛苦我是知道的。后期如果时间紧迫,我们都是采取灵活的测试方式:简化测试用例。但是测试用例不能不执行!

xiaoshi_2011 发表于 2012-9-18 13:57:49

这样的问题比较多,特别是一些小公司,我也遇到过,遇到问题也是一种挑战,尽力去解决,如解决不了,那么是你能力不够,或者这样的公司体制有问题,唯一的办法就是离开

Nexi 发表于 2012-9-18 14:48:26

看了这么多,收益匪浅啊

littlecorn 发表于 2012-9-28 15:17:57

深有同感,彷徨无助。。。

meetingh2000 发表于 2012-10-8 09:46:06

个人经验,没有积极性的人砍掉,提出团队。自己招来的人使用才顺手。根本上能解决问题。
页: 1 2 [3] 4
查看完整版本: 请教:一个测试负责人的苦恼。。。