阅读量:0
目录
测试工程师在软件开发过程中扮演着至关重要的角色，他们确保产品在发布前达到预期的质量标准，然而这一岗位也面临着一些困局和迷局，面对这些困局和迷局，测试工程师需要不断提升自己的专业技能，培养良好的沟通与解决问题的能力，并且积极适应行业变化，以实现个人和职业生涯的成功。
测试工程师的困局
时间压力：
软件开发周期往往紧张，测试工程师可能面临时间紧迫的情况，需要在有限的时间内完成大量的测试工作。
需求变更：
项目需求频繁变化，这可能导致原先设计的测试计划和用例失效，需要重新评估和调整测试策略。
技术更新及快速迭代:
软件技术和开发框架不断更新，测试工具和自动化测试技术也日新月异。测试工程师需要不断学习新技术，以跟上项目需求，这增加了工作负担和学习压力。
自动化与手动测试的平衡：
自动化测试可以提高效率，但并非所有测试场景都适合自动化。找到自动化与手动测试之间的平衡点是一个挑战。
缺陷管理：
确定缺陷的优先级，以及如何有效地与开发团队沟通并追踪缺陷修复过程，是测试工程师面临的另一项挑战。
测试覆盖率：
确保测试覆盖了所有必要的功能和边界条件，同时避免过度测试，这是一个需要仔细权衡的问题。
资源限制：
缺乏足够的测试设备、环境或人力资源，可能影响测试的全面性和准确性。
跨部门协作：
测试工程师需要与开发人员、产品经理、UI/UX设计师等多个部门紧密合作。沟通不畅或协作不紧密可能导致测试效率低下或遗漏重要问题。
测试工程师的迷局
职业发展路径不明确：
相比于开发岗位，测试工程师的职业发展路径有时不够清晰，可能会导致职业规划上的困惑。
测试策略的选择：
面对不同的项目需求和资源限制，测试工程师需要制定合适的测试策略。然而，如何选择最适合的测试方法、工具和流程，是一个需要不断摸索和优化的过程。
被低估的价值：
在一些组织中，测试工程师的工作价值可能没有得到充分认可，导致其在决策过程中的影响力不足。
跨领域知识需求：
高效的测试工程师需要具备广泛的技能，包括编程、业务理解、用户体验等，这对个人能力提出了较高要求。
沟通与协作：
需要与开发人员、产品经理和其他团队成员紧密合作，良好的沟通技巧对于解决冲突和促进项目进展至关重要。
技术创新的压力：
随着人工智能、大数据等技术的兴起，测试领域也在不断探索新的测试方法和工具。测试工程师需要关注这些新技术的发展动态，并思考如何将其应用于实际工作中以提高测试效率和质量。然而，这也带来了技术创新的压力和不确定性。
测试策略与执行的平衡：
制定有效的测试策略是一方面，而确保策略的正确执行则是另一方面的挑战，两者之间需要找到最佳平衡点。
面对这些困局和迷局，测试工程师需要不断学习、创新和实践，以提高自身的专业素养和应对能力。同时，也需要加强与其他团队成员的沟通和协作，共同推动项目向前发展。
新生测试力量缺乏对测试行业的正确理解
目前中国依然有很多高校没有提供专门的软件测试课程，在缺乏正确引导的情况下学生们对软件测试的理解非常容易片面化。他们会认为软件测试是一个重复且缺少创造性的行业。这个行业对技术要求低，从事这个行业的人员没有软件开发人员那么辛苦。
于是软件测试成了很多初出茅庐的同学“退而求其次”的选择；
我的编程能力不咋样，先找份测试工作凑合干着；
我成绩不太好，可能得不到好的开发职位，干脆投测试吧;
我是女生，不想那么累，投测试吧;
...........
因为工作原因，我几乎每年都会去做校园招聘，我发现这些年主动投测试岗位的同学，包括那些名校，几乎清一色都是女生。面试时问同学们为什么要选择测试，几乎所有同学的答案里都有“我细心”“我性格好”“我能够做好重复性的工作”这些元素。
也有一些公司对校园招聘采取统一“分配”岗位的政策，那些被分到测试岗的同学常常会十分沮丧，有的还会为此毁约。
还有很多新生测试力量会通过“测试培训机构”来加入软件测试行业，他们里面很多人都是因为专业不对口或者是学历问题才做此选择的，其中不少人将软件测试作为过渡，先入IT行业，再转别的岗位。
我们很少看到新生测试力量是因为了解测试、喜欢测试或希望成为优秀的测试人员才选择测试工作的。这必然会对中国的软件测试行业造成不利的影响。
管理者对测试缺乏正确认识
那些同时管理开发人员和测试人员管理者常常会在绩效上更认可开发人员的工作在资源上更偏向开发人员，例如开发人员容易比测试人员获得更高的薪水和奖金;如果增加团队人数，开发团队会增加得更多;如果减少则往往是先拿测试团队开刀;开发人员还会比测试人员有更多的晋升机会。即便是独立管理的测试团队，测试整体情况也常常不如开发“重开发，轻测试”在软件行业中依然比较普遍。这是因为还是有很多管理者根深蒂固地认为:“只有开发才能创造价值，测试不仅不能创造价值，还是一种开销。”当开发和测试被放在一起评价时，管理者会认为开发的贡献更大。
还有很多管理者虽然会认为“好质量是测试出来的，测试的价值就是找缺陷，缺陷发现得越多产品质量就越高”，但在实际项目中,“测试进入时间晚”“留给测试人员进行分析和准备的时间少”“测试资源不足”等情况比比皆是，使得测试效果远远达不到管理者的预期，给管理者留下测试能力水平有问题的偏见。
在敏捷开发模式下的实例化需求、开发者测试、自动化测试、重构、持续集成等实践可有效预防缺陷，提升代码内建质量，降低测试开发比，但也会进一步强化一些管理者对测试人员的偏见，那些管理者会认为“没有测试，项目不也好好的”“测试的价值确实不明显”“测试人员的能力水平确实不行”……我曾和一位管理者聊 DevOps 转型的事情，他的观点是“DevOps 转型就是从取消测试开始”。
不合时宜的要求
还有一些瀑布或是伪敏捷的团队，在文化、组织、能力、资源没有任何变化的情况下开始按照敏捷开发的要求对测试团队进行调整:
追求低测试开发，盲目减少测试人数，使得测试团队长期处于缺人的状态，正常的测试工作都不能有效开展；
过分看重测试编码能力，否定测试其他能力；
追求自动化率，但设计、流程跟不上，接口、UI频繁变化；
要求普通测试人员都能掌控那些非常专业的测试，比如安全性测试；
类似这样的不合时宜的要求还有很多，压得测试人员喘不过气来。
低门槛和测试外包
单从“入门”来看，软件测确实比较容易只通过点、点、点的操作也能验证系统。但要想成为测试高手，就必须对用户、系统、设计实现等均有深入了解，还要努力培养自己的测试思维，如系统思维、批判性思维、逆向思维和解决问题的思维。测试者的综合素质要求很高，所谓“入门容易，深入难”。
但是现实中，测试“深入难”的特点往往被忽视,“人门容易，门槛低”的特点却被放-“门槛低”的另一层意思就是“技术含量不高，谁都能做”，这使得在软件行业中测大一试外包非常普遍。
托马斯·弗里德曼在其名著《世界是平的》一书中将外包归为21世纪铲平世界的十大动力之一。站在企业运营的角度来说，外包的好处是显而易见的，可以让企业更加关注核心业务，建立弹性的人力资源体系。
测试外包有助于企业聚焦核心业务，但这暗示着很多公司并没有将测试作为核心去建设和发展。对正式员工而言，这也意味着企业可能会削弱在软件测试方面的投入，减少对测试员工的培训，没有考虑其职业发展。
对测试外包人员来说，频繁地更换测试产品，导致其无法了解产品核心设计，缺乏归属感，容易一直处于一种低水平的测试状态，自身能力难于提升和进一步发展。这对软件测试行业的整体发展来说势必造成负面影响。
缺少发展和规划
国内某知名软件测试网站发布的《中国软件测试从业人员调查报告》中的调查数据显示52%的公司对测试人员的职业规划不明确，26%的公司对测试人员没有职业规划，只有 22%的公司对软件测试人员有明确的职业规划。
对那些工作了两三年的测试工程师来说，他们对产品和测试技术都有了基本的认识足以胜任日常工作，他们很自然会开始寻找新的发展方向和目标。
一个发展方向是软件测试管理。但即便在瀑布开发模式下，软件测试的管理岗也不多更别提在敏捷开发模式下测试和开发不断融合、测试开发比不断降低的情况下，管理岗位就更少了。所以测试工程师要想在测试管理方面有所发展，不仅需要能力，还需要机遇。
当测试工程师进入测试职业发展的平台期时，就会变得迷茫、困惑，看不清自己未来的发展方向，需要指引，但又得不到帮助，这会是一件非常痛苦的事情。我的一位同事曾经拿“布朗运动”来形容他自己在平台期的状态和感觉，我觉得这个比喻非常贴切。正如《奥德赛》中描述的一样，还有什么比徘徊不前更让人感到难受的呢?
职业发展遇到瓶颈本来也很正常，但是如果总是得不到改善，就是致命的。在我身边，有很多测试3年左右的同事离职或者转岗。《中国软件测试从业人员调查报告》也指出，中国软件测试行业有超过7成的从业者的工作年限是0~3年，只有18%的人是3~5年。需要注意的是，这个比值从2009年开始就没有发生过变化，这说明中国软件测试人员在工作经验的分布上并不合理，缺乏持续性。我们正在丢失工作3年左右最有潜质的那些测试人员，如果这种情况一直持续下去，很难说中国的软件测试行业会不会出现“青黄不接”的情况。
