帮助我了解QA在Scrum中的工作原理

Apparently we use the Scrum development methodology. Here's generally how it goes:

显然我们使用Scrum开发方法。这里通常是这样的:

Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding. QA can never complete the tasks on time, sprints are rarely releasable on time, and Dev and QA have a miserable few days at the end of the sprint.

开发人员试图完成他们的任务。通常,任务需要完成大部分sprint。质量保证代表Dev发布他们可以测试的内容,Dev在sprint结束前一两天向QA抛出一些错误的代码,并花费其余的时间修复QA发现的错误。 QA永远不能按时完成任务,冲刺很少能按时发布,而Sp和QA在冲刺结束时几天都很糟糕。

How is scrum supposed to work when releasable Dev tasks take up most of the sprint?

当可释放的Dev任务占用大部分冲刺时,scrum应该如何工作?

Thank you everyone for your part in the discussion. As it's a pretty open-ended question, it doesn't seem like there is one "answer" - there are many good suggestions below. I'll attempt to summarize some of my "take home" points and make some clarifications.

感谢大家参与讨论。由于这是一个相当开放的问题,似乎没有一个“答案” - 下面有很多好的建议。我将尝试总结一些“带回家”的观点,并做出一些澄清。

(BTW - Is this the best place to put this or should I have put it in an 'answer'?)

(顺便说一下 - 这是放置这个的最好的地方还是我应该把它放在'答案'?)

Points to ponder / act on:

要思考/行动的要点:

• Need to ensure that developer tasks are as small (granular) as possible.

需要确保开发人员任务尽可能小(粒度)。

• Sprint length should be appropriately based on average task length (e.g. sprint with 1 week tasks should be at least 4 weeks long)

短距离长度应根据平均任务长度进行适当调整(例如,1周任务的冲刺应至少为4周)

• Team (including QA) needs to work on becoming more accurate at estimating.

团队(包括QA)需要努力提高估算的准确性。

• Consider doing a separate QA sprint in parallel but off-set if that works best for the team

如果最适合团队,请考虑并行进行单独的QA冲刺,但要进行抵消

• Unit testing!

13 个解决方案

#1

My opinion is that you have an estimation problem. It seems that the time to test each feature is missing, and only the building part is being considered when planning the sprint.

我的意见是你有一个估计问题。似乎缺少测试每个功能的时间,并且在规划sprint时仅考虑构建部件。

I'm not saying it is an easy problem to solve, because it is more common than anything. But things that could help are:

我不是说这是一个容易解决的问题,因为它比任何事情都更常见。但可能有用的事情是:

• Consider QA as members of the dev team, and include them in the sprint planning and estimating more closely.

  将QA视为开发团队的成员,并将其包含在sprint计划和更紧密的估算中。

• 'Releasable Dev tasks' should not take up most of the sprint. Complete working features should. Try to gather metrics about dev time vs QA time for each kind of task and use those metrics when estimating future sprints.

  '可释放的开发任务'不应该占用大部分冲刺。完整的工作功能应该。尝试收集有关每种任务的开发时间与QA时间的指标,并在估计未来冲刺时使用这些指标。

• You might need to review your backlog to see if you have very coarse grained features. Try to divide them in smaller tasks that could be easily estimated and tested.

  您可能需要查看您的待办事项,看看您是否具有非常粗糙的功能。尝试将它们分成可以轻松估算和测试的较小任务。

In summary, it seems that your team hasn't found what its real velocity is because there are tasks that are not being considered when doing the estimation and planning for the sprint.

总而言之,您的团队似乎还没有找到真正的速度,因为在进行sprint的估算和规划时,有些任务没有被考虑。

But in the end, estimation inaccuracy is a tough project management issue that you find in agile-based or waterfall-based projects. Good luck.

但最终,估计不准确是一个棘手的项目管理问题,您可以在基于敏捷或基于瀑布的项目中找到它。祝好运。

#2

A little late to the party here but here's my take based on what you wrote.

这里的聚会有点晚了,但这是基于你所写的内容。

Now, Scrum is a project management methodology, not a development one. But it is key, in my opinion, to have development process in place. Without one, you spend the majority of your time reacting rather than building.

现在,Scrum是一种项目管理方法,而不是开发方法。但在我看来,关键是要有适当的发展过程。没有一个,你花费大部分时间来反应而不是建设。

I'm a test-first guy. In my development process I build tests first to enforce the requirements and the design decisions. How is your team enforcing those? The point I'm trying to make here is that you simply can't "throw stuff over the fence" and expect anything but failure to occur. That failure is either going to be by the test team (by not testing very well and thus letting problems slip by) or by the developers (by not building the product that solves the problem). I'm not saying you must write tests first - I'm not a militant or a test-first evangelist - but I'm saying you must have a process in place to produce quality, tested, ready-for-production code when you reach an iteration's end.

我是测试第一的人。在我的开发过程中,我首先构建测试以强制执行需求和设计决策。你的团队如何执行这些?我试图在这里提出的观点是,你根本不能“把东西扔到篱笆上”,并期待任何事情,但不会发生。这种失败要么是由测试团队(通过不能很好地测试,从而让问题漏掉),要么是开发人员(通过不构建解决问题的产品)。我不是说你必须首先编写测试 - 我不是激进分子或测试优先的传播者 - 但我说你必须有一个流程来制作质量,测试,准备生产的代码当你达到迭代的结束。

I've been right where you are in this development methodology that I call the Death Spiral Method. I built software for the government (US) for years in such a model. It doesn't work well, it costs a LOT of money, it produces late code, poor code, and does nothing for morale. You can't make any headway when you spend all your time fixing bugs you could have avoided making in the first place. I was absolutely beaten down by the affair.

我一直都在这个开发方法中,我称之为死亡螺旋方法。我在这样的模型中为*(美国)建立了多年的软件。它不能很好地工作,它花费了很多钱,它产生了晚期的代码,糟糕的代码,并没有为士气做任何事情。当你花费所有时间来修复你本可以避免制造的错误时,你无法取得任何进展。我被这件事彻底打败了。

You don't want QA finding your problems. You want to put them out of work, really. My goal is to make QA flabbergasted because everything just works. Granted, that is a goal. In practice, they'll find stuff. I'm not super-human. I make mistakes.

您不希望QA发现您的问题。你想让他们失业,真的。我的目标是让QA大吃一惊,因为一切正常。当然,这是一个目标。在实践中,他们会找到东西。我不是超级人类。我犯错了。

Back to scheduling...

回到安排......

At my current job we do Scrum, we just don't call it that. We aren't into labels here but we are into producing quality code on time. Everyone is on-board. We tell QA what we'll have ready to test and when. If they come a-knocking two weeks early for it, they can talk to the hand. Everyone knows the schedule, everyone knows what will be in the release and everyone knows that the product has to work as advertised before it goes to QA. So what does that mean? You tell QA "don't bother testing XYZ - it is broken and won't be fixed until release C" and if they go testing that, you point them back at that statement and tell them not to waste your time. Harsh, perhaps, but sometimes necessary. I'm not about being rude, but everyone needs to know "the rules" and what should be tested and what is a 'known issue'.

在我目前的工作中,我们做Scrum,我们只是不称它为。我们不是在这里做标签,而是按时生产高质量的代码。每个人都在船上。我们告诉QA我们准备好测试什么以及什么时候测试。如果他们提前两周来敲门,他们可以和他们说话。每个人都知道时间表,每个人都知道发布中会有什么,每个人都知道产品必须像广告中那样在QA之前工作。那是什么意思呢?你告诉QA“不要打扰测试XYZ - 它已经坏了,在发布C之前不会被修复”,如果他们去测试那个,你就把它们指回那个声明并告诉他们不要浪费你的时间。苛刻,也许,但有时是必要的。我不是要粗鲁,但每个人都需要知道“规则”,应该测试什么以及什么是“已知问题”。

Your management has to be on board. If they aren't you are going to have troubles. QA can't run the show and the dev group can't completely run it either. All the groups (even if those groups are just one person per group or a guy that wears several hats) need to be on the same page: the customer, the test team, the developers, management, and anyone else. More than half the battle is communication, typically.

您的管理层必须在船上。如果不是,你就会遇到麻烦。 QA无法运行该节目,开发组也无法完全运行它。所有组(即使这些组只是每组一个人或戴着几顶帽子的人)都需要在同一页面上:客户,测试团队,开发人员,管理人员和其他任何人。通常,超过一半的战斗是沟通。

Perhaps you are biting off more than can be accomplished during a sprint. That might be the case. Why are you doing that? To meet a schedule? If so, that is where management needs to step in and resolve the issue. If you are giving QA buggy code, expect them to toss it back. Better to give them 3 things that work than 8 things that are unfinished. The goal is to produce some set of functionality that is completely implemented on each iteration, not to throw together a bunch of half-done stuff.

也许你在冲刺期间所做的事情远不止于此。情况可能就是这样。你为什么这样做?要满足时间表?如果是这样,那就是管理层需要介入并解决问题的地方。如果您要提供QA错误代码,请期待他们将其丢回。最好给他们3件有用的东西,而不是8件未完成的东西。目标是生成一些在每次迭代时完全实现的功能集,而不是将一堆半完成的东西放在一起。

I hope this is received as it is intended to be - as an encouragement not a rant. Like I mentioned, I've been where you are and it isn't fun. But there is hope. You can get things turned around in a sprint, maybe two. Perhaps you don't add any new functionality in the next sprint and simply fix what is broken. You'll have to decide that as a team.

我希望这是收到的,因为它的目的是 - 作为鼓励而不是咆哮。就像我提到的那样,我一直都在你身边,这并不好玩。但是有希望。你可以在冲刺中扭转局面,也许两个。也许您不会在下一个sprint中添加任何新功能,只需修复损坏的内容即可。你必须作为一个团队来决定。

One more small plug for writing test code: I've found myself far more relaxed and far more confident in my product since adopting a 'write the tests first' approach. When all my tests pass, I have a level of confidence that I simply couldn't have without them.

另一个用于编写测试代码的小插件:自从采用“首先编写测试”方法以来,我发现自己对我的产品更加放松,更加自信。当我的所有测试都通过时,我有一种自信,如果没有它们,我就无法拥有。

Best of luck!

祝你好运!

#3

It seems to me that there is a resource allocation problem in scenarios requiring QA functional testing in order for a given feature to be 'done' within a sprint. No one seems to address this in any QA-related scrum discussion I've found so far, and the original question here is almost the same (at least related), so I wanted to offer a partial answer and extend the question a bit.

在我看来,在需要QA功能测试的场景中存在资源分配问题,以便在sprint中“完成”给定功能。在我迄今为止发现的任何QA相关的scrum讨论中似乎没有人解决这个问题,这里的原始问题几乎相同(至少是相关的),所以我想提供一个部分答案并稍微扩展一下这个问题。

As to the specific original question about development tasks taking the full sprint - it seems that the general advice of easing up on these tasks makes sense if functional testing by QA is part of your definition of 'done'. Given lets say a 4 week sprint, if it takes about a week to test multiple features from multiple developers, then it seems like development tasks taking about 3 weeks, followed by a lag week of testing tasks taking about 1 week is the answer. QA would of course start as soon as possible be we recognize that from the last set of delivered features, there will be about a week lag. I realize that we want to get features to QA asap so you don't have this waterfall-like scenario in a sprint, but the reality is that development usually can't get real, worthwhile delivered functionality to QA until 1 to 3 weeks into the sprint. Sure there are bits and pieces here and there, but the bulk of the work is 2-3 weeks development, then about a week's testing leftover.

至于关于完整冲刺的开发任务的具体原始问题 - 如果QA的功能测试是您对'完成'的定义的一部分,那么放宽这些任务的一般建议似乎是有意义的。假设让我们说4周冲刺,如果需要大约一周的时间来测试来自多个开发人员的多个功能,那么看起来开发任务需要大约3周,然后是大约1周的测试任务延迟一周就是答案。 QA当然会尽快开始我们认识到,从最后一组交付的功能中,将会有大约一周的延迟。我意识到我们希望尽快获得QA的功能,因此您不会在sprint中拥有这种类似瀑布的场景,但实际情况是开发通常无法实现真正​​的,有价值的QA功能,直到1到3周之后冲刺。当然,这里和那里都有点点滴滴,但大部分工作是2-3周的开发,然后大约一周的测试剩余。

So here is the resource allocation problem, and my extension to the question - in the above scenario QA has time to test the planned features of a sprint (3 weeks worth of development tasks, leaving the last week for testing the features delivered last). Also let's assume QA starts to get some testable features after 1 week of development - but what about week #1 for QA, and what about week #4 for development?

所以这里是资源分配问题,以及我对问题的扩展 - 在上面的场景中QA有时间测试sprint的计划功能(3周的开发任务,最后一周用于测试最后提供的功能)。另外,让我们假设QA在开发一周后开始获得一些可测试的功能 - 但QA的第一周是什么,以及第四周的开发是什么?

If QA functional testing is part of the definition of 'done' for a feature in a sprint, then it seems this inefficiency is unavoidable. QA will be largely idle during week #1 and development will be largely idle during week #4. Of course there are some things that fill in this time naturally, like bug fix and verification, design/plan, etc., but we are essentially scheudling our resources at 75% capacity.

如果QA功能测试是sprint中某个功能的“完成”定义的一部分,那么这种低效率似乎是不可避免的。 QA将在第1周内基本闲置,并且在第4周期间开发将基本闲置。当然,这个时候有些东西自然会填满,比如错误修复和验证,设计/计划等等,但我们基本上以75%的容量计划我们的资源。

The obvious answer seems to be overlapping sprints for development and QA since the reality is that QA always lags beind development to some degree. Demonstrations to product owners and others would follow the QA sprint since we want features to be tested before being shown. This seems to allow more efficient use of both develoment and QA since we don't have as much wasted time. Assuming we want to keep developers developing and tester testing, I can't see a better practical solution. Perhaps I have missed something, and I hope someone can shed some light on this for me - otherwise it seems this rigid approach to scrum is flawed. Thanks.

显而易见的答案似乎是发展和质量保证的重叠冲刺,因为现实是质量保证总是在一定程度上落后于发展。产品所有者和其他人的演示将遵循QA sprint,因为我们希望在显示之前测试功能。这似乎可以更有效地利用开发和QA,因为我们没有浪费太多时间。假设我们想让开发人员继续开发和测试测试,我看不到更好的实用解决方案。也许我错过了一些东西,我希望有人可以为我揭示这一点 - 否则看起来这种严厉的scrum方法是有缺陷的。谢谢。

#4

Hopefully, you fix this by tackling fewer dev tasks in each sprint. Which leads to the questions: Who's settings dev's goals? Why is Dev falling short of those goals consistently?

希望您通过在每个sprint中处理更少的开发任务来解决这个问题。这引出了一些问题:谁设定了开发人员的目标?为什么Dev一直没有达到这些目标?

If dev isn't setting their own goals, that's why they're always late. And that isn't the ideal way to practice Scrum. That's just incremental development with big, deadline-driven deliverables and no actual stake-holder responsibility on the part of developers.

如果开发者没有设定自己的目标,那就是他们总是迟到的原因。这不是练习Scrum的理想方式。这只是增量开发,具有大的,截止期限驱动的可交付成果,并且开发人员没有实际的利益相关者责任。

If dev can't set their own goals because they don't know enough, then they have to be more involved up front.

如果开发人员因为不了解而无法设定自己的目标,那么他们必须更多地参与到前面。

Scrum depends on four basic principles, outlined in the Agile Manifesto.

Scrum取决于敏捷宣言中概述的四个基本原则。

1. Interactions matter -- that means dev, QA, project management, and end users need to talk more and talk with each other. Software is a process of encoding knowledge in the arcane language of computers. To encode the knowledge, the developers must have the knowledge. [Why do you think we call it "code"?] Scrum is not a "write spec - throw over transom" methodology. It's ANTI-"write spec - throw over transom"

   交互很重要 - 这意味着开发,QA,项目管理和最终用户需要更多地交谈并相互交谈。软件是用计算机的神秘语言编码知识的过程。要对知识进行编码,开发人员必须具备相关知识。 [为什么你认为我们称它为“代码”?] Scrum不是“写规范 - 抛出横向”方法。这是反对“写规范 - 抛出横梁”

2. Working Software matters -- that means that each piece dev bites off has to lead to a working release. Not a set of bug fixes for QA to wrestle with, but working software.

   工作软件很重要 - 这意味着每件作品都必须导致工作发布。不是QA的一组错误修复来解决,而是工作软件。

3. Customer Collaboration -- that means dev has to work with business analysts, end users, business owners, everyone who can help them understand what they're building. The deadlines don't matter as much as the next thing handed over to the customer. If the customer needs X, that's the highest priority thing for everyone to do. If the project plan says build Y, that's a load of malarkey.

   客户协作 - 这意味着开发人员必须与业务分析师,最终用户,业务所有者以及能够帮助他们了解他们正在构建的内容的每个人合作。截止日期与下一件交给客户的事情无关。如果客户需要X,这是每个人都要做的最重要的事情。如果项目计划说构建Y,那就是malarkey的负载。

4. Responding to Change -- that means that customers can rearrange the priorities of the following sprints. They can't rearrange the sprint in process (that's crazy) but all the following sprints are candidates for changing priorities.

   响应变化 - 这意味着客户可以重新安排以下冲刺的优先级。他们无法在进程中重新安排冲刺(这很疯狂)但是所有以下冲刺都是改变优先级的候选者。

If the customer drives, then the deadlines become less artificial "project milestones" and more "we need X first, then Y, and this thing in section Z, we don't need that any more. Now that we have W, Z is redundant."

如果客户开车,那么最后期限变得不那么人为“项目里程碑”,更多“我们首先需要X,然后是Y,而这一点在Z部分,我们不再需要它了。现在我们有W,Z是多余的“。

#5

The Scrum rules say that all Sprint items need to be "fully tested, potentially implementable features" at the end of the Sprint to be considered complete. Sprints ALWAYS end on time, and the Team doesn't get credit and isn't allowed to present anything at the Sprint review that isn't complete - and that includes QA.

Scrum规则说,所有Sprint项目都需要在Sprint结束时“完全测试,可能实现的功能”才能被认为是完整的。 Sprint总是按时结束,并且团队不会获得信用,并且不允许在Sprint评论中提供任何未完成的内容 - 包括QA。

Technically, that's all you should need. A Team commits to a certain amount of work, finally gets it to QA two days before the end of the Sprint and the QA isn't done in time. So the output from the Sprint is zero, they have to go in front of the Customer and admit that they have nothing to show for a month of work.

从技术上讲,这就是你应该需要的。一个团队承诺一定数量的工作,最终在Sprint结束前两天进入QA并且QA没有及时完成。因此,Sprint的输出为零,他们必须走在客户面前,并承认他们没有任何东西可以展示一个月的工作。

Next time round, you'll bet that they'll pick less work and figure out how to get it to QA so that it can be finished on time.

下一次,你会打赌他们会选择更少的工作,并找出如何让它到QA,以便它可以按时完成。

#6

Speaking as a QA who has worked on Agile projects for 2.5 years this is a really difficult issue and I still don't have all the answers.

作为一名从事敏捷项目工作2。5年的QA,这是一个非常棘手的问题,我仍然没有得到所有答案。

I work as part of a "triplet" (two developers who pair program + one QA) and I am involved in tasking out stories and estimating in planning meetings at the beginning of two week iterations. As adrianh mentioned above it is essential for QAs to get their voice heard in the initial sprint planning. This can be difficult especially if you are working with Developers with very strong personalities however QAs must be assertive in the true sense of the word (i.e. not aggressive or forceful but respectfully seeking to understand the Truth/PO and Developers/technical experts whilst making themselves understood). I advocate producing QA tasks first during planning to encourage a test driven mentality - the QA may have to literally put themselves forward to get this adopted. It is opposite to how many people think software development works but pays dividends for several reasons;

我作为“三元组”的一部分工作(两个开发人员将程序+一个QA配对),我参与了在两周迭代开始时计划会议的故事和估算。正如上面提到的adrianh,QAs必须在最初的sprint计划中听到他们的声音。这可能很难,尤其是如果您与具有非常强烈个性的开发人员合作,但QAs必须在真正意义上的主张(即不具有侵略性或有力,但尊重地寻求理解真理/ PO和开发人员/技术专家同时使自己理解)。我主张在计划鼓励测试驱动的心态时首先制定质量保证任务 - 质量保证部门可能必须真正将自己付诸实践。与有多少人认为软件开发有效但由于多种原因支付红利相反;

1. QA is heard and not relegated to being asked "so how are you going to test that?" after Devs have said their piece (waterfall mentality).

   QA被听到并且没有降级为被问到“所以你将如何测试它?”开发者说过他们的作品(瀑布心态)。

2. It allows QA to propose ideas for testing which at the same time checks the testability of the acceptance criteria while the Truth/PO is present (I did say it is essential for them to be present in the planning meeting didn't I?!) to fill in any gaps in understanding.

   它允许QA提出测试的想法,同时检查验收标准的可测试性,同时存在真相/采购订单(我确实说他们必须出现在计划会议中我不是吗?!)填补理解上的空白。

3. It provides the basis for a test driven approach - after the test approach has been enunciated and tasked the Devs can think about how they will produce code to pass those tests.

   它为测试驱动的方法提供了基础 - 在发布测试方法和任务后,开发人员可以考虑如何生成代码以通过这些测试。

4. If steps 1 - 3 are your only TDD activity for the rest of the iteration you are still doing a million times better than the scenario postulated by Steve in the first post; "Developers thrash around trying to accomplish their tasks. Generally the tasks take most of the sprint to complete. QA pesters Dev to release something they can test, Dev finally throws some buggy code out to QA a day or two before the sprint ends and spends the rest of the time fixing bugs that QA is finding"

   如果步骤1 - 3是您在迭代的其余部分中唯一的TDD活动,那么您仍然比第一篇文章中Steve所假设的情景好一百万倍; “开发人员试图完成他们的任务。通常任务需要大部分sprint才能完成.QA讨厌Dev发布他们可以测试的东西,Dev终于在sprint结束和花费之前的一两天向QA抛出一些错误的代码其余的时间修复QA发现的错误“

Needless to say this comes with some caveats for the QA;

毋庸置疑,这有一些关于质量保证的警告;

1. They must be prepared to have their ideas for testing challenged by Devs and Truth/PO and to reach a compromise; the "QA police" attitude won't wash in an Agile team.

   他们必须准备好让Devs和Truth / PO挑战他们的测试想法并达成妥协; “QA警察”的态度不会在敏捷团队中流淌。

2. QA tasks must strike a difficult balance to be neither too detailed nor too generic (tasks can be written on a card to go on a "radiator board" and discussed at daily stand up meetings - they need to be moved from "in progress" to "completed" DURING the iteration).

   质量保证任务必须达到难以平衡,既不太详细也不太通用(任务可以写在卡上以便放在“散热器板”上并在每日站立会议上讨论 - 它们需要从“进行中”转移到在迭代期间“完成”)。

3. QAs need to prepare for planning/estimation meetings. Don't expect to be able to just turn up and produce a test approach off the top of your head for unseen user stories! Devs do seem to be able to do this because their tasks are often far more clear cut - e.g. "change x module to interface with z component" or "refactor y method". As a QA you need to be familiar with the functionality being introduced/changed BEFORE planning so that you know the scope of testing and what test design techniques you might apply.

   QA需要为规划/评估会议做准备。对于看不见的用户故事,不要期望能够出现并为您提供最佳测试方法!开发者似乎能够做到这一点,因为他们的任务往往更加明确 - 例如“将x模块更改为与z组件接口”或“重构y方法”。作为QA,您需要熟悉计划之前引入/更改的功能,以便了解测试范围以及可能应用的测试设计技术。

4. It is almost essential to automate your tests and have these written and "failing" within the first two or three days of an iteration or at least to co-incide with when the Devs have the code ready. You can then run the test/s and see if they pass as expected (proper QA TDD). This is how you avoid a mini waterfall at the end of iterations. You should really demo the test to the Devs before or as they start coding so they know what to aim for.

   几乎必不可知的是,自动化测试并在迭代的前两三天内将这些内容写入并“失败”,或者至少与开发人员准备好代码时共同使用。然后,您可以运行test / s并查看它们是否按预期通过(正确的QA TDD)。这就是你在迭代结束时避开迷你瀑布的方法。您应该在开始编码之前或开始编码时向Devs演示测试,以便他们知道目标是什么。

5. I say 4 is "almost essential" because the same can sometimes be successfully achieved with manual checklists (dare I say scripts!) of expected behaviour - the key is to share this with Devs ahead of time; keep talking to them!

   我说4“几乎是必不可少的”,因为有时可以通过预期行为的手动清单(我敢说脚本!)成功实现 - 关键是提前与Devs分享;跟他们说话!

With regards to point 2 above on the subject of the tasks, I have tried creating tasks as granular as 1/2 hour to 2 hours in size each corresponding to a demonstrable piece of work e.g. "Add checks for incorrect password to auto test - 2 hrs". While this helps me organise my work it has been criticised by other team members for being too detailed and has the effect at stand ups of me either moving multiple tasks across to complete from the day before or not being able to move any tasks at all because I have not got onto them yet. People really want to see a sense of steady progress at daily stand ups so it is more helpful to create tasks in 1/2 day or 1 day blocks (but you might keep your own list of "micro-tasks" to do towards to completion of the bigger tasks that you use for COMMUNICATING overall progress at the stand-up).

关于上述关于任务主题的第2点,我尝试创建粒度为1/2小时到2小时的任务,每个任务对应于可证明的工作,例如: “添加检查错误密码以自动测试 - 2小时”。虽然这有助于我组织我的工作,但是其他团队成员一直批评它过于详细,并且对我的立场有影响,要么是从前一天完成多个任务,要么根本不能完成任何任务,因为我还没有进入他们。人们真的希望在每日站立时看到稳定的进步感,因此在半天或一天的时间内创建任务会更有帮助(但是你可以保留自己的“微任务”列表来完成您用于在站立时传达整体进度的更大任务)

With regards to points 4 and 5 above; the automated tests or manual checklists you prepare early should really cover just the happy paths or key acceptance criteria. Once these pass you can have planned an additional task for a final round of "Exploratory testing" towards the end of the iteration to check the edge cases. What the Devs do during that time is problematic because as far as they are concerned they are "code complete" unless and until you find a bug. Some Agile practitioners advocate going for the edge cases first although this can also be problematic because if you run out of time you may not have assured that the acceptance criteria have been delivered. This is one of those finely balanced decisions that depends on the context of the user story and your experience as a QA!

关于上述第4点和第5点;您提前准备的自动化测试或手动检查清单应该只涵盖快乐路径或关键验收标准。一旦这些通过,您可以计划在迭代结束时进行最后一轮“探索性测试”的额外任务,以检查边缘情况。 Devs在那段时间做的事情是有问题的,因为就他们而言,他们是“代码完整”,除非你发现了一个bug。一些敏捷从业者提倡首先考虑边缘案例,尽管这也可能有问题,因为如果你没时间用完,你可能无法保证已经提供了验收标准。这是一个精细平衡的决策之一,取决于用户故事的背景和您作为QA的经验!

As I said at the beginning I still don't have all the answers but hope the above provide some pointers born out of hard experience!

正如我在开始时所说的那样,我仍然没有得到所有答案,但希望上面提供一些经验丰富的指针!

#7

Sounds like your development team might not be doing enough testing on their own, before the release to QA. If all your unit tests are passing, the QA cycle should be relatively smooth sailing, no? They'll find some integration errors, but there shouldn't be very many of those, right?

在发布到QA之前,听起来你的开发团队可能没有自己做足够的测试。如果你的所有单元测试都通过了,那么QA周期应该相对平稳,不是吗?他们会发现一些集成错误,但不应该有很多这样的错误,对吧?

#8

I think that there are several problems here. First, I think that perhaps the developer tasks aren't either fine grained enough, or perhaps not estimated well, or perhaps both. The whole purpose of the sprints in Scrum is to be able to demonstrate workable code at the end of the sprints. Both of the problems that I mentioned could lead to buggy code.

我认为这里有几个问题。首先,我认为开发人员的任务可能不是很好,或者估计不好,或者两者都不是。 Scrum中sprint的全部目的是能够在sprint结束时演示可行的代码。我提到的两个问题都可能导致错误的代码。

If developers are release buggy code towards the end of the sprint, I would also look at:

如果开发人员在sprint结束时发布了错误代码,我还会看看:

• Are the product owners really holding the dev members accountable for getting their tasks done. That's the job of the PO and if that's not happening, then the developers will slack.

产品所有者是否真的让开发成员对完成任务负责。这是PO的工作,如果没有发生,那么开发人员就会松懈。

• Are the devs using any kind of TDD. If not, that might help matters greatly. Get the developers in the habit of testing their code. We have this problem where I work, and my team is focused on doing the TDD in the important areas so that we don't have to have someone else do it later

开发人员是否使用任何类型的TDD。如果没有,这可能会有很大帮助。让开发人员养成测试代码的习惯。我工作的地方有这个问题,我的团队专注于在重要领域进行TDD,以便我们以后不必让其他人这样做

• Are the task/user stories too generic? Wiggle room in the task breakdowns will cause developers to be sloppy. Again, this is somewhat of a PO problem.

任务/用户故事是否过于通用?任务故障中的摆动空间将导致开发人员马虎。同样,这有点像PO问题。

One idea that I've heard batted around in the past is to use a QA person as scrummaster. They will be present for the daily standups and can get sense of where things are at with the developers. They can address issues with the PO (assuming that the PO can adequately do their job).

我过去听过的一个想法是使用QA人作为scrummaster。他们将参加每日站立,并了解开发人员的工作场所。他们可以解决PO的问题(假设PO可以充分地完成他们的工作)。

I can't help but feel that you need more coorporation between QA and your scrum teams. It sounds like testing only happens at the end, which is a problem. Getting QA to be a part of the team will help identify things that can be tested earlier and better.

我不禁觉得你需要QA和你的scrum团队之间更多的合作。听起来测试只发生在最后,这是一个问题。让QA成为团队的一员将有助于识别可以更早,更好地测试的内容。

I also feel like you have an issue with the product owner. They must be in there making sure that everyone is driving the right direction. they should be making sure that there is good cooperation, not only between QA and devs, but between the devs themselves.

我也觉得您对产品所有者有疑问。他们必须在那里确保每个人都在朝着正确的方向前进。他们应该确保不仅在QA和开发者之间,而且在开发者之间进行良好的合作。

#9

"How is scrum supposed to work when releasable Dev tasks take up most of the sprint?"

“当可释放的开发任务占据大部分冲刺时,scrum应该如何工作?”

As you've found out - it doesn't work terribly well :-) The process you're describing doesn't sound much like Scrum to me - or at least not like Scrum done well.

正如你已经发现的那样 - 它的效果不是很好:-)你所描述的过程对我来说听起来不像Scrum - 或者至少不像Scrum做得好。

I'm unsure from what you've described whether the QA folk are part of the team - or a separate group.

我不确定你所描述的QA人是否是团队的一部分 - 或者是一个单独的团体。

If they're a separate group then this is probably a big part of the problem. They won't be involved in the team's commitment to completion of tasks - and the associated scope negotiation with the product owner. I've never seen an agile group succeed well without their being QA skills in the team. Either by having developers with a lot of testing/QA skills - or by having an embedded QA person or three on the team.

如果他们是一个单独的小组,那么这可能是问题的重要组成部分。他们不参与团队完成任务的承诺 - 以及与产品所有者的相关范围协商。如果没有他们在团队中的QA技能,我从未见过敏捷团队成功。通过让开发人员具备大量测试/ QA技能 - 或者通过在团队中拥有一个或三个嵌入式QA人员。

If they are on the team then they need to get their voice heard more in the initial sprint planning. By now it should be clear to the product owner and team that you're overcommitting.

如果他们在团队中,那么他们需要在最初的sprint计划中更多地听到他们的声音。到目前为止,产品所有者和团队应该清楚您过度使用。

I'd try a few things if it were me:

如果是我,我会尝试一些事情:

• Get QA/testing folk on the team if they're not there already

如果他们不在那里,请在团队中获得QA /测试人员

• Have a good long chat with the product owner & the team over what counts as "done". It sounds like some of the developers are still in the pre-scrum mindset of "handed over to QA"" == done.

与产品所有者和团队进行长时间的聊天,了解“完成”。听起来有些开发人员仍处于“移交给QA”的前Scrum思维中“==完成。

• Break down the stories into smaller chunks - makes it easier to spot estimation mistakes

将故事细分为更小的块 - 更容易发现估计错误

• Consider running shorter sprints - because little and more often is easier to track and learn from.

考虑运行更短的冲刺 - 因为很少和更经常更容易跟踪和学习。

You might also find these tips about smoothing down a scrum burndown useful.

您可能还会发现有关平滑scrum burndown的这些提示很有用。

#10

We solved this problem as follows: - Every item in the product backlog must have fit criteria or acceptance criteria, without those, we don't start a sprint - A tester is part of our team, for every product backlog item, he creates test tasks (1 or more, based on the acceptance criteria) together with an estimation, and a link to the item to test - During the daily scrum, all tasks that are finished are placed in a 'To Test' column - We never do tasks that take longer than 16 hours; tasks that are estimated longer, are split up

我们解决了这个问题如下: - 产品积压中的每个项目都必须符合标准或验收标准,没有这些,我们不会启动冲刺 - 测试人员是我们团队的一部分,对于每个产品积压项目,他创建测试任务(1个或多个,基于验收标准)以及估计和要测试的项目的链接 - 在每日Scrum期间,所有已完成的任务都放在“To Test”列中 - 我们从不执行任务这需要超过16个小时;估计更长的任务被拆分

#11

Split the tasks into smaller tasks.

将任务拆分为较小的任务。

Also, QA can create test cases for Dev to test against.

此外,QA可以为Dev创建测试用例以进行测试。

#12

One idea to consider is to have QA work one iteration behind the main development. That works well in our environment.

需要考虑的一个想法是让QA在主要开发之后进行一次迭代。这在我们的环境中运作良好。

#13

Here I would say that, One size does not fit all. Every team deals QA differently. It so much depends on the project you are working on, either it's a small one or big one. Does it need extensive regression, User acceptance and exploratory testing or you have quite few scenarios to test. Let me restate that in Agile, generalist are preferred on specialist. What is that? Because there is time during the project when you don't have anything to Test, so at that time you might be doing something else. Also you might be doing testing even though you are a hard-core programmer.

在这里我会说,一个尺码并不适合所有人。每个团队以不同方式处理QA。这在很大程度上取决于您正在进行的项目,无论是小型还是大型项目。是否需要进行广泛的回归,用户接受和探索性测试,或者您需要测试的场景很少。让我重申,在敏捷中,通才是专家的首选。那是什么?因为在项目期间你没有任何东西需要测试,所以当时你可能正在做其他事情。即使您是一名核心程序员,您也可能正在进行测试。

How do we handle it? We have regular 2 week sprint. Testing start after a week on the task completed by developers during the week. Now tester keep adding issues to our Issue tracker and developers who are done with their sprint tasks start picking those bugs. By the end of the sprint we mostly get done with our sprint task and all critical and major bugs.

我们该如何处理?我们定期进行为期2周的冲刺。本周开发人员在完成任务后一周内开始测试。现在测试人员不断向我们的问题跟踪器添加问题,完成他们的sprint任务的开发人员开始挑选这些错误。在sprint结束时,我们主要完成了sprint任务以及所有关键和主要错误。

So what does tester two in the first week of the sprint?

那么在冲刺的第一周,测试人员两个是什么?

Well, There are always things to test. We have testing tasks in the backlog, that may include some exploratory testing. Many people don't value Exploratory testing but that is extremely important to build quality products. Good testers create task for themselves and find the possibilities where things go wrong and test them.

好吧,总会有东西要测试。我们在积压中有测试任务,可能包括一些探索性测试。许多人不重视探索性测试,但这对于构建优质产品极为重要。优秀的测试人员为自己创造任务,找到出错的可能性并对其进行测试。

Hope that helps!

希望有所帮助!