Anything that you supply to a customer, you are reponsible for unless your contract of supply with them specifies otherwise. This is why software product EULAs are so long. Have a look at all of the exclusions.
There's a difference between Validation, Verification and Customer Acceptance Testing.
You'll find that a Customer will sign off a package as being Accepted after a period of acceptance testing, but that doesn't mean that they'll accept any bugs within the code. That is why you perform validation and verification testing.
If you're using a licenced SDK to produce a product and your customer is hit finacially due to bugs in your product then you'll need to prove that it isn't your code but the SDK suppliers code if you wish to avoid litigation. This is also why you have insurance.
edit - added
Remember also to only lay claim to anything that you can prove to be the case. Don't claim that your product is Windows 7 compliant or compatible unless you can prove that it is.
You only need to meet a customers quality standards if that is what you have commercially agreed to provide, although you'll find that every country stipulates that software must not be of a malicious or harmful nature and fit for purpose.
发布评论
评论（2）
除非您与客户的供应合同另有规定，否则您对向客户提供的任何东西都负有责任。这就是软件产品 EULA 如此长的原因。查看所有排除情况。
确认、验证和客户验收测试之间存在差异。
您会发现，经过一段时间的验收测试后，客户会签署已接受的包，但这并不意味着他们会接受代码中的任何错误。这就是您执行验证和验证测试的原因。
如果您使用许可的 SDK 来生产产品，并且您的客户因产品中的错误而受到经济损失，那么如果您希望避免诉讼，则需要证明这不是您的代码，而是 SDK 供应商的代码。这也是您拥有保险的原因。
编辑 - 添加
还请记住，仅对您可以证明的情况提出主张。请勿声称您的产品符合或兼容 Windows 7，除非您能证明这一点。
您只需要满足客户的质量标准（如果这是您在商业上同意提供的标准），尽管您会发现每个国家/地区都规定软件不得具有恶意或有害性质并且适合特定用途。
Anything that you supply to a customer, you are reponsible for unless your contract of supply with them specifies otherwise. This is why software product EULAs are so long. Have a look at all of the exclusions.
There's a difference between Validation, Verification and Customer Acceptance Testing.
You'll find that a Customer will sign off a package as being Accepted after a period of acceptance testing, but that doesn't mean that they'll accept any bugs within the code. That is why you perform validation and verification testing.
If you're using a licenced SDK to produce a product and your customer is hit finacially due to bugs in your product then you'll need to prove that it isn't your code but the SDK suppliers code if you wish to avoid litigation. This is also why you have insurance.
edit - added
Remember also to only lay claim to anything that you can prove to be the case. Don't claim that your product is Windows 7 compliant or compatible unless you can prove that it is.
You only need to meet a customers quality standards if that is what you have commercially agreed to provide, although you'll find that every country stipulates that software must not be of a malicious or harmful nature and fit for purpose.
这是一个很老的问题，但我在这个领域有一些经验，因此我认为我可以做出贡献。
我将描述适合中小型公司的简化流程。
该流程从SRS（软件需求规范）开始，并基于SRS的流程图。这些是由软件开发团队准备的。
SRS 转发给验证团队。他们根据 SRS 编写 STD（软件测试描述）并相应地开始验证过程。
在此过程中，他们创建带有屏幕截图等的记录日志。最终，验证团队编写 STR（软件测试记录）
和 STD和 STR 由验证者、IT 经理、QA 经理和文档控制人员签名
It is pretty old question, but I have some experience in this field thus I think I can contribute.
I will describe the simplified process that it suitable for small and middle size companies
The process starts with SRS (Software Requirements Specification) and flowchart based on SRS. These are prepared by software dev team.
The SRS forwarded to validation team. They write STD (Software Test Description) accoriding to the SRS and start validation process accordingly
During the process they create a record log with screenshot, etc... At the end of the day the validation team writes STR (Software Test Record)
Both STD and STR are signed by the validator, IT Manager, QA Manager and Doc Control