我不是一个想要强迫测试每个人的喉咙的短视狂热者,但我确实希望帮助每个人在他们花在编写测试上的时间里获得最大的收益.每周花大量时间编写测试,因此最大化回报非常重要.
现在,我做了一些尝试和帮助的事情.首先,我总是让自己谈论可测性问题.例如.尝试识别测试策略,特定设计是否可测试等等.
除了向人们解释事情并且通常试图帮助他们之外,我还会审查完成的代码和他们编写的测试(我必须签署故事,这意味着我也有点对抗).
我目前的过程是单独坐下来,通过他们的代码和书签&评论所有问题区域,可以改进的地方以及原因.然后,我将开发人员带到我的电脑上,并通过所有评论点进行讨论.然后我给他们一个体面的写作,所以他们有一个记录,他们很容易参考.
我不修复他们的代码和测试,但如果我发现差距,我会添加更多测试用例等.我之所以决定不对它们进行测试的原因是开发人员太容易说“谢谢”而是要退出.我的理由是,如果他们必须在我签署之前解决我发现的问题,这将导致更好的项目测试标准(即更自给自足的开发人员测试).
我的问题是：在帮助团队时,我能做得更好吗？您发现哪些方法有益？
我特别希望听到那些担任类似职位的人面临同样的挑战(例如帮助提高测试质量,证明价值测试可以带来相关情况,并在支持和对抗之间取得良好平衡.)
*编辑：
谢谢你的回答;所有这些都包含有用的建议.我认为最好的答案是最好的答案,因为我认为它归结为开发人员的支持,并且配对编程是我尚未尝试过的(缺少一些即兴的’这里是我如何做这个’示范在测试之后书面).我会和任何努力测试的人一起去试试:)干杯.
过了一段时间,这些人应该在单元测试中变得更好,而你的工作负荷应该减少.
另一件事是每个人都应该看看测试.如果我触摸某个功能,进行任何更改,那么我应该检查测试以确定它们是否完整.如果有问题,我可以与开发人员讨论.
您还应该参加团队领导的工作,因为这是他的责任的一部分,或者应该是,以确保每个人都了解如何编写测试.