对测试人员而言的TDD(二)

2014-09-25   出处: ministryoftesting  作/译者:Duncan Nisbet/大头

编写足够的代码使测试通过


程序员告诉我,当他们有一些代码和测试提交。我们过一遍代码和相关测试(主要是“unit-integration” 的测试)流程,讨论了验收标准覆盖面,然后我便抽离了对程序员软件的探索。


我尝试了几个这些边界情况下,我正在考虑和几个错误举例测试,以检查测试的有效性。也有机会向客户展示软件来检查我们是否满足了期望。


失败的测试的这种反馈循环,代码演示然后提交一般花费数小时而不是几天。


根据软件的进步,我可能会向程序员证明我的系统测试或是为自动化我的一些测试场景而寻求帮助。


诚然,我永远无法确切知道,测试是否是在代码之前完成的(真正的TDD方式),但最终我信任程序员,以及,经过上述所有的步骤后的,测试过的代码。


重构


程序员提高软件的质量。我会继续探索。


通过和程序员合作,我知道哪部分测试已经存在,各个部分如何互相影响以及是否有任何在程序员不得不同时编写代码和测试之处存在的潜在的努力点。


收集信息用来确认和建立我的测试的认可。


在重构阶段,我们也检讨可测试性和测试覆盖率,以确保它仍然是有效和高效。


例如,程序员可能会认为我们可以通过一个单元测试,而不是一个UI方案来证明达到要求。我们会探讨测试的意图,以及延迟测试的好处和坏处。会进行什么样的测试是一个群体决策,而不是一个片面决定。


关于软件的设计和运行状况的信息是双向的。没有什么是隐藏的,暴露缺陷变成了一个更为轻便的事情。


闭环


我觉得开发团队的密切合作在TDD周期像针线在衣服,其中针就像交互作用而线就像关系。密集的针线可以使得缝合得更牢固。用较少的针线则会增加布料破裂的可能性。


当谈到决定一个新特性是否“完成”的时候,开发团队和利益相关者会有来自许多来源的反馈,而不仅仅是测试人员。


于是测试者确认了程序。整个团队都知道软件的状态和行为,因此都明白它是否值得被发布到生产环境去。


这是和上图所示的TDD的周期相同的图像,但我加入了一些在整个周期中测试人员可以参与的活动类型的例子:


增加测试者的TDD周期

如果你的团队不实行TDD怎么办?


程序员可能不会主动使用TDD开发,也不会先写测试部分,然而幸运的是作为一个测试者在程序员讨论设计程序的时候你也可以参与其中。


仅仅因为一个开发团队在不使用测试驱动代码的设计并不代表他们没有考虑设计。测试会是一个不错的副产品。


如果你和你的程序员不会根据软件创建软件测试框架,使之可以“自校验”,那么事先与程序员密切合作将有助于该缺陷预防。


现在怎么办?


这里有一些提示和技巧,帮助我与程序员合作并能够更多的参与到软件的设计中去。


上下文驱动测试


不同情况决定不同的测试方法。


我离开使用瀑布/阶段式交付的组织,并加入一个使用TDD的极限开发团队。我以前的方法来测试并不再适用。


我需要检查并调整,以提供新的组织有价值的测试。上下文驱动测试团体真正帮助我成长,并理解自己是什么类型的测试者和团队合作者。


程序员行业的认识


程序员一般都自豪自己的工作。花一些时间来学习一下程序员都做些什么,他们为什么这样做,他们是如何达到他们今天的成就。


你会惊奇地发现这种兴趣很快就得到回报。


成为一个领域专家


掌握你正在测试的领域!


要知道谁是将要使用你的软件的人,他们可能有什么困难是这个软件试图解决的。越能代表我们的用户,我们的测试就能做得越好。


有一本很棒的书帮助我在我的的领域和设计相关的话题的是埃里克·埃文的“领域驱动设计”一书。贯穿全书的一个要点是利用通用语言。当业务语言被翻译成“开发者语言”时会产生很多含糊不清的地方。了解你的领域,应用批判性思维,推动通用语言可以帮助消除这种模棱两可。


证明你的价值

 

我对测试,并对与其他开发团队成员密切合作的热爱不只是一朝一夕的事。


这需要一些艰苦的工作和大量相对简单的工作,然而通过批判性思维,激情和在众多项目中的自我证明,我可以证明自己可以为以程序员为中心的环境提供怎样的价值。


如果我能做到这一点,你也可以。


你是一个软件开发团队的测试者。你有你自己对于软件设计的意见;你也许只是尚未意识到…


作者简介


邓肯尼斯比特是一个相信开发团队与大企业可以更好合作的测试者。他训练测试人员,程序员和业务人员,教导他们相互帮助,沟通以及合作,以提供可以真正解决问题的软件。他不仅关注日常开发,还重视促进团队提升。可以通过他的博客或Twitter @DuncNisbet关注他。

                                                                                                                       

编辑:阅读本文后,理查德·布拉德肖(@friendlytester)发了一个精彩而简洁的回应:

 

结论:TDD是不是测试,却为测试提供了一些伟大的艺术品。我也画了一幅画。 pic.twitter.com/knxsdjRdh0

 

理查德·布拉德肖(@FriendlyTester2014819

 

同时也画了很棒的涂鸦,我觉得为文章增加了实际价值,所以也贴在了这里:

上篇:《对测试人员而言的TDD(一)》

【英文原文:http://www.ministryoftesting.com/2014/08/tdd-testers/

{测试窝原创译文,译者:大头}



声明:本文为本站编辑转载,文章版权归原作者所有。文章内容为作者个人观点,本站只提供转载参考(依行业惯例严格标明出处和作译者),目的在于传递更多专业信息,普惠测试相关从业者,开源分享,推动行业交流和进步。 如涉及作品内容、版权和其它问题,请原作者及时与本站联系(QQ:1017718740),我们将第一时间进行处理。本站拥有对此声明的最终解释权!欢迎大家通过新浪微博(@测试窝)或微信公众号(测试窝)关注我们,与我们的编辑和其他窝友交流。
286° /2860 人阅读/0 条评论 发表评论

登录 后发表评论