"What are the best practices to find business related bugs early in software development process."
Several things.
Use Cases.
Overall Tests based on the Use Cases.
Unit Tests based on the Use Cases.
The important thing is to tie the system -- as a whole -- to real actors, real business value. It's too easy to focus on technical issues. To avoid narrow focus on technical issues, have use cases and test against those.
User stories/Use cases should be specific enough to determine Acceptance critia; The acceptance criteria should include all business rules to prevent the situation you describe, and if your Unit Tests are just testing technical capabilities they are insufficient.
Can you learn from those incidents you mention, why they weren't covered in those artifacts?
Also, in my experience, this is the #1 benefit of continuous integration and "Deliver Early and Often" - you should not discover invalid business rules more than a day or two after the functionality is coded.
I've found FitNesse helps in many such cases -- essentially, to over-simplify, the users specify important examples of "input data" and what corresponding "output results" they expect, and the testing framework checks that the correspondence is correct. Check it out, it won't solve every problem of wrong business rules, but it will help with many.
The best way I know of to catch business problems early is to listen carefully, and ask lots of clarifying questions, up front. "Do you mean...?" and "what about...?" might slow a meeting down, but it can get a lot of information out onto the table quickly. It sounds like the QA and data quality people need to be in the room during these conversations.
But if it's the customer's QA and data quality people who're signing off on stuff that you later find isn't right, they have a problem, too, and as a vendor/contractor/consultant, it's not a problem for you to solve (beyond pointing it out).
Close interaction with someone who is knowledgeable about the business. I find that simple flow charts work well -- these can represent use cases in a diagrammatic form that is easier for the user to understand.
It is also important to have early and frequent interaction with the user - determine all the data requirements at each point of the use case, where the data comes from, constraints on the data etc. Use cases using sample data are useful for detecting misunderstandings here.
It also helps to have an early prototype. Powerpoint is good for this, as it doesn't tempt you to start "coding" at an early phase.
If those business rules can (without too much effort) be expressed in code, "Design by Contract" might be usefull in your situation. Use assertions to make sure every part of the program plays by the rules.
test driven unit tests (write the unit tests first)
automated functional tests
full regression test run at least daily (if not at every check in)
Also, all User Acceptance Test, designed by the business, should be captured in your automated functional tests.
If your developers use
pair developing
test driven development
continuous integration
refactoring
then such practices will drive defects to zero or near zero during UAT and in production. Defects found in UAT or production will be the exception. If you do not follow theses practice much of the teams velocity will be lost and spent fixing defects. We have found that if a defect found in development cost 1x, the it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix if found in production. As you can see, driving defect to the left (earlier in the development life cycle) more than pays for itself.
发布评论
评论（9）
“在软件开发过程的早期发现与业务相关的错误的最佳实践是什么。”
有几件事。
用例。
基于用例的总体测试。
基于用例的单元测试。
重要的是要将整个系统与真正的参与者、真正的商业价值联系起来。 人们很容易关注技术问题。 为了避免狭隘地关注技术问题，请提供用例并针对这些用例进行测试。
"What are the best practices to find business related bugs early in software development process."
Several things.
Use Cases.
Overall Tests based on the Use Cases.
Unit Tests based on the Use Cases.
The important thing is to tie the system -- as a whole -- to real actors, real business value. It's too easy to focus on technical issues. To avoid narrow focus on technical issues, have use cases and test against those.
用户验收测试专注于此类问题。
User Acceptance Testing focuses on these sorts of issues.
用户故事/用例应该足够具体以确定验收标准； 验收标准应包括所有业务规则，以防止出现您所描述的情况，如果您的单元测试只是测试技术能力，那么它们是不够的。
您能否从您提到的那些事件中了解到，为什么这些文物没有涵盖它们？
另外，根据我的经验，这是持续集成和“尽早并经常交付”的第一大好处 - 在功能编码后一两天内您不应该发现无效的业务规则。
User stories/Use cases should be specific enough to determine Acceptance critia; The acceptance criteria should include all business rules to prevent the situation you describe, and if your Unit Tests are just testing technical capabilities they are insufficient.
Can you learn from those incidents you mention, why they weren't covered in those artifacts?
Also, in my experience, this is the #1 benefit of continuous integration and "Deliver Early and Often" - you should not discover invalid business rules more than a day or two after the functionality is coded.
我发现 FitNesse 在许多此类情况下都有帮助 - 本质上，为了过度简化，用户指定了重要的示例他们期望“输入数据”和相应的“输出结果”，测试框架检查对应关系是否正确。 检查一下，它并不能解决错误业务规则的所有问题，但它会帮助解决很多问题。
I've found FitNesse helps in many such cases -- essentially, to over-simplify, the users specify important examples of "input data" and what corresponding "output results" they expect, and the testing framework checks that the correspondence is correct. Check it out, it won't solve every problem of wrong business rules, but it will help with many.
据我所知，尽早发现业务问题的最佳方法是仔细倾听，并预先提出大量澄清问题。 “你的意思是...？” 以及“那……呢？” 可能会减慢会议速度，但它可以快速获得大量信息。 听起来，在这些对话期间，质量保证和数据质量人员需要在场。
但是，如果是客户的 QA 和数据质量人员签署了您后来发现不正确的内容，那么他们也有问题，作为供应商/承包商/顾问，这是不是你要解决的问题（除了指出它之外）。
The best way I know of to catch business problems early is to listen carefully, and ask lots of clarifying questions, up front. "Do you mean...?" and "what about...?" might slow a meeting down, but it can get a lot of information out onto the table quickly. It sounds like the QA and data quality people need to be in the room during these conversations.
But if it's the customer's QA and data quality people who're signing off on stuff that you later find isn't right, they have a problem, too, and as a vendor/contractor/consultant, it's not a problem for you to solve (beyond pointing it out).
作为对 akf 答案的补充，我想推荐一本综合指南，应用的用户故事< /a>.
As a compliement to akf's answer, I would like to recommend a comprehensive guide, User Stories Applied.
与了解业务的人密切互动。 我发现简单的流程图效果很好——它们可以以图表形式表示用例，更容易让用户理解。
尽早和频繁地与用户进行交互也很重要 - 确定用例每个点的所有数据需求、数据来自哪里、数据的约束等。使用示例数据的用例对于检测此处的误解很有用。
拥有早期原型也很有帮助。 Powerpoint 对此很有用，因为它不会诱使您在早期阶段开始“编码”。
Close interaction with someone who is knowledgeable about the business. I find that simple flow charts work well -- these can represent use cases in a diagrammatic form that is easier for the user to understand.
It is also important to have early and frequent interaction with the user - determine all the data requirements at each point of the use case, where the data comes from, constraints on the data etc. Use cases using sample data are useful for detecting misunderstandings here.
It also helps to have an early prototype. Powerpoint is good for this, as it doesn't tempt you to start "coding" at an early phase.
如果这些业务规则可以（无需太多努力）用代码表达，“按契约设计 “对于您的情况可能有用。 使用断言来确保程序的每个部分都遵守规则。
If those business rules can (without too much effort) be expressed in code, "Design by Contract" might be usefull in your situation. Use assertions to make sure every part of the program plays by the rules.
你的故事卡应该有
，这将推动测试驱动单元测试的创建
此外，所有用户验收测试都设计了应该在您的自动化功能测试中捕获。
如果您的开发人员使用
那么此类实践将在 UAT 和生产过程中将缺陷降至零或接近于零。 在 UAT 或生产中发现的缺陷属于例外情况。 如果你不遵循这些实践，团队的大部分速度将会损失并花费在修复缺陷上。 我们发现，如果在开发过程中发现的缺陷成本为 1 倍，则在功能测试期间修复的成本为 2 倍，在 UAT 期间修复的成本为 3 倍，如果在生产中发现缺陷则修复成本为 4 倍。 正如您所看到的，将缺陷推向左侧（在开发生命周期的早期）是值得的。
Your story cards should have
which will drive the creation of
Also, all User Acceptance Test, designed by the business, should be captured in your automated functional tests.
If your developers use
then such practices will drive defects to zero or near zero during UAT and in production. Defects found in UAT or production will be the exception. If you do not follow theses practice much of the teams velocity will be lost and spent fixing defects. We have found that if a defect found in development cost 1x, the it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix if found in production. As you can see, driving defect to the left (earlier in the development life cycle) more than pays for itself.