If a defect gets to a customer, it is the team's fault, therefore the team should be writing test cases to assure that defects don't reach the customer.
The Project Manager (PM) should understand the domain better than anyone on the team. Their domain knowledge is vital to having test cases that make sense with regard to the domain. They will need to provide example inputs and answer questions about expectations on invalid inputs. They need to provide at least the 'happy path' test case.
The Developer(s) will know the code. You suggest the developer may be best for the task, but that you are looking for black box test cases. Any tests that a developer comes up with are white box tests. That is the advantage of having developers create test cases – they know where the seams in the code are.
Good developers will also be coming to the PM with questions "What should happen when...?" – each of these is a test case. If the answer is complex "If a then x, but if b then y, except on Thursdays" – there are multiple test cases.
The Testers (QA) know how to test software. Testers are likely to come up with test cases that the PM and the developers would not think of – that is why you have testers.
I think the Project Manager, or Business Analyst should write those test cases. They should then hand them over to the QA person to flesh out and test.
That way you ensure no missing gaps between the spec, and what's actually tested and delivered.
The developer's should definately not do it, as they'll be testing their unit tests. So it's a waste of time.
In addition these tests will find errors which the developer will never find as they are probably due to a misunderstanding in the spec, or a feature or route through the code not having been thought through and implemented correctly.
If you find you don't have enough time for this, hire someone else, or promote someone to this role, as it's key to delivering an excellent product.
From past experience, we had pretty good luck defining tests at different levels to test slightly different things:
1st tier: At the code/class level, developers should be writing atomic unit tests. The purpose is to test individual classes and methods as much as possible. These tests should be run by developers as they code, presumably before archiving code into source control, and by a continuous-integration server (automated) if one is being used.
2nd tier: At the component integration level, again have developers creating unit tests, but that test the integration between components. The purpose is not to test individual classes and components, but to test how they interact with each other. These tests should be run manually by an integration engineer, or automated by a continuous-integration seerver, if one is in use.
3rd tier: At the application level, have the QA team running their system tests. These test cases should be based off the business assumptions or requirements documents provided by a product manager. Basically, test as if you were an end user, doing the things end users should be able to do, as documented int eh requirements. These test cases should be written by the QA team and the product managers who (presumably) know what the customer wants and how they are expected to use the application.
I feel this provides a pretty good level of coverage. Of course, tiers 1 and 2 above should ideally be run before sending a built application to the QA team. Of course, you can adapt this to whatever fits your business model, but this worked pretty well at my last job. Our continous-integration server would kick out an email to the development team if one of the unit tests failed during the build/integration process too, incase someone forgot to run their tests and committed broken code into the source archive.
We experimented with a pairing of the developer with a QA person with pretty good results. They generally 'kept each other honest' and since the developer had unit tests to handle the code, s/he was quite intimate with the changes already. The QA person wasn't but came at it from the black box side. Both were held accountable for completeness. Part of the ongoing review process helped to catch unit test shortcomings and so there weren't too many incidents that I was aware of where anyone was purposely avoiding writing X test because it would likely prove there was a problem.
I like the pairing idea in some instances and think it worked pretty well. Might not always work, but having those players from different areas interact helped to avoid the 'throw it over the wall' mentality that often happens.
The reason I don't like having my QA people do it, is because I don't like the idea of them creating their own work. For example they might leave out things that are simply too much work to test, and they may not know the technical detail that is needed.
Yikes, you need to have more trust in your QA department, or a better one. I mean, imagine of you had said "I don't like having my developers develop software. I don't like the idea of them creating their own work."
As a developer, I Know that there are risks involved in writing my own tests. That's not to say I don't do that (I do, especially if I am doing TDD) but I have no illusions about test coverage. Developers are going to write tests that show that their code does what they think it does. Not too many are going to write tests that apply to the actual business case at hand.
Testing is a skill, and hopefully your QA department, or at least, the leaders in that department, are well versed in that skill.
"developers who think it's a waste of their time, or that they simply don't like doing it" Then reward them for it. What social engineering is necessary to get them to create test cases?
Can QA look over the code and test cases and pronounce "Not Enough Coverage -- Need More Cases". If so, then the programmer that has "enough" coverage right away will be the Big Kahuna.
So, my question is: Once the task is done, who should define the goal of "enough" test cases for this task? Once you know "enough", you can make the programmers responsible for filling in "enough" and QA responsible for assuring that "enough" testing is done.
Too hard to define "enough"? Interesting. Probably this is the root cause of the conflict with the programmers in the first place. They might feel it's a waste of their time because they already did "enough" and now someone is saying it isn't "enough".
the QA people, in conjunction with the "customer", should define the test cases for each task [we're really mixing terminology here], and the developer should write them. first!
Select (not just pick randomly) one or two testers, and let them write the test cases. Review. It could also be useful if a developer working with a task looks at the test cases for the task. Encourage testers to suggest improvements and additions to test sets - sometimes people are afraid to fix what the boss did. This way you might find someone who is good at test design.
Let the testers know about the technical details - I think everyone in an agile team should have read access to code, and whatever documentation is available. Most testers I know can read (and write) code, so they might find unit tests useful, possibly even extend them. Make sure the test designers get useful answers from the developers, if they need to know something.
My suggestion would be to having someone else look over the test cases before the code is merged to ensure quality. Granted this may mean that a developer is overlooking another developer's work but that second set of eyes may catch something that wasn't initially caught. The initial test cases can be done by any developer, analyst or manager, not a tester.
QA shouldn't write the test cases as they may be situations where the expected result hasn't been defined and by this point, it may be hard to have someone referee between QA and development if each side thinks their interpretation is the right one. It is something I have seen many many times and wish it didn't happen as often as it does.
I loosely break my tests down into "developer" tests and "customer" tests, the latter of which would be "acceptance tests". The former are the tests that developers write to verify that their code is performing correctly. The later are tests that someone other than developers write to ensure that behavior matches the spec. The developers must never write the accepatance tests because their creation of the software they're testing assumes that they did the right thing. Thus, their acceptance tests are probably going to assert what the developer already knew to be true.
The acceptance tests should be driven by the spec and if they're written by the developer, they'll get driven by the code and thus by the current behavior, not the desired behavior.
The Agile canon is that you should have (at least) two layers of tests: developer tests and customer tests.
Developer tests are written by the same people who write the production code, preferably using test driven development. They help coming up with a well decoupled design, and ensure that the code is doing what the developers think it is doing - even after a refactoring.
Customer tests are specified by the customer or customer proxy. They are, in fact, the specification of the system, and should be written in a way that they are both executable (fully automated) and understandable by the business people. Often enough, teams find ways for the customer to even write them, with the help of QA people. This should happen while - or even before - the functionality gets developed.
Ideally, the only tasks for QA to do just before the merge, is pressing a button to run all automated tests, and do some additional exploratory (=unscripted) testing. You'll want to run those tests again after the merge, too, to make sure that integrating the changes didn't break something.
The purpose of testing is to drive defects to the left (earlier in the software development process when they are cheaper and faster to fix).
Each story card should include acceptance criteria. The Product Owner pairs with the Solution Analyst to define the acceptance criteria for each story. This criteria is used to determine if a story card's purpose has been meet.
The story card acceptance criteria will determine what automated unit tests need to be coded by the developers as they do Test Driven Development. It will also drive the automated functional test implemented by the autoamted testers (and perhaps with developer support if using tools like FIT).
Just as importantly, the acceptance criteria will drive the automated performance tests and can be used when analyzing the profiling of the application by the developers.
Finally, the user acceptance test will be determined by the acceptance criteria in the story cards and should be designed by the business partner and or users. Follow this process and you will likely release with zero defects.
I've rarely have heard of or seen Project Managers write test cases except for in the smaller teams. In any large,complex software application have to have an analyst that really knows the application. I worked at a mortgage company as a PM - was I to understand sub-prime lending, interest rates, and the such? Maybe at a superficial level, but real experts needed to make sure those things worked. My job was to keep the team healthy, protect the agile principles, and look for new opportunities for work for my team.
The system analyst should review over all test-cases and its correct relation with the use-cases. Plus the Analyst should perform the final UAT, which could be based on test-cases also. So the analyst and the quality guy are making sort of peer-review.
The quality is reviewing the use-cases while he is building test-cases, and the analyst is reviewing the test-cases after they are written and while he is performing UAT.
当然BA是领域专家，不是从技术角度来看。 BA 了解需求，并且测试用例应该映射到需求。 开发人员不应该编写测试用例来测试他们的代码。 QA 可以根据需求编写详细的测试步骤。 但是编写需求的人应该决定需要测试什么。 测试用例到底是谁写的，我不太关心，只要测试用例能够追溯到需求即可。 我认为 BA 指导测试方向或范围，而 QA 编写细粒度的测试计划是有道理的。
Of course BA is the domain expert, not from technical point of view. BA understands the requirements and the test cases should be mapped to the requirements. Developers should not be the persons writing the test cases to test against their code. QA can write detail test steps per requirement. But the person who writes the requirement should dictate what needs to be tested. Who actually writes the test cases, I dont care too much as long as the test cases can be traced back to requirements. I would think it makes sense that BA guides the testing direction or scope, and QA writes the granular testing plans.
We need to evolve from the "this is how it has been done or should be done mentality" it is failing and failing continuously. The best way to resolve the test plan/cases writing issue is that test cases should be written on the requirements doc in waterfall or the user story in agile as those reqs/user stories are being written. This way there is no question what needs to be tested and QA and UAT teams can execute the test case(s) and focus time on actual testing and defect resolution.
发布评论
评论（16）
团队。
如果客户发现了缺陷，那么这是团队的错误，因此团队应该编写测试用例确保缺陷不会到达客户手中。
项目经理 (PM) 应该比团队中的任何人都更了解该领域。 他们的领域知识对于拥有对该领域有意义的测试用例至关重要。 他们需要提供示例输入并回答有关无效输入期望的问题。 他们至少需要提供“快乐路径”测试用例。
开发人员会知道代码。 您建议开发人员可能最适合该任务，但您正在寻找黑盒测试用例。 开发人员提出的任何测试都是白盒测试。 这就是让开发人员创建测试用例的优势 - 他们知道代码中的接缝在哪里。
优秀的开发人员也会向 PM 提出问题“当……时会发生什么？” – 其中每一个都是一个测试用例。 如果答案很复杂“如果a则x，但如果b则y，周四除外” –有多个测试用例。
测试人员 (QA) 知道如何测试软件。 测试人员可能会提出 PM 和开发人员不会想到的测试用例 - 这就是您拥有测试人员的原因。
The Team.
If a defect gets to a customer, it is the team's fault, therefore the team should be writing test cases to assure that defects don't reach the customer.
The Project Manager (PM) should understand the domain better than anyone on the team. Their domain knowledge is vital to having test cases that make sense with regard to the domain. They will need to provide example inputs and answer questions about expectations on invalid inputs. They need to provide at least the 'happy path' test case.
The Developer(s) will know the code. You suggest the developer may be best for the task, but that you are looking for black box test cases. Any tests that a developer comes up with are white box tests. That is the advantage of having developers create test cases – they know where the seams in the code are.
Good developers will also be coming to the PM with questions "What should happen when...?" – each of these is a test case. If the answer is complex "If a then x, but if b then y, except on Thursdays" – there are multiple test cases.
The Testers (QA) know how to test software. Testers are likely to come up with test cases that the PM and the developers would not think of – that is why you have testers.
我认为项目经理或业务分析师应该编写这些测试用例。
然后他们应该将它们交给 QA 人员进行充实和测试。
这样您就可以确保规范与实际测试和交付的内容之间不会遗漏任何差距。
开发人员绝对不应该这样做，因为他们将测试他们的单元测试。
所以这是浪费时间。
此外，这些测试将发现开发人员永远不会发现的错误，因为它们可能是由于对规范的误解，或者代码中的功能或路线没有经过深思熟虑和正确实现而造成的。
如果您发现自己没有足够的时间来执行此操作，请雇用其他人，或将某人提升到该职位，因为这是交付出色产品的关键。
I think the Project Manager, or Business Analyst should write those test cases.
They should then hand them over to the QA person to flesh out and test.
That way you ensure no missing gaps between the spec, and what's actually tested and delivered.
The developer's should definately not do it, as they'll be testing their unit tests.
So it's a waste of time.
In addition these tests will find errors which the developer will never find as they are probably due to a misunderstanding in the spec, or a feature or route through the code not having been thought through and implemented correctly.
If you find you don't have enough time for this, hire someone else, or promote someone to this role, as it's key to delivering an excellent product.
根据过去的经验，我们非常幸运地在不同级别定义测试来测试略有不同的东西：
第一层：在代码/类级别，开发人员应该编写原子单元测试。 目的是尽可能测试各个类和方法。 这些测试应该由开发人员在编码时运行，大概是在将代码归档到源代码管理之前，并且由持续集成服务器（自动化）（如果正在使用）运行。
第二层：在组件集成级别，开发人员再次创建单元测试，但测试组件之间的集成。 目的不是测试各个类和组件，而是测试它们如何相互交互。 这些测试应由集成工程师手动运行，或者由持续集成服务器（如果正在使用）自动运行。
第三层：在应用程序级别，让 QA 团队运行他们的系统测试。 这些测试用例应基于产品经理提供的业务假设或需求文档。 基本上，就像您是最终用户一样进行测试，做最终用户应该能够做的事情，如需求中记录的那样。 这些测试用例应该由 QA 团队和产品经理编写，他们（大概）知道客户想要什么以及他们希望如何使用应用程序。
我觉得这提供了相当好的覆盖范围。 当然，理想情况下，上面的第 1 层和第 2 层应该在将构建的应用程序发送给 QA 团队之前运行。
当然，您可以根据自己的业务模式进行调整，但这在我上一份工作中效果很好。 如果其中一个单元测试在构建/集成过程中失败，我们的持续集成服务器会向开发团队发送一封电子邮件，以防有人忘记运行测试并将损坏的代码提交到源存档中。
From past experience, we had pretty good luck defining tests at different levels to test slightly different things:
1st tier: At the code/class level, developers should be writing atomic unit tests. The purpose is to test individual classes and methods as much as possible. These tests should be run by developers as they code, presumably before archiving code into source control, and by a continuous-integration server (automated) if one is being used.
2nd tier: At the component integration level, again have developers creating unit tests, but that test the integration between components. The purpose is not to test individual classes and components, but to test how they interact with each other. These tests should be run manually by an integration engineer, or automated by a continuous-integration seerver, if one is in use.
3rd tier: At the application level, have the QA team running their system tests. These test cases should be based off the business assumptions or requirements documents provided by a product manager. Basically, test as if you were an end user, doing the things end users should be able to do, as documented int eh requirements. These test cases should be written by the QA team and the product managers who (presumably) know what the customer wants and how they are expected to use the application.
I feel this provides a pretty good level of coverage. Of course, tiers 1 and 2 above should ideally be run before sending a built application to the QA team.
Of course, you can adapt this to whatever fits your business model, but this worked pretty well at my last job. Our continous-integration server would kick out an email to the development team if one of the unit tests failed during the build/integration process too, incase someone forgot to run their tests and committed broken code into the source archive.
我们尝试将开发人员与 QA 人员配对，取得了很好的结果。 他们通常“保持彼此诚实”，并且由于开发人员进行了单元测试来处理代码，因此他/她已经对更改非常熟悉了。 质量检查人员不是，而是从黑匣子方面进行处理。 两者都对完整性负责。 正在进行的审查过程的一部分有助于发现单元测试的缺点，因此我没有注意到太多有人故意避免编写 X 测试的事件，因为这可能会证明存在问题。
在某些情况下，我喜欢这种配对的想法，并且认为它效果很好。 可能并不总是有效，但让来自不同领域的玩家互动有助于避免经常发生的“把它扔到墙上”的心态。
无论如何，希望这对您有所帮助。
We experimented with a pairing of the developer with a QA person with pretty good results. They generally 'kept each other honest' and since the developer had unit tests to handle the code, s/he was quite intimate with the changes already. The QA person wasn't but came at it from the black box side. Both were held accountable for completeness. Part of the ongoing review process helped to catch unit test shortcomings and so there weren't too many incidents that I was aware of where anyone was purposely avoiding writing X test because it would likely prove there was a problem.
I like the pairing idea in some instances and think it worked pretty well. Might not always work, but having those players from different areas interact helped to avoid the 'throw it over the wall' mentality that often happens.
Anyhow, hope that is somehow helpful to you.
哎呀，您需要更加信任您的 QA 部门，或者更好的部门。 我的意思是，想象一下您说过“我不喜欢让我的开发人员开发软件。我不喜欢他们创建自己的作品。”
作为一名开发人员，我知道编写自己的测试存在风险。 这并不是说我不这样做（我确实这样做，特别是如果我正在做 TDD），但我对测试覆盖率不抱任何幻想。 开发人员将编写测试来表明他们的代码执行了他们认为的操作。 没有太多人会编写适用于手头实际业务案例的测试。
测试是一项技能，希望您的 QA 部门，或者至少该部门的领导者，精通这项技能。
Yikes, you need to have more trust in your QA department, or a better one. I mean, imagine of you had said "I don't like having my developers develop software. I don't like the idea of them creating their own work."
As a developer, I Know that there are risks involved in writing my own tests. That's not to say I don't do that (I do, especially if I am doing TDD) but I have no illusions about test coverage. Developers are going to write tests that show that their code does what they think it does. Not too many are going to write tests that apply to the actual business case at hand.
Testing is a skill, and hopefully your QA department, or at least, the leaders in that department, are well versed in that skill.
“开发人员认为这是浪费时间，或者他们根本不喜欢这样做”然后奖励他们。 让他们创建测试用例需要哪些社会工程？
QA 能否检查代码和测试用例并宣布“覆盖范围不够——需要更多用例”。 如果是这样，那么立即拥有“足够”覆盖范围的程序员将是 Big Kahuna。
所以，我的问题是：任务完成后，谁应该为该任务定义“足够”测试用例的目标？ 一旦您知道“足够”，您就可以让程序员负责填写“足够”，让 QA 负责确保完成“足够”测试。
定义“足够”太难？ 有趣的。 也许这就是与程序员发生冲突的根本原因。 他们可能会觉得这是浪费时间，因为他们已经做得“足够”了，现在有人说这还“不够”。
"developers who think it's a waste of their time, or that they simply don't like doing it" Then reward them for it. What social engineering is necessary to get them to create test cases?
Can QA look over the code and test cases and pronounce "Not Enough Coverage -- Need More Cases". If so, then the programmer that has "enough" coverage right away will be the Big Kahuna.
So, my question is: Once the task is done, who should define the goal of "enough" test cases for this task? Once you know "enough", you can make the programmers responsible for filling in "enough" and QA responsible for assuring that "enough" testing is done.
Too hard to define "enough"? Interesting. Probably this is the root cause of the conflict with the programmers in the first place. They might feel it's a waste of their time because they already did "enough" and now someone is saying it isn't "enough".
QA 人员与“客户”一起，应该定义每个任务的测试用例[我们实际上在这里混合了术语]，并且开发人员应该编写它们。 第一的！
the QA people, in conjunction with the "customer", should define the test cases for each task [we're really mixing terminology here], and the developer should write them. first!
选择（不仅仅是随机选择）一两个测试人员，然后让他们编写测试用例。 审查。 如果处理任务的开发人员查看该任务的测试用例，它也可能很有用。 鼓励测试人员对测试集提出改进和添加建议——有时人们害怕修复老板所做的事情。 这样您可能会找到擅长测试设计的人。
让测试人员了解技术细节 - 我认为敏捷团队中的每个人都应该具有对代码以及任何可用文档的读取权限。 我认识的大多数测试人员都可以阅读（和编写）代码，因此他们可能会发现单元测试很有用，甚至可能扩展它们。 如果测试设计者需要了解某些信息，请确保他们从开发人员那里得到有用的答案。
Select (not just pick randomly) one or two testers, and let them write the test cases. Review. It could also be useful if a developer working with a task looks at the test cases for the task. Encourage testers to suggest improvements and additions to test sets - sometimes people are afraid to fix what the boss did. This way you might find someone who is good at test design.
Let the testers know about the technical details - I think everyone in an agile team should have read access to code, and whatever documentation is available. Most testers I know can read (and write) code, so they might find unit tests useful, possibly even extend them. Make sure the test designers get useful answers from the developers, if they need to know something.
我的建议是在合并代码之前让其他人检查测试用例以确保质量。 诚然，这可能意味着一个开发人员忽视了另一个开发人员的工作，但第二双眼睛可能会发现一些最初没有发现的东西。 初始测试用例可以由任何开发人员、分析师或经理完成，而不是测试人员。
QA 不应该编写测试用例，因为它们可能是未定义预期结果的情况，并且此时，如果双方都认为自己的解释是正确的，则可能很难在 QA 和开发之间进行仲裁。 这种事我已经见过很多次了，但愿它不要像现在这样频繁地发生。
My suggestion would be to having someone else look over the test cases before the code is merged to ensure quality. Granted this may mean that a developer is overlooking another developer's work but that second set of eyes may catch something that wasn't initially caught. The initial test cases can be done by any developer, analyst or manager, not a tester.
QA shouldn't write the test cases as they may be situations where the expected result hasn't been defined and by this point, it may be hard to have someone referee between QA and development if each side thinks their interpretation is the right one. It is something I have seen many many times and wish it didn't happen as often as it does.
我将测试松散地分为“开发人员”测试和“客户”测试，后者是“验收测试”。 前者是开发人员编写的测试，用于验证他们的代码是否正确执行。 后者是开发人员之外的其他人编写的测试，以确保行为符合规范。 开发人员绝不能编写验收测试，因为他们在创建正在测试的软件时假定他们做了正确的事情。 因此，他们的验收测试可能会断言开发人员已经知道的事实。
验收测试应该由规范驱动，如果它们是由开发人员编写的，那么它们将由代码驱动，从而由当前行为驱动，而不是所需的行为。
I loosely break my tests down into "developer" tests and "customer" tests, the latter of which would be "acceptance tests". The former are the tests that developers write to verify that their code is performing correctly. The later are tests that someone other than developers write to ensure that behavior matches the spec. The developers must never write the accepatance tests because their creation of the software they're testing assumes that they did the right thing. Thus, their acceptance tests are probably going to assert what the developer already knew to be true.
The acceptance tests should be driven by the spec and if they're written by the developer, they'll get driven by the code and thus by the current behavior, not the desired behavior.
敏捷准则是，您应该（至少）有两层测试：开发人员测试和客户测试。
开发人员测试由编写生产代码的同一个人编写，最好使用测试驱动开发。 它们有助于提出良好的解耦设计，并确保代码正在执行开发人员认为正在执行的操作 - 即使在重构之后也是如此。
客户测试由客户或客户代理指定。 事实上，它们是系统的规范，并且应该以既可以执行（完全自动化）又可以被业务人员理解的方式编写。 通常，团队会在 QA 人员的帮助下找到让客户编写它们的方法。 这应该在功能开发期间甚至之前发生。
理想情况下，质量检查在合并之前要做的唯一任务是按下按钮来运行所有自动化测试，并进行一些额外的探索性（=无脚本）测试。 您还需要在合并后再次运行这些测试，以确保集成更改不会破坏某些内容。
The Agile canon is that you should have (at least) two layers of tests: developer tests and customer tests.
Developer tests are written by the same people who write the production code, preferably using test driven development. They help coming up with a well decoupled design, and ensure that the code is doing what the developers think it is doing - even after a refactoring.
Customer tests are specified by the customer or customer proxy. They are, in fact, the specification of the system, and should be written in a way that they are both executable (fully automated) and understandable by the business people. Often enough, teams find ways for the customer to even write them, with the help of QA people. This should happen while - or even before - the functionality gets developed.
Ideally, the only tasks for QA to do just before the merge, is pressing a button to run all automated tests, and do some additional exploratory (=unscripted) testing. You'll want to run those tests again after the merge, too, to make sure that integrating the changes didn't break something.
测试用例首先在故事卡中开始。
测试的目的是将缺陷推向左侧（在软件开发过程的早期，修复这些缺陷更便宜且更快）。
每张故事卡都应包含验收标准。 产品负责人与解决方案分析师配对，定义每个故事的验收标准。 此标准用于确定故事卡的目的是否已满足。
故事卡验收标准将确定开发人员在进行测试驱动开发时需要编码哪些自动化单元测试。 它还将推动由自动测试人员实施的自动化功能测试（如果使用 FIT 等工具，可能还需要开发人员的支持）。
同样重要的是，验收标准将驱动自动化性能测试，并且可以在开发人员分析应用程序分析时使用。
最后，用户验收测试将由故事卡中的验收标准确定，并应由业务合作伙伴和/或用户设计。 遵循此流程，您可能会以零缺陷的方式发布。
A test case begins first in the story card.
The purpose of testing is to drive defects to the left (earlier in the software development process when they are cheaper and faster to fix).
Each story card should include acceptance criteria. The Product Owner pairs with the Solution Analyst to define the acceptance criteria for each story. This criteria is used to determine if a story card's purpose has been meet.
The story card acceptance criteria will determine what automated unit tests need to be coded by the developers as they do Test Driven Development. It will also drive the automated functional test implemented by the autoamted testers (and perhaps with developer support if using tools like FIT).
Just as importantly, the acceptance criteria will drive the automated performance tests and can be used when analyzing the profiling of the application by the developers.
Finally, the user acceptance test will be determined by the acceptance criteria in the story cards and should be designed by the business partner and or users. Follow this process and you will likely release with zero defects.
除了较小的团队之外，我很少听说或见过项目经理编写测试用例。 在任何大型、复杂的软件应用程序中，都必须有一位真正了解该应用程序的分析师。 我在一家抵押贷款公司担任产品经理，我是否了解次级贷款、利率等？ 也许只是表面上的，但真正的专家需要确保这些事情发挥作用。 我的工作是保持团队健康，保护敏捷原则，并为我的团队寻找新的工作机会。
I've rarely have heard of or seen Project Managers write test cases except for in the smaller teams. In any large,complex software application have to have an analyst that really knows the application. I worked at a mortgage company as a PM - was I to understand sub-prime lending, interest rates, and the such? Maybe at a superficial level, but real experts needed to make sure those things worked. My job was to keep the team healthy, protect the agile principles, and look for new opportunities for work for my team.
系统分析师应该审查所有测试用例及其与用例的正确关系。
另外，分析师应该执行最终的 UAT，这也可以基于测试用例。
因此，分析师和质量人员正在进行同行评审。
质量是在构建测试用例时审查用例，而分析师是在编写测试用例后以及执行 UAT 时审查测试用例。
The system analyst should review over all test-cases and its correct relation with the use-cases.
Plus the Analyst should perform the final UAT, which could be based on test-cases also.
So the analyst and the quality guy are making sort of peer-review.
The quality is reviewing the use-cases while he is building test-cases, and the analyst is reviewing the test-cases after they are written and while he is performing UAT.
当然BA是领域专家，不是从技术角度来看。 BA 了解需求，并且测试用例应该映射到需求。 开发人员不应该编写测试用例来测试他们的代码。 QA 可以根据需求编写详细的测试步骤。 但是编写需求的人应该决定需要测试什么。 测试用例到底是谁写的，我不太关心，只要测试用例能够追溯到需求即可。 我认为 BA 指导测试方向或范围，而 QA 编写细粒度的测试计划是有道理的。
Of course BA is the domain expert, not from technical point of view. BA understands the requirements and the test cases should be mapped to the requirements. Developers should not be the persons writing the test cases to test against their code. QA can write detail test steps per requirement. But the person who writes the requirement should dictate what needs to be tested. Who actually writes the test cases, I dont care too much as long as the test cases can be traced back to requirements. I would think it makes sense that BA guides the testing direction or scope, and QA writes the granular testing plans.
我们需要摆脱“这就是这样做或应该这样做的心态”，它正在不断失败。 解决测试计划/用例编写问题的最佳方法是，在编写这些需求/用户故事时，应将测试用例编写在瀑布中的需求文档或敏捷中的用户故事上。 这样，就不存在需要测试什么的问题，QA 和 UAT 团队可以执行测试用例，并将时间集中在实际测试和缺陷解决上。
We need to evolve from the "this is how it has been done or should be done mentality" it is failing and failing continuously. The best way to resolve the test plan/cases writing issue is that test cases should be written on the requirements doc in waterfall or the user story in agile as those reqs/user stories are being written. This way there is no question what needs to be tested and QA and UAT teams can execute the test case(s) and focus time on actual testing and defect resolution.