了解最新技术文章
您的敏捷团队可能会认为开发人员与开发人员协作,测试人员与测试人员协作。然而,跨专业的不同人员合作越多,产品就会越好。而且,他们也许能够更快地完成工作。
艾米是一名测试员,经常与测试团队的其他成员一起吃午餐。开发人员经常吃不同的桌子。今天,她偶然听到两位开发人员 David 和 John 之间的对话,谈论性能测试。他们似乎被困住了。
她转过身来说道:“我上周刚刚在该领域写了一些测试。想见他们吗?”
大卫低头看着他的食物。嗯,她知道大卫真的很害羞。
约翰说:“当然。把它们送给我?”
“你打赌,”艾米说。“等我吃完午饭了。” 她回到其他测试人员身边,吃完午饭。
当她回到办公室时,她向大卫和约翰发送了她上周创建的测试的链接。
大约一个小时后,她收到了大卫的消息。上面写着:“握拳!你真的帮助了我们。谢谢你!”
一个几乎不说话的家伙的感叹号?一定是个值得纪念的日子。
几周后,艾米在午餐时讨论了她的一个测试挑战。她感到有人拍了拍她的肩膀。
大卫说:“我想我知道你能做什么。” 他没有看她,但至少他在说话。
“你想让我午饭后过来我们讨论一下吗?” 艾米问道。
“当然,”他说。
午饭后,艾米去了他的办公室。他们详细讨论了她的担忧,并在白板上画了一些图表。然后他问道:“我可以编写一点代码来尝试一下这个吗?”
“当然,”她说。“只要我能够编写下一个代码。”
他们两人花了大约一个小时进行小型测试实验。他们权衡了由谁来创建测试。在那段时间结束时,艾米知道她需要做什么。而且,David 意识到他可以在哪里更改代码以使其更易于测试。
这不是传统的驾驶员和领航员配对。然而,这是一种对他们有效的配对形式。当艾米和大卫结对时,他们学到的东西比他们单独学到的要多。
适用于 QA 和开发团队的现代测试用例管理软件
即使在所谓的敏捷团队中,我也经常看到开发人员和测试人员分开工作。开发人员可能会相互结对。测试人员可能会互相配对。但当人们跨专业结对时,我经常看到更好的结果。
这些专业不一定只是开发测试人员。专业人士可能是测试人员/数据库专家或测试人员/用户界面专家。
当测试人员与数据库专家合作时,专家通常会学习如何使数据库内部更易于测试。而且,测试人员可能会学习一些技巧和窍门,使测试变得更容易、更快。
在一家公司,测试人员每次想要测试时,都会花费近一个小时从头开始重新生成特定数据库。当 DBA 看到他们在做什么时,他解释了如何在短短五分钟内重新生成他们想要的数据库。测试人员很兴奋。而且,尽管他不喜欢他们在数据库中发现问题,但他很高兴他们可以更快地测试他的更改。
在另一家公司,用户界面专家 Al 一直在设计一个屏幕,但测试员 Bob 发现无法使用。
鲍勃问道:“你知道,我一直在与这个屏幕作斗争。我让你看看我的脱节怎么样?”
艾尔同意了,并和鲍勃坐在一起。两人互相阐述了各自的观点。当阿尔意识到问题后,他更换了屏幕。
配对很棒。围攻甚至可以更好。
当团队暴动时,他们都会一起解决同一个问题。一般来说,暴民有一名打字员,即敲键盘的人。他们可能有关于主要导航员的指南,或者是否允许每个人立即与打字员交谈。(我不建议每个人同时讨论,除非团队决定讨论正在进行的工作。)
你不必是一个敏捷的团队才能发起攻击。您所需要的只是愿意共同努力解决单一问题。
艾米、大卫和约翰所在的团队自称为敏捷团队。然而,团队成员并不经常一起协作工作。由于团队成员没有协作,他们的工作在反馈循环方面花费了“太长”的时间。
该团队的成员在午餐时分开,与各自的职能小组一起吃饭。他们的午餐变成了非正式的实践社区。然而,他们并没有获得作为一个团队一起解决问题的价值。
艾米和大卫向他们的团队报告了他们的配对编码和测试实验的进展情况。大卫说:“我不太喜欢说话。但是,这确实很有效。我想尝试解决一些更困难的问题。”
团队的其他成员感到惊讶,但愿意尝试。他们霸占了一间会议室,以便拥有一个大屏幕。
他们同意由一个人(导航员)解释团队其他成员希望打字员做什么。他们甚至同意每五分钟更换一次角色。并且,他们同意,当每个人担任领航员时,将根据自己的专长进行工作。
他们选择了一个他们认为需要近一周才能实现的功能。起初,他们似乎在任何事情上都无法达成一致。就在那时,大卫说:“让我们将其视为一系列实验。我们想做的实验清单是什么?”
该团队列出了 18 个实验。现在,他们有了一个计划:对每个实验进行编码和测试。
中途,一位开发人员建议他们考虑将测试驱动开发作为驱动思维的一种方式。他们对此进行了实验。一半的团队喜欢它,一半的团队讨厌它。他们决定继续以前的工作方式。
最终,他们将问题范围从最初的 18 个备选方案中缩小到了两个。他们同意第二天继续,看看作为一个团队可以做些什么。
当他们第二天都到达时,他们花了一个上午的时间完成了这个功能。所有代码,所有测试,甚至必要的发行说明。每当他们有一个他们认为需要三天以上的功能时,他们就会决定进行围攻。
但最好的部分是人们学到的东西。在开发人员编写代码之前,开发人员就了解了测试人员所需的挂钩类型。测试人员了解开发人员如何喜欢这些数据。不是错误报告,而是如何组织测试数据。
每个人都更多地了解了产品的内部,以及如何简化开发和测试。
团队作为一个团队工作得越多——跨专业协作——就越容易完成工作。此外,每个人学到的东西都比他们预期的要多。
如果您还没有跨专业合作,特别是作为测试人员与开发人员合作,请考虑一下。并且,考虑您的团队如何聚集或以其他方式一起协作。
团队合作越多,工作就会越快、越容易。
上一篇:无预算的性能测试
下一篇:分布式跟踪在性能测试中的价值