被分等级很正常，这就是现实，接受它吧。

测试工作不如开发重要，不管这种观点是如何形成的，原因何在，那都是前人种下的果。或许是因为他们还没有意识到到底软件测试包含哪些内容、有什么价值、重要性又有多少，因而产生误解。也许也是因为他们曾经满怀希望地招聘过很多测试人员，予以优厚待遇，却被深深地伤害了一把，并没有看到这些测试人员为产品为公司贡献多少价值，因而开始刻意地区分开发、测试的等级。

如果我们想改变这种情形，真正有志于改善测试、开发分等级情况的我们，不应该顾忌这样的“不公平”对待，恰恰应该向着这样的困境前进，用实际行动让他们知道，测试的价值和意义，以及测试人员的能力。为自己拼搏的同时，也为未来的测试人员们创造更加良好的就业环境。

我觉得这事从你做测试的那一天起就很明显的摆在眼前了，纠结无意义。可以说说为什么感觉不是一个等级。我的例子是指基础职位，一般公司，别拿什么IBM来喷我。

对公司而言，核心关键必然是能挣钱的人更加重要。销售之类的能直接挣钱的就不用说了。技术之类必然是能生产出卖钱的东西的人更重要些。产品，研发，设计，必然是首当其冲，没他们东西生不出来，而测试反而可有可无了。很多公司的初期是没有测试的，或者研发自己就兼职测试了。还有个关键点，测试的可替代性超级高。产品啦，研发啦，设计啦，人家手握命脉，重新来个人走入正轨需要一定的代价。测试，就算你不熟悉产品，就算没有需求，你不也能拿着陌生的软件开始测试么？这就导致了测试人员流动性大，公司也不会使劲挽留。

对一般的测试工作而言，实话就是入门很容易。我曾经供职的一家公司雇佣二十多名中专毕业生，分成三组三班轮换只执行测试用例。他们每个人只负责自己手里的那百十来条case，就像机器人一样，不停地执行。用例写的超级详细，只要一个小时，就能上手。这个例子可能有些极端，但测试就是这样，门槛很低。这就导致了一个问题，初级测试真的是什么人都有，龙蛇混杂。

难道就没有翻身之日么？我只能说，全看个人努力。关键点在两个，一个是是否产生价值，一个是是否容易替代。

你想要有地位，先和你打交道最多的研发同学，形成平等关系吧。

其实你做测试时间越久，就越会发现，测试和研发的地位会越来越平等。
我说的还是一般的公司，项目周期短，时间紧任务重，开发过程中需求偶尔还会变一变。
研发会信赖测试人员对其的代码进行验证，而测试人员必须掌握更多知识，承担这份信赖。
你发现的问题，研发不会第一反应是你环境有问题吧，而是直接开始处理问题。
研发会与你沟通他的实现方式，你也会跟他讨论你的测试重点，什么地方风险更大，更容易出现问题。大家彼此互补，共同合作。
这样的好处是不言而喻的，研发在开发阶段更好的处理风险，测试在测试阶段更有针对性的进行测试。甚至是针对研发的开发风格进行针对性测试。合作久一些的研发，我都知道他们老爱在什么地方出问题，没事提醒一下，减少不必要的bug。有的研发愿意先吧整个流程打通，再开始处理各种功能细节，最后处理UI。基本在测试的时候，我也会按照他的习惯来，省的他找来找去，思路也就乱了。改bug也很痛苦的，谁都会犯懒，看见改个文本啊，调个控件啊，肯定就先处理了。反而关键bug就被延后解决了。
能多做一步，就别少做一步。bug title 把bug相关信息都体现出来，bug描述最起码做到没错别字，别让人看不懂。UI的问题就截图，放上设计图圈出问题所在，能配上设计图路径那自然是最好。流程不对的，直接把相关需求附上。崩溃的问题，附上log。web端的问题，附上链接，标签，id。单机问题告诉他设备在哪。特殊数据，告诉他数据怎么获得，或者直接上传数据。

你可能会觉得这么做有什么意义，研发是觉得这个测试不错。可是对公司而言，并没有提供什么价值。
其实价值体现在两个方面，一个是开发周期的缩短，一个是产品质量的提升。
研发看你写的bug就是时间成本，看不懂还得多看两遍，把你找来问，还得耽误两份的时间，没准还得影响心情，改一个bug多出5个bug。。。

除了研发还有什么是能做的？真心说，多了。测试在整个项目周期中时刻都有参与的地方。
跟产品多多沟通，充分理解他想要的是什么。给需求文档找bug，产品经理们也是风格各异，有的不处理异常情况，有的不考虑相关模块，有的老忘了不同平台之间的差异。产品与研发有分歧的时候，以中立的角度给出建议。
主动找设计师检查一下UI，就算你的眼睛是像素级别，他们的眼睛是纳米级别的。。。有的颜色，在iPhone上看着好看，Android上就只能呵呵。有的UI风格，不同平台，还是有些差异的。设计师天马行空，有时候真的会考虑不到。

能参与的地方很多，前提是本职干好。参与这些不是为了提高地位，而是更好的服务与本职。掌握更多的信息，更多的技术，才能更好的以一个中立的态度，发现问题，定位问题，甚至是解决问题。你的价值体现了，地位自然会高。