自动化测试:帮助和教育开发人员的方法?

时间:2009-05-11 23:51:18

标签: unit-testing automated-tests

我是一名嵌入开发团队的软件测试工程师。我的大部分工作都涉及检查项目自动化测试的状态(主要是单元/集成测试)。

我不是一个想要强迫测试每个人的喉咙的短视狂热者,但我想要帮助每个人在他们花在编写测试上时充分发挥。每周花费大量时间编写测试,因此最大化回报非常重要。

现在,我做了一些尝试和帮助的事情。首先,我总是让自己谈论可测性问题。例如。尝试识别测试策略,特定设计是否可测试等等。

除了向人们解释事情并且通常试图帮助他们外,我还会检查完成的代码和他们编写的测试(我必须在故事上签字,这意味着我也有点对抗)。< / p>

我目前的流程是单独坐下来,完成他们的代码和书签&amp;评论所有问题区域,可以改进的地方以及原因。然后,我将开发人员带到我的电脑上,并通过所有评论点进行讨论。然后我给他们一个体面的写作,所以他们有一个记录,他们很容易参考。

修复他们的代码并测试它们,但如果我发现差距,我会添加更多测试用例等。我之所以决定不对它们进行测试的原因是开发人员太容易说“谢谢”而是要退出。我的理由是,如果他们必须在我签署之前解决我发现的问题,这将导致更好的项目测试标准(即更自给自足的开发人员测试)。

我的问题是:在帮助团队方面,我能做得更好吗?您发现哪些方法有益?

我特别希望听到那些担任类似职位的人面临同样的挑战(例如帮助提高测试质量,证明价值测试可以带来相关情况,并在支持和支持之间取得良好平衡。对抗性。)

*修改: 谢谢你的回答;所有这些都包含有用的建议。我认为最好的答案是最好的答案,因为我认为它归结为开发人员的支持,并且配对编程是我尚未尝试过的(缺少一些即兴的'这里是我如何做这个'示范在测试之后书面)。我会和任何努力测试的人一起去试试:)干杯。

4 个答案:

答案 0 :(得分:5)

如果你有某些人在测试中往往很弱,那么请坐下来,编程,排序,当他们处理代码时,你可以帮助他们看看他们如何测试它。

过了一段时间,这些人应该在单元测试中变得更好,并且你的工作量应该减少。

另一件事是每个人都应该看看测试。如果我触摸某个功能,进行任何更改,那么我应该检查测试以确定它们是否完整。如果有问题,我可以与开发人员讨论。

您还应该参加团队负责人的工作,因为这是他的职责之一,或应该是,以确保每个人都了解如何编写测试。

答案 1 :(得分:1)

我要做的一些事情:

  1. 让他们运行报道并发现任何遗漏的代码区域并突出显示他们认为他们已经涵盖了所有案例,但他们可能没有。我和几个人一起完成了这个,当他们认为他们写的是水密测试时,他们总是对他们错过的地方感到非常惊讶
  2. 在您当地的Wiki上启动“食谱”页面。每当有人提出他们无法弄清楚或需要您帮助的测试场景时,请将其粘贴在Wiki上并使其易于查找。让其他人也做出贡献
  3. 听起来你无论如何都已经这样做,但确保当有人有测试相关问题时,让自己可用即使这会损害你的正常工作量。如果你对它充满热情,它应该激励那些有兴趣做正确事情的人。
  4. 当我介绍某人进行测试(或新的测试技术)时,我经常会花很多时间随意徘徊到他们的工作站,只是为了看看他们是如何进行的,并将它们推向正确的方向。这可以很好地适应茶/烟休息时间或你正在建造时。我对此有很好的反馈,但YMMV。

答案 2 :(得分:1)

根据团队的规模,我想知道在对代码进行初步审核后是否有意义,将其他人拉到另一组眼睛,可以看出你提出的改变并充当方式表明这不仅仅是你对它的看法。这可以作为一种方式来突出显示哪些变化可能会让您看到开发人员可能回复的变化,“哦,这需要数周时间,而且可能不值得......”或者类似的东西,如果你想改变的东西并不那么简单。

同样,大多数团队如何看待测试?是否有领导者或受到高度尊重的领导者对此持积极态度,并帮助培养积极的态度?是否有关于测试指南的一般文档可以帮助团队中的新手快速掌握?这些只是我要研究的其他几个方面,因为有时测试可能是一件好事,有时它们可​​能会很痛苦。就像半空或半满的玻璃一样,取决于你想看到它的方式。

并不是说我有同样的立场,但作为一个曾经是开发人员的人,这正是我希望看到的,以帮助使测试成为一件好事,正如Martha Stewart所说。

答案 3 :(得分:1)

轻松让团队开始测试的一种方法是在修复错误时启动编写测试的练习。因此,当出现错误时,要做的第一件事就是编写一个因为错误而失败的测试,修复错误然后让测试通过。

当内部修改代码(没有公共API更改)时,也可以执行此方法 - 编写测试以覆盖正在修改的区域,以确保代码更改不会破坏它。以这种方式编写测试工作要少得多,并且一旦开发人员发现他们的第一个回归错误就会清楚地证明这些好处。