现在公司的测试越来越牛了。

现在公司的测试越来越牛了。
1. 项目在上线阶段，需求变更和优化需求必定很多，上版本也十分紧急和频繁。但测试的坚持必需把版本计划制定好，开完版本评审会议，然后再去写测试用例，然后再测试用例评审，然后开发人员必需提供转测试文档。如果有一步缺失，拒绝测试。
2. 测试人员现在把QA的工作也做了，文档写得不好或流程缺失，发邮件并邮件标明抄送领导。
3. 测试数据需要开发人员准备
4. 让他去检查表字段是否存在，居然还要截图说明怎么检查。
5. 一个业务逻辑，测试了第三遍后，还要再问，还要重复讲第四遍。

现在要找测试测试，就是折磨自己，有时候觉得自己花点时间去测试比找测试人员来测还要省时间。
而且，这批测试不知道是怎样招进来的，简单的SQL都不会写，整天都想着怎么搞流程，干嘛不去申请做QA呢？

我发泄完了。。。。

----------------------------------------------------------------------------------------
感谢各位的解惑，有时候工作烦心确实需要发泄下，但发泄后还是要把工作做好。

测试和开发其实就是一对欢喜冤家。。。。。。。。。

这个直接问上级领导，到底是开发人员准备还是测试人员准备


让他看文档，要是再问的话你要表现的很不耐烦的样子，让他明白自己占用了别人的工作时间

向领导说明时间紧急，没有时间做这些事，请领导定夺。


按他要求改，改的时候及时沟通，直到对方认可。


拒绝截图，我认为测试也应该了解软件的功能，不是你告诉他应该怎么测，而是按照需求测试。

软弱的开发人员！

如果你对你的领导申诉这些事情，可能你的领导表面上会为你着想，会站在相对公正的立场上说测试组的同事都是猪头，但是，那些话只是为了照顾你的情绪。
而实际上，你的领导是非常想和测试组的同事搞好关系，所以他希望你能把活都揽下来，哪怕这些活都不应该由你来完成。

在这种情况下，你不能一口答应下来完成所有的事情，也不能一口反对。你要尽可能地表现的繁忙，尽可能的表现不能胜任这些事情。

因为，即使你胜任这些事情，可以预见的是，升值加薪也轮不到你。
相反，即使你不能胜任这些事情，你的工资、奖金也不会少一分。

可以看出，你、你的领导、测试组相关人员，在这三个角色中，或许你是干了最主要的活，但是在制度上，你是最可有可无的人

呵呵 别郁闷了 你还没遇到各种推脱责任了 那跟更郁闷

其实是你流程有问题,测试只是按流程办事.

试想,一个带着无数bug上线的版本能有多少意义?
而这些,由于测试不到位,bug回归不到位,严重影响测试进度.

想解决这些有两种:
1. 需求越早细化越好,防止后期来回变动
2. 拥抱变化,使用敏捷开发,不断在开发过程细化需求,但要有充分的自动化回归机制.

快过年了，看你工作真忙碌，公司，很高兴。
有经验的大牛，在下面回复你，你，很高兴。
这些内容都是对你有帮助的，你，很 高兴。
你能有这些想法，说明你在进步，你的领导，很高兴。
祝你和我们大家，在新的一年共同进步，大家很高兴。
所以，首先你要做的，是保持乐观的心态，这个对于你的健康和发展都很重要。
/******************华丽的分割线**********************/
1、在中国，在绝大多数的项目或者产品中。软件实现的全过程，不是必须的。具体哪些环节可以精简，可以按照技术人员、产品人员、设计人员的水平灵活调配。理论上的软件过程，需要全方位的支撑，这在很多中小公司，基本上脱节，有要求没承诺。希望这点能够平息你的怒火和怨气。开发过程是一个愉快的过程，这点需要你认同或者强制认同。敏捷开发真的挺难的，虽然我也实施过，但是对整个公司的技术、产品触动比较大，有一些外在的、人为的因素干扰，甚至可能因为这个丢掉饭碗，嘿嘿。不过我本人赞同部分项目产品敏捷，敏捷真的不错。
2、项目已在上线阶段，变更和优化这么多，说明产品经理做的不到位，没有与其他部门和领导把产品这个事情说清楚。同时，demo不够详细，没有预开发阶段；测试这么要求，那么要求，是为自己争取时间。有些东西是可以沟通的，比如测试用例的覆盖范围，是所有功能点全做呢还是只做重点？；测试文档分为两部分，其中功能部分，应该是由产品经理完成的，为什么需要技术全做？可不可以把测试用例的工作缩小到重点功能上？产品经理能不能带领团队来和技术一块实现测试文档？解决方案：沟通很重要，可以节省一些时间；demo不给力，导致技术开发反复，不断推倒重来。
3、QA的工作交给测试部门，没有问题。关键是不能同一个人或者同一批人来同时做测试和QA。QA是法官，QC是警察。这里面东西多了去了，小心啊。解决方案是不理会QA，同QC搞好关系。
4、测试数据开发人员有时间就准备，没时间测试人员自己做，这个东西没的商量。目前这种情况，说明开发领导没重视或者不客气的说，偏软。解决办法：给开发领导买壮肾补品或者换开发领导，这个都罩不住，怎么带兄弟？
5、表字段是否存在？请找DBA落实。
6、业务逻辑为什么要问技术？很奇怪的问题。如果技术人员骗测试怎么办？就这么通过了？！这个通过的业务逻辑是不是产品需要实现的？关于业务逻辑，是产品经理同时讲给测试和开发，测试和开发不要沟通业务逻辑。否则问题大大的。
7、发泄可以。回过头来还要思考。单纯的开发人员是做不好开发的。努力提升技术水平，同时在与产品、测试等部门的沟通中，要学会适当引导，主动深入。给你举个栗子：一个哥们在2004年做开发的时候，教设计人员如何兼容浏览器，教测试人员写LR脚本，同时在产品设计中，提了很多的问题来影响产品经理的思路，在产品prd制作的同时，配合做了很精致细腻的demo。最后，在具体的开发过程中，很省力。而且时间上，因为做了很多的工作，所以和其他部门沟通时间也很顺利，甚至这个阶段的产品制作差点就白盒了，很牛的。
8、今天过小年了，大家辛苦一年不容易。尤其是底层的开发人员，加班加点，做的东西让公司领导、客户很不满意。领导不懂技术，最后开发背了黑锅还不知道是怎么回事。同时也没有成就感！写这点东西，抛砖引玉，同时开发人员趁着过年也要思考为什么？凭什么？干什么？学什么？做什么？赚什么？
9、欢迎站短，虽然可能我不看，呵呵。北京的开发有兴趣换工作的可以聊聊。这就是我夜里3点多回复的目的。哈。

一看就是华为的流程···

    这种情形不是一家软件公司存在的，我想很多所谓有点规范的公司都会有这个问题。

    测试的为什么这么折腾？其实他也是不想背黑锅，现在的公司里的测试团队，还在项目需求分析阶段，他们就能每周出测试周报，群发N个领导，但是我详细看了每一份，内容都TM一样，就是不断改个日志，说XXX未实现，XXX实现了?%，cao，百分比都能算出来！为啥？就是给领导看的。

    做开发很容易背上骂名的，因为专注于技术，忽略了这些沟通问题。就像上面的回复一样，你揽下来，领导并不会觉得你能力多强，加薪升职可能和你关系不大，但是做不完，黑锅就是你背。

    建议： 1. 尽量暴露问题所在，既然要这么搞，你就不要太想着把事情做完，都反馈给上面知道

              2. 简单直接，在项目十万火急的情况下离职。别谈什么鸟发展，所谓发展最后还不是谈成薪资？哪里工作不是工作？

 

我觉得这个流程挺好的， 每一步都脚踏实地。

开发的眼光不要只看着开发那点工作量，如果因为测试工作没做细，最终暴露了bug给客户， 首先遭罪的虽然不是开发，但是往小了说返工也是工作量，往大了说产品的形象跟着也遭殃。

qc&qa的工作做细，虽然很繁琐，但是是有必要的。有些理所当然的，别人眼里也许是无法理喻的，反之亦然。换位思考。