敏捷测试高效实践:测试架构师成长记
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人

1.3.2 软件测试在软件行业

业内较为普遍的一种现象是,公司高层领导在管理IT团队时,经常会把公司资源偏向软件开发岗位,而软件测试岗位得到的资源相对较少。这是因为从公司盈利层面出发,公司管理层普遍认为,在IT团队内部,软件开发岗位是“软件创造者”,是研发团队,是生产力;而软件测试岗位则是“质量检测者”,是花钱的团队。所以,公司的资源自然就会偏向软件开发岗位了。如果产品系统出现了线上问题,在有些公司中,开发团队领导甚至会对测试工程师来个“灵魂三问”:

● 为什么这个Bug测不出来?

● 测试工程师怎么测的?到底会不会测?

● 测试工程师的工作能不能快一点啊!为什么总是拖后腿,最后才反馈Bug?

这种发泄式的质问,让很多测试工程师非常不满,从而破坏了开发团队与测试团队的关系。

大多数IT团队都有很强的技术情节,这本身并没有错,IT团队也是靠技术实力在公司立足的。但团队中的一部分同事认为,只有编程、写代码才算是最有技术含量和前途的工作,软件测试人员既不需要编程,也不需要写代码,他们的工作就是每天对着电脑和手机“点点点”地测试,从而认为软件测试是没有前途的工作。

除此之外,你应该也遇到过或者见到过:产品在开发过程中出现了进度延迟,而产品仍需按照原定时间上线,造成了测试时间的压缩,这些风险给测试工程师的工作带来了较大压力,最终影响软件的交付质量。

总之,在软件行业中,大家都会自然而然地拿软件开发和软件测试进行比较,因为这两个岗位在日常的工作中合作最为紧密,而大家也会自然而然地去拿软件开发岗位的要求来对比软件测试岗位,这种偏见会让大家只看到了软件测试的弱势,而忽略软件测试的优势及测试工程师所能创造的价值。

软件测试虽然处于产品开发流程的后段,但不代表测试工作就一定要在代码开发完成后才能启动。比如,测试驱动开发法工作模式的实践,就是在开发编码工作启动前先行开展的。

测试驱动开发法是敏捷软件开发中的一项核心实践和技术。测试驱动开发法的原理是开发功能代码之前,先编写测试代码,然后编写功能代码并用测试代码进行验证,如此循环直到完成全部功能。测试驱动开发法的概念有广义和狭义之分,狭义的测试驱动开发法也就是UTDD(Unit Test Driven Development),即单元测试驱动开发;广义的测试驱动开发法是ATDD(Acceptance Test Driven Development),即验收测试驱动开发。

换句话说,测试工作可以发生在需求讨论、产品设计、代码评审等阶段,测试工程师可以参与其中,通过自身技能和丰富的测试经验发现问题缺陷、设计编写测试用例、尽早识别产品风险、推动问题的及时解决。由此可见软件测试是非常有技术含量的工作,想要做好测试工作是非常具有挑战性的。如今,随着产品的迭代速度越来越快,如何在有限的时间内提高测试工作的质量和效率,已然成为测试工程师最大的挑战。

小虎在毕业时去招聘会尝试应聘软件开发工程师,发现软件开发工程师岗位对技术能力要求较高,几次应聘都以失败告终。

大学的师兄给了他一个建议:“可以试试应聘软件测试岗位,软件测试和软件开发岗位有所不同,软件测试需要的技能更广泛、更全面,但是对编程技术的要求略低”。

果然,经过小虎的努力,终于成功应聘了“软件测试工程师”岗位。

注:offer——录用通知书或录取通知书。