程序员应该自给自足吗?


28

在我目前的工作场所中,我们没有任何测试人员,管理层的理由是:“如果我们有测试人员,则根本不会测试自己的代码”。这种想法似乎对产品质量有害,因为当我测试自己的代码时,由于我了解系统内在而又不知道如何使用,我会错过很多事情这是“错误的”。黑盒测试并不能真正起作用,因为我下意识地避免了专用测试人员会陷入的陷阱。我花了很多时间来修复那些已渗入生产代码并由最终用户发现的错误。

有问题的系统很大,但完全由我开发。这也导致一些管理职责落在我的腿上,例如定义时间表和制定规格。

这些任务应该由我负责吗?我严格地把自己看作一个程序员,没有别的。如果这些是我的责任,在多大程度上?什么时候一个项目如此之大而需要测试人员?程序员是否应该完善规范,担心项目管理甚至提供客户支持?

注意

有些人可能会觉得我不赞成扩大职责–情况并非如此,我渴望获得一个涉及更多管理职责的职位,但目前不在我的职位描述中。在我正式受雇之前,或者在我的薪水中开始显示其他职责之前,我将一直认为自己“只是”一名程序员。不幸的是,作为一名初级开发人员,转为管理职务不会很快发生。

到目前为止,出色的答案,如果您有其他要添加的内容或需要分享的个人经验,请随时提出来!


4
啊,好老的“测试者用户”场景。我很清楚
马特·艾伦

抱歉,我不得不告诉您,但是..您的管理中白痴:(
Hannibal Lecter博士2010年

1
您在哪家公司工作?如果他们确实聘用了测试人员,是否有足够的工作让他们全职工作?如果他们确实雇用了项目经理,是否会有足够的工作让他们全职忙?我不得不管理像我这样的事情的工作是那些规模还不足以证明另一位员工担任这些职位的公司。
Carson63000

@ Carson6300,目前我们有7位程序员,他们都很精疲力竭,并且图形设计师的数量也相同。我们也有项目经理,至少在这个词的一些感觉。正如我所说,“ .. 引起了一些管理职责。” 大多数管理仍由项目经理完成。我认为我们足够大,足以证明专用测试人员的合理性。
塔图·乌尔曼嫩

也许您需要向管理层显示以下文章:通过软件错误进行操作条件调节
Vaibhav Garg,

Answers:


19

确实有测试员。只有您称他们为“最终用户”。由于您描述的所有原因,这是有害的;无论您是多么认真的编码人员,您都将永远做不到足够好的工作来克服自己对代码“被假定”如何被用于查找所有可能弄糟的方式的先入之见。 。

您需要重新与管理部门联系。至此,听起来好像您有一些可靠的数据来支持您的案件。当前的质量保证放手方法既浪费时间,损害用户体验。您在呈现此内容时需要谨慎,这样很明显这是一个结构性问题,而不是 “您只是在测试中吸气”的情况,但这听起来像是需要进行讨论的讨论。

听起来您正在和这位雇主走到十字路口。如果您打算保留一名程序员,而别无所求,则可能需要开始回避并要求他们开始为您提供帮助,从而使您摆脱某些管理任务,或者通过引进新的人员或扩展现有同事的职责。(“这不是您雇用我的目的,并且这些任务也不会消失。我花在做这些事情上的时间很糟糕,是我没有在我擅长的东西上花费时间。”)但是,可能不现实。您是否认为如果他们为您提供完成工作所需的资源和权限,您就可以担任更高的管理职位吗?

至于在需要测试人员之前项目需要多大的规模,我不确定如何精确地定义这条线,但是我绝对认为您已经跨过了。您花费的时间超过了修复来自实际用户的错误报告的时间。对我来说,是时候该花更多的精力来阻止bug的出现。


坦率地说,我在很多地方工作,老板认为开发人员必须测试软件,而不是一个很好的工作场所,如果公司没有测试人员,他们只是不了解软件开发的基础知识或廉价的混蛋,无论哪种方式,您都应该找到另一份工作
jonathan

13

是。如果必须,您应该能够测试您的代码。(我不是在谈论单元测试,而是在进行验收测试。)

没有。测试人员比您更擅长测试。正如您所指出的,就像校对一样,很难发现自己的错误。拥有更多的眼球会对程序质量产生重大(良好)影响。

您还有很多其他问题。我只会回答一个:

程序员是否应该完善规范?

是! 您必须实施该规范,因此必须确保该规范实际上是可实施的。另外,作为一名经过明确思维,精确度等训练的程序员,您可以帮助人们发现实际需要做的事情,并消除模棱两可或逻辑上有缺陷的要求。


5

他们所说的与现实可能是两件事。最有可能的理由是:
“为什么我只能让程序员承担双重职责,为什么我必须支付测试人员的薪水?”

当然,他们不会这么说,并且会弥补他们认为合理的各种借口。我可以想到一些反对意见,但老实说,他们不会有所帮助。我已经看到这场战斗一遍又一遍,每当你揭穿他们当前的论点时,他们都会改变他们的做法。最终,他们会放弃,并只是直接指示您这样做,因此您将被标记为投诉人。

我能想到的最佳方法不是从质量的角度来解决问题,管理直到出现问题时才看重它,而从成本的角度来看。与程序员相比,测试人员便宜,或者至少被认为便宜。提醒他们,让您承担双重职责,他们将支付较高的薪水资源(程序员)来完成可以通过更便宜的资源(测试人员)完成的工作。因此,他们没有使从编程技能中提取的价值最大化。

如果您得到薪水,这种方法的确会崩溃,而且他们不会让您加班加点费,这并没有什么不妥,但值得一试。


如果您获得薪水,并且他们没有让您加班的报酬高涨的机会,那就该辞职了。
glenatron

谢天谢地,强制性无偿加班并不是到处都有的。
史蒂文·埃弗斯

3

有问题的系统很大,但完全由我开发。这也导致一些管理职责落在我的腿上,例如定义时间表和制定规格。

很公平。

这些任务应该由我负责吗?

最终由您的管理层决定。

我严格地把自己看作一个程序员,没有别的。

也许您当时做错了工作。许多人喜欢被赋予额外的责任。

如果这些是我的责任,在多大程度上?

如果管理层这么说,是的。

什么时候一个项目如此之大而需要测试人员?

当开发人员要做的其他工作太多时。那时,管理层需要决定是否要聘用专门的测试人员,还是冒着跳过测试的风险。(最终,开发人员只能做很多事情。)

拥有专门的测试人员固然有一定优势,但是除了雇用额外员工的成本外,还有缺点。

如果程序员必须完善规范,

如有必要,可以。实际上,如果规范需要完善,并且没有其他人在努力,那么不这样做可能会导致项目失败。

担心项目管理

如有必要,可以。

甚至提供客户支持?

如有必要,可以。

在我看来,您劳累过度,并对压力做出反应。这是个问题。但是,采取“做X,Y,Z不是您的工作”的立场是无济于事的。更好的计划是明确说明您只能做很多事情,并指出这很可能导致错过最后期限,质量下降,客户支持差等。但是无论如何都要尽力而为...在此过程中不会损害您的健康,人际关系等。


这不仅与管理有关,还包括他的管​​理和适当的薪酬。如果OP不满意他的职责和报酬,那么尝试找到一个基线以发现其期望更接近现实是完全合理的。
jmoreno

3

我们有测试人员。没有他们,我不想工作。尽管我确实为所有代码编写了单元测试(使用TDD)和自动集成测试,但是测试人员仍然具有非常有价值的功能。

  1. 他们技术精湛,与程序员具有不同的技能。
    1. 他们在如何进行QA测试以及如何验证所生成的代码是否确实符合用户的期望和用户的实际行为方面具有丰富的经验和知识。
    2. 他们经历了许多错误,并且非常善于考虑可能破坏软件的情况。
    3. 他们倾向于玩世不恭和系统。我观察到程序员通常更乐观。
  2. 他们提供了关于可用性的有价值的早期反馈。例如,最近创建REST API时,质量检查测试人员不容易理解的区域很好地表明了用户也会感到不满意的区域。
  3. 他们在实际环境中进行测试,实际上是实际硬件,操作系统等的许多配置。
  4. 他们知道如何建立大规模的,现实的测试台以及如何进行性能,负载和压力测试
  5. 他们专注于防止不良发布。程序员倾向于专注于发布代码。几乎就像,程序员将默认释放代码,但是QA测试人员将需要一个理由来释放它(事实证明它可以工作!)

0

“如果我们有测试人员,您将根本不会测试自己的代码”

如果您的汽车有安全带,您会一直撞坏!

这些任务应该由我负责吗?[...]如果这些是我的责任,到什么程度?

答案是“取决于”。据我了解,您的雇主将您视为“一个人的IT部门”。如果是这样,是的,这是您的责任。如果您有自己绝对讨厌并希望避免的责任,请在拥有更大IT部门的公司中寻找职位。

什么时候一个项目如此之大而需要测试人员?

那不是(很)正确的问题。您最好问“什么时候公司的产品/图像质量如此重要,以至于需要测试人员?”

程序员是否必须完善规范,[...]

当然是。在大多数情况下,开发人员/实施人员需要什么和客户提供什么(作为规范)之间存在很大差异。

在很多情况下,您需要找到灰色/未指定的区域并提出正确的问题,注意到并指出技术上不可能或矛盾的要求等(特别是如果您是唯一的开发人员)。

[...]担心项目管理甚至提供客户支持?

这取决于您担任职位时承担的责任。例如,某些职位要求您直接与客户打交道。在其他所有条件都相同的情况下,我会尽量避免担任此类职位(但这取决于您,您可能没有太多的工作选择)。


0

首先,测试,或者更好的说是质量保证,不仅涉及通过单击应用程序来测试功能。质量保证与过程有关。不仅要测试应用程序以查找错误,而且还必须阻止开发人员执行错误。

  1. 产品规格+用例
    即使每个人都知道(或认为他们知道)产品功能是什么,也必须写下来。没有明确的规范,您无法测试应用程序。规范定义了什么是正确的行为以及什么是错误。
  2. 单元测试,集成测试
    难以通过UI测试的内部测试,特殊的应用程序状态。这对于每个更大的系统都是必须的。两种类型的测试还具有另一个有趣的特性-它们迫使您再次遍历代码的每个部分,并且您将意识到以前从未见过的错误/体系结构问题。
  3. 代码质量和编码标准
    QA要做的任务之一是测量代码复杂度。低复杂度的代码减少了出错的可能性(防止错误)。
  4. 代码审查
    当项目达到给定的大小或被许多用户使用时,必须进行代码审查。另一个程序员总是会发现您错过的代码问题/错误。程序员有时对自己代码中的明显错误视而不见。
  5. 文档
    记录您的代码及其体系结构,这将帮助您实现可能的缺陷(根据我的经验)。
  6. 测试人员测试人员
    不是只单击UI的猴子。测试人员获取规范和用例,并创建测试用例。然后他/她一个接一个地测试它们。如果最终用户报告了一个错误,则必须为此添加一个测试用例。

程序员切勿创建规范(1)。您不在那里决定功能。通常,他们必须与最终用户交谈,创建图形设计等。这是一项耗时的任务。如果程序员决定了功能,通常会以“这很不错,但是明天可以在此窗口中更改所有内容吗?”结束。“这不是我想要的”,“它有效,但是很难使用”,“它缺少我们真正需要的唯一功能”。

程序员可以实现的是2、3和5。

您需要4个其他的程序员。任何拥有大型IT项目的公司,只有一个知道系统在非常危险的基础上发展的开发人员。

如果您没有足够的时间,请不要费心创建测试用例(5)。通常需要专职人员,因为这会花费很多时间。没有测试用例,测试只是一个玩笑。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.