首页 测试 体会 查看内容

软件测试员,敢问路在何方?(第二部分)

2014-10-17 20:06| 发布者: | 查看: 767| 评论: 0

摘要:   “测试的未来”的相关参考文章:   ● 在谷歌2011年的测试自动化会议上,谷歌工程和创新倡导者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia负责开幕式主题演讲。他 ...

  “测试的未来”的相关参考文章:

  ● 在谷歌2011年的测试自动化会议上,谷歌工程和创新倡导者的主管(Director of Engineering and Innovation Agitator at Google)——Alberto Savoia负责开幕式主题演讲。他认为,我们曾熟知的软件测试已死 - 或至少是垂死的。我与几位同事看了这个视频两遍,大家都觉得这是很警醒的谈话,让我们更严肃地深思测试和事业。我强烈推荐每个测试相关的人去看看这个视频。主题中提到,初创公司对“我们正在做正确的事情吗?”比“我们正在正确地做事吗?”更感兴趣。也就是说,这里的质量真的不是我的软件或者服务是否有缺陷,而是我的想法是不是吸引顾客的最佳想法。这对我们的软件测试员有一定的影响,因为我们太专注于

  “我们正在正确地做事吗?”,并可能导致我们很难在初创公司找到工作。

  ● “众包”是最近非常热门的话题。你能想象一家拥有数以十万计的软件测试员的公司吗,它可以帮助其他公司在极短的时间内完成测试。这些兼职软件测试员的薪水和他们找到的缺陷挂钩。他们在不同的地方用不同的语言在不同的设备上运行测试。不同于我们的内部测试,他们像真正的客户般的运行测试。 uTes??t.com就是这么一个公司,该公司在这个领域相当抢眼,它将会对测试服务和测试移动应用的方式上有着极大影响。在内部,我们有几个团队,包括Bing,Lync,都在积极利用众包来测试他们的功能。对我们的测试员意味着是什么?仍是未知数。

  ● 由James Whittaker , Jason Arbon和Jeff Carollo编写的“ 谷歌怎样进行软件测试 ”,很详细地回答封面的上问题。能在迷雾下看到像谷歌这么一个大型技术公司如何处理软件测试的复杂性,是很具知识性和趣味性。一个有趣的现象是,在此书的出版之前,三位作者都离开谷歌,一位回到微软担任开发主管,和另外两个则加入了uTest.com。下面是 一次访谈 的片断:

  提问:在本书中,你提出了,“不要雇用太多的测试员”,并且在未来里测试工程师的作用在下降。你对此有何回应,公司认为需要更多的角色,以此划分开发人员和质量保证之间的界线?

  为什么你要这样的界线吗?谷歌已经证明编写代码和保证代码优秀的界线是模糊的,其结果就是代码被开发更快,并且潜在缺陷更少。雇用太多的测试员是为开发人员创建了一个依靠,对产品来说这就是有害的。当人们过于纠结自己的角色,会使我懊恼。“我是一个测试员”是一种不健康的心态。“我是一名开发人员”同样也是不健康的心态。当人们停止过多关注自己的角色,开始专注于他们的产品,这才是奇迹发生之时。这时候,每个人都专注于尽一切力量来打造他们能打造的最好的产品。

  提问:对当前那些考虑加入测试相关角色的测试分析师(test analysts)或新毕业生,你能提供最好的建议是什么?可以满足这个角色不断变化的技能。

  对待测试如同开发一般。获取一个CS学位,并擅长CS。证书和行业培训只会教你简单的东西。学习难的东西,并掌握它。软件测试员只做简单的事情,在很长的时间里仍然会被视为二等公民。不想被这样对待吧?那就获取一等的技能。

  ● Bing团队的融合工程(Combined Engineering)设想,对服务测试和软件测试员的职业生涯都是非常有趣的。在融合工程,软件开发工程师(SDE)们和软件测试开发工程师(SDET)们合并为一个“工程师”的角色,我们为交付服务而优化,而不是为软件而优化。换句话说,许多测试成为开发者,真正的开发人员只写代码,而不是测试。我认为这可能是服务团队的未来发展方向,今天的测试员可以更专注于监测,基础设施和工具,他们和开发人员是一样的。

  ● 我们的生产环境测试(Testing in Production)专家——Seth Eliot,认为TestOps是我们的测试的未来发展道路之一。你可以到这个链接看看相关信息。我认为生产环境测试能真正改变我们如何做测试以及测试员的职业的未来。这是TestOps访谈的一个小段:

  我认为测试领域的一个重要的变化将是我已经谈到过围绕测试服务和生产环境测试。我把它称为TestOps。

  测试员需要摆脱定式思维观念,编写测试 - 运行测试 - 评估结果。我们要使用大量数据(一般是指服务)作为产品的质量信号,而不是用日常运行的测试结果作为质量信号。这包括系统数据,如CPU,API请求,系统响应时间,以及(妥善匿名处理的)用户数据。此外,还包括在生产环境中持续运行时交易发出的数据。这些依然是测试用例,你可以得到持续的可用性和性能状况,而不是只获得每天的失败 / 通过的状态。这是一种技术,但它也必定会改变我们的软件工程。角色的分类与归类(role and specialization versus generalization)的问题,答案是应满足每个团队的具体需要。数据科学家做为工程团队的一部分,就是TestOps方法的一个令人兴奋的结果。

版权声明:本文出自 omg 的51Testing软件测试博客:http://www.51testing.com/?166582

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

相关链接:

软件测试员,敢问路在何方?(第一部分)


鲜花

握手

雷人

路过

鸡蛋

扫一扫关注最新动态

毒镜头:老镜头、摄影器材资料库、老镜头样片、摄影
爱评测 aipingce.com  
返回顶部