我是有动力为我们的团队带来一些质量保证的人。问题在于,我们的开发人员经常讨厌测试,即使他们拥有测试协议,也并非所有人都真正在测试。他们经常问他们的同事,而不是测试自己的错误所在和类似的做法。他们通常对完成工作并不感兴趣。

这当然是一个普遍的问题,他们可能会因为这种态度而被解雇。但是实际上,事情并不像这样简单。

我现在的问题是,是否有聪明的战术可以防止他们作弊。我会让每个测试人员发生一些随机错误以防止这种情况发生,但是由于它们是开发人员,因此几乎不可能阻止在源代码中搜索这些错误。另一个想法是为发现最多错误的人提供奖励。或不要让​​多个人测试相同的事物(但这会降低测试的质量)。

您有什么聪明的建议来“迫使”开发人员进行真正的测试,使他们无法进行测试作弊?当然也欢迎使用有趣的策略...

在我的情况下,应用程序是用PHP编写的,开发人员也是测试人员(同一个人)。

评论

您是否只是尝试让他们对结果代码负责,而不是尝试强制“更多”测试?

他们过去不得不签署测试协议,但是公司需要他们付出很多努力来实施严厉的惩罚。除此之外,我正在寻找积极的条件,而不是由于存在欠款而产生更大的压力。

开发人员经过培训和培养,可以学习系统规则以及在需要时如何规避它们。这就是他们的报酬。您应该重新考虑为什么要他们这样做,以及为什么他们如此讨厌。

#1 楼

正如user246所说,强迫开发人员进行测试的技巧总是可以解决的:您最好找出他们为什么不喜欢测试,以及实际的问题是如何从中建立测试和质量文化。

您正在使用PHP-开发人员可以使用针对PHP的单元测试框架。如果他们不知道测试可以节省多少麻烦,那就可以在这里进行宣传。我建议初学者使用一些单元测试来完成一个较小的项目,然后对其进行重构-用它来演示精心设计的单元测试如何可以帮助节省工作:如果您知道会发现任何破坏现有技术的变化在您进行编译的同时,您还知道可以安全地重构和扩展系统。

其他一些可以帮助您的事情:


当他们抓紧一些不起作用的东西,或者谈论他们玩的游戏时(至少某些特定的游戏玩家几乎都有在团队中),看看您是否能感觉到他们对所使用软件中的错误的响应方式。
Google“也许他们应该测试更多”。我向您保证,您的
开发人员不想在该博客上找到他们的应用程序!
保持机敏。如果您对此感到厌烦,则会遭到抵抗和破坏。那只是人的本性-人们不喜欢有人在将他们铁路运输到他们不想去的地方。
确保您正在创建单元测试并测试您的工作。如果您要建模,而您希望团队的其他成员去做,那总是一个好的开始。由此,您可以删除偶尔的种子注释,例如随便提一下最后的增强功能是多么容易,因为一旦您破坏了某个内容,您就可以通过所有这些测试告诉您(不要做得过多-提一下它,然后离开一段时间:让他们来找你)。

通常,如果您的团队想要建立高质量的文化并认为这是他们的想法,那么您将有更好的机会建立高质量的文化。同时,请不要太沮丧:您的团队很可能将“测试”视为任何训练有素的猴子都可以做的事情,而这却背离了其主要目的。

评论


谷歌“也许他们应该测试更多”。或者也尝试“也许他们应该测试更多”。

–乔·斯特拉泽(Joe Strazzere)
2013年9月26日16:18

@JoeStrazzere-我忘了“也许他们应该测试更多”的一个。当您搜寻这些词组时,会发生一些SCARY问题

–凯特·保罗(Kate Paulk)
2013年9月26日在18:32

大声笑我不得不笑。感谢您的好建议。令人恐惧的是自己开发的私有框架,并且应用程序非常庞大。他们从统一测试开始,但随后时间用光了,他们专注于开发本身。我现在的目标是提高整体质量。因此,我与所有开发人员讨论了他们想要更改的内容,并告诉他们我愿意接受每一个建设性的投入。接下来,我个人开始使用Selenium进行功能测试。但是在我想要确保质量的地方也需要进行手动测试。

–安迪
2013年9月26日在20:28

@Andy-通常就是这样。一旦出现时间紧缩,单元测试和任何其他类型的测试就会被丢弃。这样做的问题是,如果您没有花时间去正确地做它,那么您最终将花时间去做是否拥有它。

–凯特·保罗(Kate Paulk)
13年10月1日在11:27

@KatePaulk就是我多年来推动单元测试的原因,但是当管理层看不到中长期节省时间时,这很困难。

–安迪
2013年10月1日14:47

#2 楼

祝你好运。您的开发人员可能足够聪明,可以破坏您采取的任何头或动机。相反,您需要直面问题:测试需要成为组织文化的一部分。这并不是说每个开发人员都需要热爱测试,或者需要测试而不是开发。相反,开发人员需要知道并相信,发现和消除错误与他们工作的每个其他方面一样重要。如果他们不认为发现错误很重要,那么他们的产品将会失败,其职业生涯也会失败。就是这么简单。

如果您同意这一点,那么问题就变成了“我如何促进测试文化?”您需要向开发人员展示测试过程如何影响他们的成功。向他们展示错误积压的情况。给他们一些例子,说明您的产品因质量而面临失败的风险。评估花费了多少时间进行测试,然后讨论如果让每个人都参与其中可以更快地完成测试,那么您的团队可以做多少工作。

您可能还会问他们为什么不参加有兴趣在测试中做好工作-不是以指责的方式,而是以好奇,开放的方式。他们可能喜欢(或至少容忍)某些测试,而不喜欢其他测试。否则他们可能不喜欢测试,因为他们实际上并不知道如何测试。除非你问,否则你不会知道。

评论


感谢您的建议。你是完全正确的。他们身后有艰苦的工作,我想尽我的一份力量。我已经与所有这些对象进行了交谈,并亲自开始使用Selenium进行自动化测试。我希望我可以改变他们的态度,并为他们提供可行的策略。这就是为什么我在寻找创新的方法来确保质量和激励的原因,也因为没有简单的方法可以欺骗这样的东西。

–安迪
2013年9月26日20:34在

#3 楼

不要要求他们测试。向他们询问您需要的信息。帮助他们了解您需要什么信息,以及什么对您有价值。


告诉他们您和其他人需要做出哪些决策,这些决策将从有关系统的良好信息中受益。 />告诉他们什么样的信息可以帮助您和其他人做出更好的决策。

询问该信息。为证。寻求帮助。
注意信息的质量-您是否在获取信息,是否了解信息以及它是否在帮助您和其他人做出更好的决策。

在了解有关他们的能力和信息需求的变化时,调整您的要求。

测试不是您想要的。测试就是他们如何产生您想要的东西。您真正想要的是信息。所以要那个。

评论


戴尔(Dale),您的立场是,只要其他开发人员能够为安迪提供足够/正确的信息,它们的其他开发人员就不需要测试-也不应该被要求测试?

–user246
2013年9月28日19:18在

好吧,他们可能不需要测试,具体取决于他所需的信息。但是,如果他需要仅来自测试的信息,则他们必须进行测试才能创建信息。但是我的意思是:不要问他们的工作。要求他们提供有价值的结果。告诉您是否得到它更容易。而且他们会更好地了解您所要求的价值,这可能比操纵杆和游戏指标更具动力。

–戴尔·埃默里(Dale Emery)
13年9月28日在22:57

那正是我的方式。我试图抓住他们的需求,为他们提供最舒适的测试环境,并与所有人交谈以确保他们知道自己的工作有多么重要。接下来,我将提供自己的部分,以便他们可以记住,我也必须进行此类工作,并且我们正在一起改进整个过程。

–安迪
2013年9月29日上午8:56

#4 楼


并非所有人都在真正地进行测试


你怎么知道的?只是因为他们在问其他程序员问题在哪里?尽管这不是一个整体策略,但它并不是发现众所周知的问题的好方法。


他们常常对完成一项工作不太感兴趣。


您怎么知道的?也许您还没有传达“好的工作”测试的意思?您和您的开发人员完全有可能对测试的含义视而不见。也许他们认为自己的方法很好?组织对测试手段是否有共识?什么质量意味着什么?您认为错误/问题等是什么?

在没有熟练,专门的资源的情况下,试图在从未有过的组织中应用一些新的正式测试需要一些策略和影响力。您的开发人员很可能不知道什么是测试,并且认为单元测试已达到他们所需要的范围。

我的建议:
考虑一下您想在测试策略方面看到的内容,然后弄清楚开发人员在当前的知识和技能基础上可以合理地进行哪些工作。然后继续扩展当前的知识和技能,直到它们逐渐适合您的测试策略为止。


另一个想法是为发现最多错误的人提供奖励。


这样的方法可能会导致游戏系统中会填充大量错误,但需要几天才能隔离和报告的最重要,关键的错误将留在系统中。您基本上是在要求低垂的果实-真的很浅的测试。


或不要让多个人测试相同的事物(但这会降低测试质量)。


如何知道他们的测试质量有什么好吗?您是否与他们一起检查他们的测试和测试策略?如果没有,这可能也会有所帮助。

评论


请不要误会我的意思。我不是他们的老板,也没有信任问题或类似问题。例如,一些开发人员自己告诉我,他们没有填写完整的测试表格,仅向办公室中的其他人询问有关错误的信息,以跳过测试任务。我要搜索的不是惩罚,而是在寻找创造性的方法来获得更多动力,并确保测试任务真正完成。我只是这个人,他将尽力充分利用自己的时间,并确保我们从中受益的更好的质量管理。他们是优秀的开发人员,但讨厌进行手动测试。

–安迪
2013年9月26日20:19



开发人员通常不愿进行手动测试-强迫他们进行测试通常是浪费优秀的开发人员。不幸的是,如果您没有专门的测试专家,那就是您所要坚持的。

–凯特·保罗(Kate Paulk)
13年10月1日在11:22

#5 楼

测试是一个激励性的问题。对于大多数程序员而言,它可能成为难以承受的线程。我听说,无关紧要的积极奖励(如发现错误时免费赠送饮料)会有所帮助。与其说是游戏模式,不如说是奖励。

一般来说,寻找减少测试的手段。否则,好的开发人员将离开,诸如此类。切换到TDD(测试驱动开发)可以是一个增量解决方案。尽管它需要组织的代码和数据,但这增加了软件质量。人们编写小型单元测试,稍后在代码更改时用作回归测试。

通常情况下,数据模型由侦听器提供更改,操作等操作。模拟特定的部分,例如选择HTML选择框。

优点是快速生成结果并减少了绒毛。

评论


我为TDD投了很长时间,他们开始了。由于截止日期非常短,他们停止了它。但是我尝试回到TDD路径上。但是目前,我主要是在寻找最好的方法,直到我们回到这条路。

–安迪
2013年9月29日上午8:59

#6 楼

雇用一些专业的测试人员
请他们确保测试证据(屏幕截图,日志,错误ID等)的安全,并告知他们将定期对其进行审核。

标记。
/>