第一次与开发冲突

上一篇 / 下一篇  2013-01-30 19:01:54 / 天气: 晴朗 / 心情: 郁闷 / 个人分类:人际沟通

 

导火线:

开发 说:
   
路径:"首页"->"境外股市"
   
问题:在表格中"名称"这个字段的长度偏大,导致后面几个字段很拥挤,"日期"这个字段与表
             
格的边缘线紧紧挨着,应该留有适当的间距。保证表格的规范性与美观性。见附件
    PS
"境外期货""国内期货""人民币汇率"这几个页夹里的表格存在类似问题。
开发 说:
   
这个是客户的意思,还是你的建议
测试:
   
建议
测试 说:
   
这个页面没有需求文档
开发 说:
   
像这种建议以后不要再提,这个人家都运营了几年都没提
测试 说:
   
只是建议吧,因为没有文档,没有具体标准衡量
开发 说:
   
建议也不提,都运营这么多年,有问题客户早提了,你们还提这种问题,这不是画蛇添足吗
测试 说:
   
我们只是从测试规范性角度看问题
测试 说:
   
你们又没文档给我们,只是让我们按照自己的理解测
测试 说:
   
这种问题产生是必然的
开发 说:
   
你们也要从我们角度来考虑,你们提一个这种没有价值的建议,我们就花很多时间去看
开发 说:
   
要文档找规划部去补
测试 说:
   
这个文档应该是上游部门去卡
开发 说:
   
别扯这个,干点实事吧
测试 说:
   
你们不卡,我们这出现这些问题是必须的
测试 说:
   
那你就别说话这么激动
开发 说:
   
跟你解释那么多次,还不明白,那啥整,要不,你们提问题时,先问问你们老大看该不该提
测试 说:
   
你自己看你怎么说话的
测试 说:
   
我明白你的意思
测试 说:
   
那你问我们老大看该不该提

 

问题分析:

      这是一个东北证券的VIP终端,属于公司的一个老系统,没有任何文档,开发也不太维护。也许是开发在这个系统上修改了一些东西,打到测试部门进行测试。组长可能已经把相关修改内容测了,出于让我多接触测试业务的目的考虑,让我进行全面回归测试,时间安排为4小时。但是这些细节问题我并不知情,初步接触测试,对于老大分配的任务不会懈怠。虽然是4小时安排,我还是利用周末时间加班进行了一遍颗粒度适中的测试,大概花了8小时。一共提了十几个bug,其中大部分是明显的错误,小部分是涉及界面风格,规范性的问题。

         周三开发火了,QC里提的相应bug"已否决"状态。并且在内部交流工具找我理论,态度比较激动,谈话内容如上。我本来脾气也不好,第一次遇到这种情况,我尽量让自己冷静,做到不卑不亢。我的原则是:1.要和对方说清楚事情,做到以理服人;2.自己不能被气到,容易引起肝郁,对身体不好。从上面的谈话内容来看,貌似一条都没做到。事后我找经理沟通,正好遇上公司发布各产品的用户满意度调查报告,终端产品界面设计、用户体验度差成为最主要问题。CTO正好这两天刚找经理谈话,大概意思是说测试不够严谨,很多界面问题不把关,近期一大主要任务是对终端界面进行梳理与优化。理所当然,经理很支持我,并且找CTO进行了反映,正好以我这件事进行了举例。

       说了这么多,我不是炫耀我解决了问题。相反,我觉得我存在很多问题,这件事从根本上并没有解决,并且还会引起一系列的问题,包括产品质量、开发与测试以后的沟通、领导关系、自己的心情、以后的职业发展。总结下经验教训吧,如下:

         第一,尽量不要接手没有文档的任务。文档是测试人员提缺陷的依据,没有文档,我们的工作将会比较被动,容易被开发牵着鼻子走,吃力不讨好。开发也会从心理或者行动上藐视测试。要对公司的产品进行全面了解,针对不同的产品要进行不同方式的测试,对于没有文档的任务,尽量不要接手,当然如果确实没有办法,要根据产品来进行不同方式的测试。PS:发生这个问题,主要也是不了解公司产品,执拗地当成普通产品进行测试,导致矛盾产生。

      第二,要加强测试流程规范,避免此类问题浪费时间。很多测试人员的最后目标肯定会是走上管理岗位,这就需要我们从现在起就要关注管理,关注流程,用心去想一些问题,去分析一些现象。开发打过来的任务,输入物与产出物,我们要在流程上进行控制。对于国内很多软件公司来说,流程不规范,无文档化开发很正常。但是我们不能因为大家都这样,就安于现状,任事态发展。对于新开发的模块要进行严格把控,必须有文档方可测试;对于旧模块我们要尽量弥补。这样也可以解决新老交替,人员流动等带来的技术流失问题。流程不止于形式,我们需要行动。The executive ability is important!

       第三,测试人员要有良好的职业素养,坚持自己的原则,态度要强硬,从为做好产品的角度出发。一些问题如果不提出,承担责任的将是测试人员。

       第四,自己的技术实力一定要强,更有底气与开发进行交涉。

       第五,自己的心理素质要强大,不能被工作左右心情。

 


TAG: 人际沟通

nightxxxx的个人空间 引用 删除 nightxxxx   /   2013-02-26 14:11:36
说说其他细节,这里一直强调的有没有需求文档,跟这种问题应该么有直接关系吧?有问题就应该提,但是需求文档有没有不应该找下层开发,应该通过流程规范去压,跟单个开发说文档,根本没意义
慢慢悠悠的测试 引用 删除 fengzhulin   /   2013-02-06 17:50:46
我认为这件事情双方都有不对的地方;
我觉得你应该先和自己的直线leader先沟通,这种体验、界面类问题是否应该提。如果得到leader的许可,就尽管提;如果leader都否决了,那么她肯定也会告诉你理由的。这种没有文档的前提下,直接和开发沟通这种需求,肯定会有争执出现的。
左右子曰 引用 删除 mkatsoho   /   2013-02-01 10:57:15
点评三句
其一:典型的对话,常年发生,无新意欧
其二:5点总结,只有一点的一半有效(第三点)。如你所述,测试的地位和权力才是决定因素。
其三:没有CTO,你的manager想来也无计可施吧。不过,未来客户体验差,QA仍然会被首先被问责。有木有?!
引用 删除 51testing_bell   /   2013-02-01 10:56:35
很多公司都有这样的项目, 有时候客户出很少的成本, 要求就是保证核心功能就可以; 于是测试人员变成了费力不讨好的角色, 连PM都不予支持.

说不上是谁的错, 希望在项目初期, 管理层能够把一些理念与大家共享; 按照bug级别标准进行测试粒度的界定.

个人认为测试员并不是将细致发挥到极致就是好的, 在bug级别和修复成本之间进行平衡是项目每个成员的责任, 没必要为了明确责任而推给leader. 只要公司的管理不是很变态, 我们就都担当得起.
左右子曰 引用 删除 mkatsoho   /   2013-02-01 10:48:08
-1
引用 删除 51testing_bell   /   2013-02-01 10:47:56
5
Gerrard的空间 引用 删除 Gerrard   /   2013-02-01 08:52:52
你做的对,只是你的公司整体水平太低。提升自己能力,去更好的平台。坚持原则!
Runa 引用 删除 rulen   /   2013-01-31 16:58:15
这种情况是很郁闷的,如果迁就开发,会让我们觉得自己不专业,不够负责任;如果坚持到底,又会得罪一大片开发。。。不好混。。。
我的做法:bug尽量提出,bug是否为closed状态由负责人定。
引用 删除 alin4721   /   2013-01-31 16:37:12
5
引用 删除 alin4721   /   2013-01-31 16:36:53
其实,我看到的是上头在这方面表现出来的关注态度,这个才是问题得以解决的关键。最近我也碰到类似的问题,但没办法,没地方找人说理,又不能越太多级去反馈,只好等待项目总结时候一次爆发。。。
北方的郎 引用 删除 吼吼哈哈   /   2013-01-31 12:16:38
5
 

评分:0

我来说两句

我的栏目

日历

« 2024-05-17  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 1490
  • 日志数: 1
  • 图片数: 1
  • 建立时间: 2012-12-06
  • 更新时间: 2013-01-30

RSS订阅

Open Toolbar