我在测试生涯中受益的一件事是,我确实对软件开发编码方法和概念有所了解。虽然我可能无法从纸袋中编码出自己的出路(或者至少在我窒息之前),但我可以阅读代码并了解正在尝试的内容。

这是一个很好的考虑因素雇用新的测试员时,还是仅仅是简历上的“奖励”项目?

评论

我认为有很多这样的人:一些特定的编码技能,许多非特定的技术和“软”技能。其中一些人会成为出色的测试人员,所以这是一个很大的问题!

#1 楼

这取决于您希望测试人员执行的操作。我确实认为这是一项值得花更多钱的技能,但是我宁愿拥有一个热情,熟练的测试人员,而不是为大多数职位读取代码的人员。至少要有一个可以阅读(最好是编写)代码的测试人员是一件非常方便的事情。

一方面,您有可以使用自动化工具但不能修改它们的测试人员,但是知道哪些测试可以发现错误,并且擅长减少错误和进行交流。这些测试人员通常经验丰富,可以解决测试问题并将其快速分解。我很幸运能与这样的人一起工作,并且我从他们那里学到很多东西。但是,他们只能进行黑盒测试。虽然黑盒测试可以涵盖很多内容,尤其是精通测试的开发人员可以执行测试计划审查,而经验丰富的测试人员通常可以猜测无形的边界或执行熟练的探索性测试以发现隐藏的边界,但是其中有些在另一端,您有SDET,他们是完全的软件开发人员,他们将自己的技能应用到软件测试领域。 SDET不仅会测试,而且通常还会开发测试工具。编写代码的测试人员可以编写固定装置,自动检查,测试脚本等,并且可以编写组织良好,可维护的自动化测试代码。关键的缺点是,这样的测试人员也是开发人员,并且像开发人员一样获得报酬。第二个缺点是,这样的测试人员可能真的想以纯开发人员的身份工作,并且他们的测试技能可能很薄弱。

对于您提到的中间级别,您将获得白盒测试。这样的测试人员是可以查看代码以识别等效类和边界的人,除非您查看代码的实现(或有过多的规范),否则它们是不可见的。您还可能会得到调试,具体取决于测试人员在IDE中的舒适程度。熟练的代码阅读者也许可以通过使用界面来确定功能的行为,从而减轻开发人员的前期文档负担,从而使文档可以在该周期的后期编写,并且测试可以更快地进行。熟练的白盒测试人员甚至可以参与代码审查,并在未进行编码之前就发现潜在的错误,从而消除了原本专门用于解决这些问题的额外开发和测试时间。但是,由于该假设的测试人员无法编写代码,因此开发人员可能仍需要为该测试人员的自动化开发工具。

评论


这是所提供方法的最佳答案,因为它很好地描述了可以读取代码的测试人员的优缺点及其一些实际示例。我喜欢@Joe的答案,也确实提到了对代码的理解是所有测试人员的要求。

– Tristaan​​Ogre
2011年5月20日17:10

#2 楼

从成为开发人员到手动/自动质量检查职位以来,我发现最有用的事情就是能够以他们所理解的术语和语言与开发人员进行交谈。

评论


那是一件好事。但是您考虑过这个事实吗?开发人员为什么不尝试用我们的语言进行更改?为什么您必须向后弯以适应他们的思维方式?

–srini
19/09/26'6:25

#3 楼

读取和理解代码的能力对所有测试人员都是有用的属性(在我看来),并且是对某些测试人员角色的严格要求。

但这是否是雇用新测试人员的好条件还是仅仅是富裕程度完全取决于特定职位的需求。

#4 楼

这取决于产品和位置的需求。如果职位要求测试自动化,那么编程背景显然是有用的。它也可能表明适用于其他技术技能的一般能力,例如数据分析。当然,缺乏编程背景并不意味着没有其他技术技能。

我遇到了具有编程背景的测试人员,他们加入了QA,成为了成熟的开发人员职位的垫脚石。只要测试人员真诚地愿意在质量保证职位上表现出色,就像他们希望在最终开发人员职位上所做的那样,这没有什么不对的。具有编程技能,但在需要时不愿进行手动测试的测试人员,或者通常对测试不感兴趣的测试人员,将承担责任。

评论


对于不想在需要时进行手动测试的测试人员,+ 1承担责任。并非所有内容都可以或应该自动化,并且这些功能也需要进行测试。

–凯特·保罗克♦
11年8月17日在10:40

#5 楼

我确实认为这可以对您的简历有所帮助。并且可能取决于您要在测试中执行的操作。

但是,我认为并非所有测试人员都需要这样做。一个好的测试团队应该是能够进行代码和自动化的人员,具有丰富领域知识的人员和其他具有出色测试技能和背景的人员之间的平衡。如果仅由一种类型的员工组成测试团队,那么最终您会遇到一个表现不佳的偏颇团队。他们可能会自动将日光从您的软件中删除,但是如果没有领域知识,可能会使所有错误的东西自动化。

#6 楼

主要的好处是,能够读取代码的测试人员也许能够找出根本的错误,而不仅仅是报告错误。

取决于所涉及的编码技能,这可能并不适用于所有应用程序,但可能会用于Web应用程序,因为它处理的技术有时会被认为具有较短的学习曲线,例如JQuery,JavaScript,CSS,HTML等。

作为另一个示例,如果您知道一些SQL,具有了解SQL过程,键,联接等内容的优势。

以我的经验,拥有一些知识比拥有100%或0%的知识要好。

一个风险是,如果您具有更多的编程技能,有时您会因提高代码的想法而分心,而忘记了寻找潜在错误的作用。

在我看来,并不是具有编程技能不会伤害您作为测试人员。

#7 楼

在2011年,正确的答案是“取决于...”。

在2019年,我感到情况发生了很大变化。特别是在过去的4年中(2015-2019)

我现在申请的每个测试职位的标题或描述中都带有“自动化”字样,而我进行的每次面试现在都是“数据结构和算法101” 。通常以其他任何东西为代价。我是一名编写代码的自动化工程师,但是不幸的是,对递归和性能效率的直截了当的测试在检查优秀的自动化工程师的技能方面非常有限。我反复接受了应用工程师的采访,他们公开承认他们对自动化必不可少的编程技能了解甚少。他们知道的唯一工具是测试不相关的技能,而不是非常相关的技能。命名和创建高质量(可维护)代码并避免过早优化根本无法实现。

行业中的大多数人也接受了“编程面试使用在实际工作中不常用的技能” (对于自动化或应用工程师而言)只是可以接受的东西。我拒绝了在加入自动化工程师之前,我曾在多家公司担任应用程序开发人员,并从那次经验中获得了这些知识。顺便说一句,对于性能工程师来说,肯定有擅长诸如此类技能的职位。根据我的经验,他们只是少数职位。

这种趋势困扰着我,但我不能为每个人改变。
基本上,如果您想要自动化工作,则最有可能采用数据结构和算法。自动化是否成功,以及如何衡量自动化,是另一个问题。

#8 楼

我认识到的最大优势是能够理解代码并形成良好的直觉。知道如何实现它(实际上不是逐行查看代码)无疑有助于缩小原因。尽管不一定要让QA /测试人员告诉开发人员错误的原因,但始终可以进行理性的讨论。这也帮助我赢得了开发人员的尊重。反过来,这有助于避免许多不必要的冗长讨论或争论,因为开发人员对测试仪具有良好的信心。

有效地节省了时间。让我们考虑一个基于UI的产品,该产品将在多个浏览器上进行测试。如果测试人员对代码有很好的理解,则他/她可能不必在所有浏览器上进行测试以确信该错误,例如该错误可能是因为IE不支持特定类型的呈现。

能够预测要测试的关键模块。随着时间的流逝,在技术水平上对产品的深入了解可能会帮助测试人员正确预测对断裂更敏感的模块,并在其他模块之前对其进行测试

创建和维护自动化。

总体声誉-由于知识渊博而赢得尊重总是有帮助的!

#9 楼

如果您想进行深潜/单元级测试,API测试或自动化,则它会有所帮助。对代码的理解也使调试变得更容易,您知道去哪里以及使用什么工具来查找精确的细节,从而形成良好的错误报告并确定修复目标。它还可以打开其他角色,进行和维护构建,发布流程和工具以及自动化或测试工具的工具锻造。我发现在小型公司中,他们具有广泛的技能和能力,可以使您成为受人尊敬的员工,并在您可以帮助开发人员完成任务以便使他们可以专注于编码时给您一些“信念”。
当我开始测试时,我不知道如何编码,自学并通过提问来学习,现在它使学习新产品变得更加容易,因为我可以更好地遵循代码并了解大多数时间在做什么。

#10 楼

我更喜欢测试人员能够理解代码,并且能够编写一切代码以实现良好的自动化。
话虽如此,我对测试人员实际阅读开发人员代码抱有矛盾。在理想的世界中,开发人员和测试人员应按规范操作,以免影响思维过程。示例:开发人员在代码中加入hack x,并带有注释,说明这是黑客。测试人员碰巧看到了这一点,并围绕这种hack编写了他的测试-从长远来看,这通常会造成麻烦。删除hack后,由于与开发代码的不必要耦合而导致测试失败/如果hack保留时间过长,则某些功能可能未经测试。.
我们拥有测试人员的主要原因之一是他们引入了测试人员桌上有不同的想法。严格地使测试人员参与每个代码审查等工作,使测试人员成为一半开发人员,无济于事。在实践中,很难通过清晰的描述来实现,因此最好找到适合您的中间立场。

评论


虽然我同意污染点,但我认为对于测试人员来说,至少知道他/他正在测试的代码中的某些逻辑对我们很有帮助,以便能够构建边界案例等。此外,虽然测试人员无需读取实际代码即可执行此操作,但了解一些您不初始化变量时会发生的情况,而当您基于1遍历数组上的n-1条记录时会发生什么基于0等的,有助于再次了解要运行的测试类型以及如何将结果传达给开发人员。

– Tristaan​​Ogre
2011年5月17日下午16:48

此外,正如@Ethel在下面指出的那样,能够帮助进行静态白盒测试(代码审查)的功能非常有助于让其他人眼前一亮

– Tristaan​​Ogre
2011年5月17日在18:09

理想情况下,所有这些信息都应该从接口到达,而不是通过查看实现。而另一只眼睛是团队中的其他开发人员:)。实际上,其他开发人员也将更好地了解与其他相关组件内部工作的交互-因此这将有助于他们给出更好的评论。

– Subu Sankara Subramanian
2011年5月17日在22:48

该接口不一定指示什么是代码路径。我目前有一个项目正在研究这种情况。有一个相当复杂的决策树来确定谁会收到某些事件的电子邮件通知。但是,该界面只是一个数据输入屏幕。现在,有了详细的规范,但是在决策中有一些复杂性,因为规范非常冗长,但是可以通过查看代码轻松地进行总结。

– Tristaan​​Ogre
2011年5月19日下午14:10

接口不必只是HCI。测试人员通常在所有接口级别(类之间的接口等)编写代码。这就是白盒测试的体现。在您的情况下,这应该可以解决问题-只要SRP和接口清晰即可。

– Subu Sankara Subramanian
2011年5月23日在8:45

#11 楼

考虑在最终用户是程序员或系统管理员的情况下测试软件。例如:


用于配置和构建应用程序的应用程序服务器。
用于管理和监视分布式系统基础结构的工具。

在这两种情况下,编程,脚本编写和平台管理技能都可以在自动化测试之外发挥作用。

首先,我对于要求苛刻的应用程序,特别是具有数据库和AJAX的Web应用程序的高级Python程序员,已经看到了beta测试邀请。测试不仅需要测试单个API,而且还需要在该API上构建示例应用程序,这些应用程序可能会对服务器的某些方面产生压力。

关于第二点,我已经看到了熟练的人员进行alpha测试的工作机会Unix / Linux环境以及其他软件平台(例如AIX和Solaris)。在收集数据,从而与平台软件集成时,可能会出现许多问题。

#12 楼

无疑,具有开发人员背景或编码知识的测试人员对软件测试有很大帮助,但这是很久以前的事情了。我认为随着新一代测试工具的发展,测试人员本身已经变得非常聪明,因此不再认为测试人员不再需要具有编码经验。这是有帮助的,因为我认为,如果有任何测试人员只专注于他自己的测试工作,将更有效,因为他们不需要花时间在乏味的编码工作上。

#13 楼

测试是一项成熟的活动,同时进行。它们就像一条铁路线,朝着相同的方向但不相交。可能会有精通编码的QA专业人员和同样具有QA本能的开发人员。

如果我在你的位置,我会把开发和编码经验视为一个加分点,但是没有强制性要求,除非您缺少编码器。