测试人员有关遇到工作中特别不配合的同事的办法

(可以直接跳到最后一句)

这种同事,我可能从第一家公司就遇到过,第二家遇到的最凶,第三家压力大,大家情绪可能都不太好,第四家就是现在,又遇到一个233.

遇到这种(一般都是开发,有时候也有别的)一跟他们沟通感觉就像是欠了他们钱似的,我就觉得,嗯,怎么说呢。”你们丫脑子没病吧?“

哈哈。

心里的想法是对这种人有点触,总怕他们暴起攻击我。

其实可能还是有些触。

而我一般的做法是,就是好好沟通。

你跟我这装逼呢,我也没什么办法,我虽然懒得理你,但是心里真的不待见。

而且,有机会,我肯定也会反击。

不能把比都让你们装了你说是不是?

要真问我,对于这种人有什么办法没有。

我想说,没tm什么好办法哈哈。

你说,这帮比人就这样,那你还能感化他们不成?

我的基本原则是,工作上非得沟通那就沟通,不用沟通时爷也懒的理你,而且你老跟我这呛呛的,还冷嘲热讽,我tm……有机会的话肯定是会反击的。

不过可能不是在工作中,毕竟对方凶了,你要也凶,那你们就该掐起来了。

所以你得让着,但并不意味着你总得让着。

有机会,比如领导找你询问同事工作的时候,你就可以果断把这种不配合的甩出去。

其实,这种也不算给你使阴招,他本身就不配合,你不过是陈述事实罢了。

领导应该也懂,因为一定不会只有你一个人反映,而且领导平时也不瞎,不是吗?

该干干。

******************************************************************************************

上面是最后一句。下面是后来的体会。

其实不论做什么工作,别让自己心理压力太大,都是应该的。

我的方法,其实是帮助人适当的释放自己。

因为人真的需要这样。

你不用”哦,他是小人,我是君子,所以我不应该像他似的言语攻击别人。“

不用这样,心情不爽就说,该喷喷。

一句话总结:对二比给太多脸,就是对自己的不给脸。

与诸位测试共勉。

原文地址:https://www.cnblogs.com/eidolongo/p/11816277.html

时间: 2024-11-25 16:32:35

测试人员有关遇到工作中特别不配合的同事的办法的相关文章

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

转:什么样的测试人员是好的测试人员

1 工作积极主动 工作态度如何,是评价一个测试人员最主要的方面,一个高水平的测试人员(指纯技术能力)如果没有一个好的工作态度,在测试团队中有时候不但不能对测试工作起到推动作用,有时候还起到阻碍作用,而一个愿意工作的测试人员,哪怕他的技术水平不高,人也不聪明,但对自己的工作认真负责,你告诉他的事情,他都可以认真去做,这个测试人员也会对测试工作起到很大的促进作用.这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因.另外,测试人员对工作是否主动也会很影响一个测试人员的发展,举一个例子,

好的测试人员应该是什么样的?

1.工作积极主动 工作态度如何,是评价一个测试人员最主要的方面,一个高水平的测试人员(指纯技术能力)如果没有一个好的工作态度,在测试团队中有时候不但不能对测试工作起到推动作用,有时候还起到阻碍作用,而一个愿意工作的测试人员,哪怕他的技术水平不高,人也不聪明,但对自己的工作认真负责,你告诉他的事情,他都可以认真去做,这个测试人员也会对测试工作起到很大的促进作用.这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因.另外,测试人员对工作是否主动也会很影响一个测试人员的发展,举一个例子,

(转)你没有成为专业的测试人员,原因何在?

1.你认为测试并不是一份技术性的职业,所以并不去尝试学习理解产品的编码 如果你从事的是软件开发,至少会理解一些软件工程的知识.而作为测试人员,你应该能够读懂代码来分析产品,来理解代码的变更和修复将会如何引入其他的bug.黑盒vs白盒的日子应该结束了. 如果你不想这样,即使不用写任何代码依然可以从事该工作.但是如果你不去读代码,将会失去对整个测试流程很重要的一项投入. 2.只有当开发人员告知开始测试时才真正介入到整个流程中 大家如实的回答,在整个开发流程中何时开展测试的? 理论上我们想在需求收集分

您不是专业测试人员的10个理由!

为什么测试人员在某些组织中没有得到专业治疗. 你是专业测试员吗? 如果您在空闲时间阅读与质量保证相关的文章以提高您的测试技能,那么您将成为确定为专业测试人员的小型(并且希望增长)工程师. 在镜子里寻找答案 说实话,无论我们不被视为(测试)专业人士,我们都没有优先考虑像专业测试人员那样行事. 基于我有限的经验,无论我在哪里看到测试人员认真对待他们的工作并努力提高智慧,我还看到他们如何受到尊重以及他们的工作如何受到赞赏,这归功于它为本组织带来的价值. 所以说到这一点: 您不是专业测试人员的10个主要

51Testing专访史亮:测试人员在国外

不久前,我接受了51Testing的访问,讨论了软件测试的一些问题.以下是全文. 1.史亮老师,作为我们51Testing的老朋友,能和我们说说您最近在忙些什么吗? 自2011年起,我加入Microsoft Office部门,参与了Microsoft Office 2013的研发,主要工作是测试Windows版本的Office产品.目前,我正参与研发下一代的Microsoft Office,主要工作是测试产品和开发测试辅助工具. 今年,我的新书<软件测试实战>问世.这本书基于一个很朴素的想法:

我所理解开发和测试人员的关系

概述 开发和测试,起源本没有分家.社会精细化,分工出现,两者渐行渐远.开发人员,创造世界的人,在建造高楼大厦的时候,必会埋下隐患.测试人员,世界的验证者,以挑剔的眼光,审视眼前需要验证的对象. 代码是开发人员的产出:bug是测试人员的产出 人,被人盯住挑自己辛苦创造的东西的毛病时,如芒在背,总是不喜欢这样的感觉.      于是,开发和测试,逐渐对立起来.      人在分工后,思维方式也变得不同(测试应当是“证坏”非“证好”),所以,开发人员看待问题的角度和测试人员诸多时候不能合轨.     

测试人员和开发人员如何更高效的配合工作

一.对开发人员的建议: 控制版本/补丁发布频率(重要) a) 版本交付间隔保证在2个工作日以上,尽量避免出现版本/补丁频繁交付导致的测试不充分. b) 控制版本补丁数量,原则上除紧急补丁外,多个补丁合并发送.这样可以让测试人员对交付版本提供一个更准确的质量状况. 版本能按计划交付(重要) a) 根据青铜器上填写的版本交付计划或者约定的交付日期进行版本交付. 明确每个版本的送测内容(重要) a) 含故障单.缺陷编号.具体功能修改等,避免出现模糊描述:如修改了用户管理模块--应描述修改的具体内容.

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来