一个缺陷描述引发的血案

发表于:2011-8-17 11:02

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:qwen    来源:51Testing软件测试博客

分享:

  开发老大(开发老大) 17:52:04
  大家可以提相关的意见

  测试A(测试A) 17:52:07
  目前很多企业都存在开发与测试之间的问题,希望在接下来的时间,通过我们共同的努力为我们公司在这方面的建设有所突破。

  测试老大助理(测试老大助理) 17:51:09
  那二期就加上文档测试,并且大部分以文档为标准,例如需求文档等,这样就需要有参考价值的文档了,没问题吧

  开发老大(开发老大) 17:52:37
  一直以来如此的

  开发老大(开发老大) 17:53:05
  不过有些时候实际操作中需求变更方面做的不规范,导致文档不一致了

  文青山(文青山) 17:53:06
  呵呵。。公司开始往已定义级开展了。这是好事啊。
  文档测试需要罗列出检查点和生成报告。

  测试老大(测试老大) 17:53:10
  只是开发的文档写的有点简单

  测试老大助理(测试老大助理) 17:52:11
  一期的需求文档有点太笼统了,我觉得应该再详细点

  测试老大助理(测试老大助理) 17:52:15
  是啊

  开发老大(开发老大) 17:53:47
  双方问题都一步步来解决吧

  开发老大(开发老大) 17:54:13
  开发A提到关于测试bug提交方面的问题,建议测试下去讨论下总结下吧 看看如何改进

  开发老大(开发老大) 17:54:31
  需求方面的问题 我们开发这边也诚心接受

  测试老大助理(测试老大助理) 17:53:25
  要不我们测试这边开个会讨论一下吧

  开发老大(开发老大) 17:54:43
  在二期我们会按CMMI3的标准来要求自己

  文青山(文青山) 17:55:57
  测试bug单的提交方法和一些关键点,我可以把我知道的一个方法引起来。这是nokia和hw以及byd的要求。只是这个要求非常严格,连缺陷标题的字数和标点符号的个数都有限制。

  感悟:反思,反思再反思!换位,换位再换位!

版权声明:本文出自 qwen 的51Testing软件测试博客:http://www.51testing.com/?287227

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

33/3<123
100家互联网大公司java笔试题汇总,填问卷领取~

精彩评论

  • maomao0-0
    2011-9-06 15:59:46

    在我们公司,测试总是最后拿到资料,最后知道需求的变更,不利于整个项目的效率。

  • wolaizhinidexin
    2011-8-31 18:02:51

    wenyu757123 兄
    测试不是跟着感觉走的,在执行过程中是有一定方法的,跟着感觉走很多问题是不能够发现的.你所说的跟着感觉走,应该更像探索式测试的一些方法,只是你可能不知道这些方法而已.下面这篇文章,就是你所说的跟着感觉走的测试.但他确实不是跟着感觉走,是可以抽象成理论的.
    http://www.51testing.com/index.php?uid-287227-action-viewspace-itemid-243862

    fly_in_real 兄,看来是经过很认真的思考,并且对实践过程中出现的问题进行了总结,感觉像老手或者测试管理这块的人了.这是我目前看到最认真的回答了,在此感谢一下.谢谢你的回答!

  • fly_in_real
    2011-8-31 16:00:04

    这样的对话经常出现在项目组中,有些是隐晦的不说,有些则是激烈争论,其实个人觉得主要是归纳为以下几点原因:
    1.担负责任的勇气:
      很多人当遇见问题时,总是尽量的推脱自己的责任,所以激烈争论在所难免,如果我们的员工能够自觉的清楚的认识到自己的工作职责范围,并且拿出足够的勇气去担负责任,那么争论就不会这么多了
    2.没有团队的观念:
      IT领域是个很依靠团队精神的领域,一个项目总是依靠很多人一起完成,当项目中的每个人都能很好的意识到团队荣誉和集体利益时,就会变的容易相互理解,就会更多的为别人考虑,会经常的站在别人的立场上去看待问题。这样矛盾也不会激化,因为大家的目标是一致的,都是为了团队最后能成功的完成项目
    3.个人的专业技能薄弱:
      关于这一点,我不否认团队中存在技术牛人,而事实上,一个团队中一般情况下也确实会有几个人是技术方面的达人,但是在目前这个功利化的社会现状下,团队中的大部分人都是比较年轻的刚进入社会工作两到三年的人,对于这样的一批员工来说,本身存在着思维上,技术上的不足,很多时候不能正确到位的理解软件的需求,这样就从最基础的地方存在着风险。这点是目前无法避免的存在,很多项目中都会或多或少有这样的因素。(除非哪个老板愿意不惜血本,专门招技术比较顶尖,工作经验很丰富的人)
    4.表达不清楚:
    IT团队中,往往存在着这样一个现象,而且也是被很多人都忽略的现象,就是团队中,往往很多人在表达上都不能做到足够优秀,究其原因,个人觉得可以有这样几方面:一。IT员工大部分是理工类出生,这样的人往往习惯思考,不喜多言,在语言表达上缺乏锻炼。二。软件开发本身是件比较严谨的事情,这就会不知不觉的影响员工的心情,对于从事严谨事情的人来说,一般就会比较习惯思考。所以,在很多交流中,往往对方只能明白你说的一半内容。。。。。。
    5.公司对于项目的规范重视程度:
    好的项目规范,会对每个文档中的每个地方都有编写要求说明,这样的情况下,即使表述能力再怎么不好的人,也能按照文档的要求把一个文档或者BUG写清楚,至少能让很多人看懂大部分。但是,目前,出于公司规模,成本,人力,项目时间,等等各方面的因素考虑,很多很多的中小企业都不能做到很规范的项目流程,在这样的现实下,这个案例中的问题在所难免会出现。

  • thebestpan
    2011-8-29 16:36:28

    规范。 流程! 贯彻?

  • 米粒里找bug
    2011-8-17 23:46:46

    我们公司通过了CMMI3,不过现在用的是敏捷开发流程,开发与测试一起上班,这样测试出问题后,在指定时间统一的给开发重现问题并截取日志,这样有助于问题解决效率的提高

  • ygmmlcy
    2011-8-17 22:51:00

    这种情况太现实了

  • testsnap
    2011-8-17 20:43:45

    两个问题:
    1.流程化的问题,不单是测试流程的规范化,是整个开发测试流程/项目的流程规范化。个人的体会,流程是重要的,至少需要朝着这个方向努力;但是流程在一般的公司都是不完善的,也不是死的东西,必须根据实际情况来调整,符合自身的情况。
    2.沟通。开发和测试人员不是对立的,但是工作内容也可以说是对立的。合理的处理沟通中遇到的问题,不仅是每个测试人员和开发人员需要去做的事情,也是两个部门的领导需要时刻关注的。

  • 麻辣兔丁
    2011-8-17 20:26:13

    标题和内容看上去不是很一致,不过开发和测试的对话听有意思,有很多有趣的地方。最后一句话很有意义。

  • ruoshui
    2011-8-17 16:57:46

    如果能制定完善的适合的流程,开发和测试之间的分歧就好减少好多。一定要规定好必须做的事,和必须不能做的事

  • Mr.曾
    2011-8-17 11:31:55

    这个问题也是我现在遇见的问题啊 我们公司也正在准备CMMI3

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2023
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号