从IT岗位转到软件测试差不多有快2年了，每一个行业的人都会在考虑自己所作的工作或者行业是否得到公司的重视，提高所在团队的地位。下面是从论坛讨论时候的帖子现在整理出来给大家都看看。
   
    通常真正要考虑这个问题的是一个公司的测试经理，当然站的多高看得多远，对于普通测试人员能在这个问题上有深入的考虑，我只能说句敬佩了。
   
    个人的地位很大程度决定于你所在的团队，而一个测试团队和其他团队或其他组织内的团队并无二异，它的地位取决与它所产生的商业价值，是诸多主客观因素决定的，而在现今的大环境下客观因素有时候占主导。各个公司并非没有牛人，为什么很少有人能真正扭转现状。但是我们应当看到的是整个情况正在向积极的一面发展，而对于客观条件的过分抱怨也没有多大意义，让我们来分析一下造成现状的一些原因。
   
    测试一般不直接产生商业价值，它是通过减少开发的损失来体现价值的。这里说一般是因为有例外，假如你能独立接测试项目能够直接创造利润。但现在有这个能力的公司屈指可数，本土的更是凤毛麟角。那减少损失不重要么？当然重要，而且是极端重要。但是你怎么衡量减少的损失？没有出现的损失不是损失，是无法估计的，无法变成活生生的统计数据摆在高层领导桌上的。三鹿出事情以前又有谁把质检看得那么重要的？更可怕的是高层明知道质量有问题却抱侥幸态度听之任之。软件行业里没有么？很多项目经理挂在嘴边的是：我的这帮伙计都有多年经验了，活有保证的。
   
    对策：无。只有在业界摸爬滚打多年，吃了不少苦头的企业才会刻骨铭心地知道质量才是生命线，靠说教是没用的。作为个人只好良禽择木而栖了。
   
    整个软件工程体系发展相对滞后。IT领域发展极快，中国软件业在商业应用上的快速发展显然没有得到理论科学的很好支撑。很多项目经理人都很年轻，是从程序员逐步成长起来的，缺乏对软件工程，项目管理的理论修养和经验，对技术和个人能力的迷信超过了系统的理论，对软件产业的风险估计不足。测试往往是他们容易忽视的环节，因为在他们早期的项目实践中缺少这方面的教训。很多项目经理相信开发人员足够应付日常测试，无需或只需很少的专职测试，这样可以压低成本。
   
    对策：无。随着一批民族软件中坚力量的成熟，科学理论的发展和实践应用，情况会逐渐改善。
   
    从业人员相对能力的薄弱。多种原因造成。
   
    首先是上述两大原因造成的大环境。哪个从业人员不想升职快加薪快。那他们在选择职业分支时无疑会找"吃香"的。在论坛上的xdjm特别是男生，想一想你们有谁在读大学的时候想着毕业要做测试的？这是一种恶性循环，软件测试人员的待遇越差越少的人才愿意投身，越少人才，他们的地位越难提升。
   
    其次是学校教育的缺位。高等教育是批量造软件人才的机器，这样生产出来的人才象机器的零部件和容易组合在一起，因为他们有较接近的职业素养和专业风格。有人形容印度程序员写出的代码都是一张面孔的，为什么？因为在学校里有人告诉他们什么是好的编程风格，什么是项目的佳实践，什么是完成一个模块的一般步骤。中国大学有吗？多少人是进了公司才知道注释的风格规范的？高考的应试作文倒是有点像，可惜一无用处。
   
    再次是测试人员在工作中相对缺乏提高技术能力的机会。相对于开发人员，测试人员接触新技术，或深入接触成熟技术的机会相对较少，需要挤时间来学习。缺乏系统的学习过程和专人培训。业余时间的自学效果远不如在项目里边做边学来的好。这也是很多软件测试人员很难从简单操作型向技术型转变的重要因素。
   
    还有一点是项目分工过细造成眼界过窄。qa的只管流程和整理文档，不懂测试，测试的只管跑用例，不懂开发。软件项目是个有机体，只看一块却不关注全局是很难适应未来的发展趋势的。而开发人员在测试上的适应性显着地比测试人员理解系统和代码强。
   
    后一个很重要的因素是很多测试人员经常被绑在某一产品甚至某一模块上很久。日久产生厌倦感或惰性。软件人员重要的一项素质是广博的知识面。但长期做一个或一种类型的项目显然是不利于发展的。
   
    对策：
   
    多学多动手，多争取实践的机会。有很多机会老板既可以让开发去做也可以让测试去做（比如一些配置项目或者基于成熟框架的小代码量开发）。假如你争取过来不但有了实践机会还可以借机显示自己的能力。很多事情你只要专心去做一定能做好，不要犹豫，不要有顾虑，别人能做的你也能做。
   
    关注技术发展。 多关心前沿技术的发展， 多和技术大牛交流。 这样可以拓展你的视野，很快提升总体技术能力和修养。 看过Jonathen Bach 的经历明白多懂些技术术语对交流和工作是很有益的。
   
    多关注一些行业规范。 建议专着于某种编程语言，熟悉它的风格和规范，这会有助于理解代码和静态发现缺陷。也可以对开发提出某些建议，这也有助于提高自身在组织的地位。 还建议一定要熟悉uml常用的图示。uml是软件工程师的公共语言 .很难想象不懂uml你怎么跟其他人在系统层面交流沟通。
   
    有机会业余做些开发项目，或是参与一些开源的项目。 熟悉一般的开发手段和流程。
   
    学会一般的研究手段， 知道如何在网络上获得所需的信息。在很多情况下谁先获得新的资讯谁牛。其实看一下国内很多所谓学术带头人的论文，也不过是比别人更早获得国外的前沿信息，然后整理一下而已。能做一些研究的测试人员还是颇受欢迎的， 因为他们通常都能自己独立地解决问题。 多留心收集一些好的网站是很有帮助的。
   
    后是调整自己的心理， 要敢于提出自己的想法和建议。要是你的建议能够被采纳当然可以提升你地位了。说不定还要你做专题的讲座。 也要敢于据理力争，但要有充分的准备。重要的还是要虚心向牛人学习。一个组织能够生存必然有一些人发挥核心作用，从他们身上无论是技术还是其他方面都能够学到很多很多。
   
    不知不觉写得太长了， 确实这个题目扩展开来有太多的内容
   
    另外一位仁兄zdlzx的回答
   
    了解别人是如何看待你的：明确当前开发团队和管理团队对于测试是何印象和如何评价的。这里面好的方面固然要继续保持和考虑如何做得更好，更重要的是不满的方面，需要仔细分析落实如何改进。我看到的测试团队有的并不能冷静地全面接受负面的评价，或者过于夸大某几个个别人的主观评价而觉得明明自己没有错，因此不知如何改进。对于后面这种情况，其实沟通本身是改进的一个重要方面。
   
    思考自己该如何提高：不管别人是如何看待你的，我们都应该经常考虑从自身做起，如何进一步加强测试人员的专业性。很多的时候，开发团队希望测试人员给出一些专业的判断，比如：测试这个版本大概需要多少时间？当前版本质量的风险在哪里？性能测试如何建模才能真实模拟生产环境的使用情况等等。如果我们测试人员不能很好地回答这些问题，甚至在某些时候还出现过在这些判断上的重大的失误，会很大程度上抹杀他人对测试人员的信任和支持。有不同的观点并不可怕，可怕的是没有观点或者坚持错误的观点。因此我觉得不管别人当前对你或你的团队评价如何，作为测试人员，你自己一定要坚持不断地试图在自己有话语权的地方不断磨练准确和敏锐的判断力。
   
   不要有"我们"和"他们"的意识。工作中，常听到测试人员把测试团队说成"我们"，把开发团队说成"他们".这看上去是个小事，但实际上是很需要提醒大家注意的。余世维先生的管理课程里有非常精彩的一段关于小我的"我们"意识的批判。当测试团队对开发团队提出改进的要求或者建议的时候，请认识到每个开发人员也和你一样聪明能干（一定有什么你不知道的原因使得他这个bug反复fail或者这个版本的质量很差），也请伸出你的手去提供一切可能的对方需要的帮助（即使那看起来不象是你职责范围内需要做的），甚至是多一点宽容和耐心，也许比你义正言辞地指出对方的问题，不留一点情面要好一些。请时刻提醒自己在软件开发团队中你不可能独善其身。请时刻反思自己：你有没有总是从开发团队/人员的角度去考虑问题，你能不能拍胸脯说你已经做到你能做的好了。
   
    一个软件开发项目组，一个软件公司，象一个大家。如果每个成员都能正确看待自己，不断提高自己，多一些理解和友爱，那么也许我们不那么关注地位的高低了，因为你已经得到了一个win-win的结果：相互的尊重。