测试人员在敏捷中的角色?

时间:2009-10-29 00:03:01

标签: testing project-management agile scrum

我在一个一直在做传统瀑布式开发方法的团队工作多年。最近,我们被告知未来的项目将朝着敏捷(特别是Scrum)方法发展。事实上,我的项目将成为第一个项目之一,因此我们将在接下来的几个月内成为几内亚猪,以确定实现过渡所需的条件。

项目本身处于非常早期阶段,我们通常需要几个月才能向测试团队发布任何内容,但现在我们将直接与他们合作。因此,我担心测试人员在这个阶段在这样一个项目中的作用。我有几个问题/疑虑,希望一些有经验的敏捷开发人员可以回答:

  1. 当开发人员编写任务时,测试人员无法对其进行测试(它还不存在)。那时测试者的角色是什么
  2. 现在测试人员参与了单元测试吗?这是否与黑盒测试并行完成?
  3. 在主要进行基础设施变更的sprint期间,测试人员做了什么,这可能只能在单元测试中测试?
  4. 传统测试团队成员如何在敏捷项目中发挥作用?

9 个答案:

答案 0 :(得分:26)

随着项目的成熟,保持测试人员的忙碌变得更容易(还有更多要测试!),但以下几点也适用于早期阶段:

  1. 测试人员可以在实施之前(或同时)为用户故事准备测试计划,测试用例和自动化测试。这有助于团队在开发人员编写任何代码之前发现用户故事中的任何不一致或含糊不清。

  2. 根据我的个人经验,测试人员没有参与单元测试;他们只测试通过所有自动化单元,集成和验收测试的代码,这些代码都是由开发人员编写的。但是,这种分裂可能在其他地方不同;例如,您的测试人员可能正在编写自动验收测试。然而,单元测试确实应该由开发人员编写,因为它们与代码一起编写。

  3. 他们的工作量会因短跑而异,但仍需要对这些变化进行回归测试......

  4. 您可能还会发现让测试人员在每个sprint的前几天花费测试上一个sprint中的任务可能会有所帮助,但是我认为最好让他们确定开发人员要做的事情。通过编写他们的测试计划来工作。

答案 1 :(得分:12)

理想情况下,质量保证和测试人员应该参与软件开发项目的第一天和非常早期阶段,无论使用何种流程(瀑布或敏捷)。测试团队需要:

  • 确保项目或冲刺要求清晰,可测量且可测试。在理想的世界中,每个要求都将在此阶段写下适合的标准。确定需要自动记录哪些信息以排除任何缺陷。

  • 准备项目特定的测试策略并确定需要哪些QA步骤以及在哪些项目阶段:集成,压力,兼容性,渗透,一致性,可用性,性能,beta测试等。确定可接受的缺陷阈值并制定缺陷严重程度分类系统,指定缺陷报告指南。

  • 指定,安排和准备测试环境:根据需要测试基础架构和模拟服务;获取,消毒和准备测试数据;编写脚本以在必要时快速刷新测试环境;建立缺陷跟踪,沟通和解决方案;准备招聘或招募用户进行测试,可用性或验收测试。

  • 提供所有相关信息,以形成项目进度表,工作分解结构和资源计划。

  • 编写测试脚本。

  • 让自己快速了解问题域,系统AS-IS和建议的解决方案。

通常,这不是测试团队是否可以在早期阶段向项目提供任何有用的输入,也不是这样的输入是否有益的问题。然而,问题是组织能够在多大程度上承担上述活动。可用时间,预算和资源与最终结果的已知质量水平之间总是存在权衡。

答案 2 :(得分:8)

好帖子。大约3年前,我处于相同的状态,从瀑布到敏捷的过渡是棘手的。我在移动过程中遇到了很多痛点,但是一旦我克服了它们并且我的角色发生了变化,我意识到这种工作方式非常适合测试。

不需要测试人员的常见错误很容易消除。

<强> 1。当开发人员编写任务时,测试人员无法对其进行测试(它还不存在)。那时测试者的角色是什么

根据我的经验,测试人员可以与客户合作,对sprint中的故事进行微调。

他们通常与开发人员合作,对他们提供的代码进行微调。即就边缘案件,流量,错误等提出建议。

他们经常参与设计编码器为执行TDD而编写的测试。

如果敏捷团队相当先进,那么测试人员通常会编写ATDD(验收测试驱动开发)测试。这些可以在Fitnesse或Robot Framework等工具中使用,也可以是更高级的ruby测试甚至是其他编程语言。或者在某些情况下,简单的记录和回放通常对少数测试有益。

他们显然会编写测试并计划一些探索性测试场景或想法。

有时为团队理解的棘手问题是故事不必完整,以便将其放到测试堆栈进行测试。例如,编码人员可以放下一个屏幕,其上有一半的字段。测试者可以测试这一半,而另一半正在编码,因此反馈早期测试结果。测试不一定要在“完成”的故事中进行。

<强> 2。测试人员现在参与单元测试了吗?这是否与黑匣子测试平行?

理想情况下,编码员会做TDD。编写测试然后编写代码以使测试通过。如果编码人员想要非常好的TDD那么他们就会和测试人员一起考虑测试。

如果没有完成TDD,那么编码人员应该在编码的同时编写单元测试。在软件被删除后,它可能不应该是经过思考或任务之后。测试的全部要点是测试软件是否正确,以避免以后浪费时间。这都是关于即时反馈的。

第3。在主要进行基础设施变更的sprint期间,测试人员做了什么,这可能只能在单元测试中测试?

理想情况下,测试人员将与团队和客户(顺便说一下,他们是团队的一员)合作来定义计划的故事并构建一些好的,详细的接受标准。这是非常宝贵的,可以节省大量的时间。测试人员还可以学习新的自动化技术,规划测试环境,帮助记录规划的结果。

理想情况下,冲刺中的每个故事都可以通过某种方式,形状或形式进行测试。这并不意味着它应该由测试团队完成,而应该是可测试的。因此,测试人员可以与团队的其他成员一起研究如何确保故事是可测试的。

我在这里发布了一些敏捷提示:http://thesocialtester.posterous.com/

希望这会帮助你 罗布..

答案 3 :(得分:3)

只是一些想法,绝对不完整:

  1. 当开发人员编写任务时,测试人员可以检查规范(或客户的请求,如果没有正式规范)并编写测试计划。这可以包括需要测试的概念框架,但它也应该包括正式编写测试套件(是的,在代码中)。对于转向敏捷的团队而言,这可能是一个相当大的挑战,因为很多测试人员都是在没有编程技能的情况下受雇的。 (在很多地方,似乎要求无法编码。)

  2. 测试人员可以通过测试具有干净界面的组件或库来参与单元测试,或者稍微更高的范围。

  3. 测试人员总是正在执行回归测试,负载测试以及他能想到的任何其他类型的测试,以及为下一个sprint编写测试套件。通常情况下,测试人员在开发之前(准备测试环境)以及开发之后的一个sprint(测试开发人员刚刚制作的内容)工作一个sprint。

答案 4 :(得分:3)

我最近看到了一个很好的talk。基本上这个团队开始做一个相当标准的Scrum流程,然后过渡到看板和精益。他们所做的最重要的事情之一就是逐渐侵蚀测试人员和开发人员之间的区别。测试人员参与编写单元测试和代码,开发人员在开发早期就引入了更高级别的测试。对于测试人员而言,这是一个陡峭的学习曲线,但值得一提的是团队从一开始就在建设质量。到目前为止,测试人员称自己为开发人员,因为他们的工作在编写代码的过程中非常集成。

答案 5 :(得分:2)

在我的公司,我们使用并认可敏捷。我们的QA团队成员参与单元测试创​​建,维护回归测试基础架构,就像在瀑布中一样,他们也会在完成后测试每个功能。

在进行基础设施变更时,他们也参与确保新基础设施可以测试。

所以,从我有限的经验来看,我会尽力回答你的观点:

  1. 如果还没有什么可以测试,请开始设置回归/测试基础设施并确保所做的一切都是可测试的
  2. 是的,他可以同时做两件事
  3. 维护测试基础架构并狩猎任何破坏测试的人

答案 6 :(得分:2)

  

1)当开发人员编写任务时,测试人员无法进行测试   它(它还不存在)。然后怎样呢   在这一点上是测试者的角色

测试人员仍然可以创建测试计划并列出将要创建的测试。如果开发涉及一些现成的软件,例如,可能还需要测试人员接受培训。如果您正在使用Sitecore进行CMS项目,那么测试人员应该了解一些关于Sitecore的信息。测试人员,开发人员和最终用户或BA之间也可以进行一些合作,以了解哪些要求和期望,以便不会出现模糊要求中出现的指责。

  

2)测试人员现在是否参与了单元测试?这是完全平行的   黑盒测试?

不在我们的案例中。测试人员正在进行更多集成/用户验收测试而不是低级单元测试。在我们的例子中,单元测试在任何QA测试之前进行,因为创建功能的开发人员将创建一层测试。

  

3)测试人员在主要基础设施的冲刺期间做了什么   已经做出了改变,这可能只是   在单元测试中是否可以测试?

回归测试!在进行基础设施变更时,有什么破坏吗?与QA相比,开发人员运行的测试套件有多彻底?我们在很短的时间内进行了冲刺,其中大部分冲刺工作都是管道返工,所以除了看到之前工作的东西还能继续工作之外没什么可测试的。

在我们的案例中,我们将测试作为我们开发环境的一个级别,但仍然是一个预生产环境。我们的想法是允许QA sprint来验证已完成的工作以及在发布到最终用户验收测试的阶段之前找到并修复的任何关键或高严重性错误,因此如果开发人员正在开发sprint X,那么QA正在验证sprint X-1和生产可能有sprint X-2或更早的运行,具体取决于最终的UAT和部署计划,因为并不是每个sprint都会在QA给OK进入分段后生产它。一旦开发人员完成任务的初始编码,就可以进行配对练习,以确保测试人员和最终用户签署构建的内容。这是我们尝试将质量控制整合到项目中的第三个或第四个版本,因此它仍然是一个已经发展了几次的工作。

答案 7 :(得分:2)

在敏捷环境中进行测试的最自然方法是我认为的探索性测试http://en.wikipedia.org/wiki/Exploratory_testing。 听起来不像

  

根据Cem Kaner&amp;詹姆斯巴赫,探索性测试更像是一种[心态]或“......一种思考测试的方式”而不是一种方法论

  

配对测试

敏捷的开发人员听起来很熟悉。与传统测试相比,测试人员可以更早地参与该过程。

答案 8 :(得分:1)

与其他一些受访者表示的一样,测试人员应该从第一天开始参与其中。在Sprint零中,他们应该参与确保产品负责人生成的故事是可测试的(例如,一旦编码就可验证)和“可接受的”(即当你通过UAT时)。一旦产品Backlog最初被填充,那么测试人员可以处理针对当前Sprint的Stories的测试用例,并且一旦有产品供他们测试(理想情况下在您的第一个Sprint的某个地方),那么他们就可以开始测试了。 p>

如果听起来似乎没有什么东西可以测试几个Sprint,那么你的故事就错了。 Sprint的目标,即使是早期的,也是最终系统的一小部分。专注于“asprin”(即如果建立一个药物处方系统,你如何在2-4周内提供可测试的功能?建立用于处方asprin的那些)和“tracer子弹”故事(当组合触摸全部时建筑的风险部分)。你会惊讶于你可以提前交出来测试的东西。如果测试人员最终有空余时间,请让他们与开发人员配对。它将建立关系和相互尊重。

这种方法的好处很多,但主要是你测试了很多内部人员 - 你的开发过程(从需求,开发,测试,反过来),其次是整个团队(所有提到的三个学科)看到了生成可执行软件后快速反馈的好处。

听起来不可能,但我看到它有效。只要确保你不要咬太大的东西开始。让你自己轻松一下,你会感到惊讶。