认可测试的价值，但更鼓励事先确定验证的标准并以此来驱动开发
认可专业测试人员的不可替代的价值，但更鼓励开发人员做好测试
认可测试计划的价值，但更强调计划是一个基于风险不断调整的过程
认可探索式测试的价值，但更希望测试是具有系统方法的、相对规范的过程
认可发现缺陷的价值，但更重视对软件产品质量的全面评估与持续反馈
崔启亮- 北京ISTQB ：测试需要提高认识，满足用户的综合要求。测试和开发的关系将更加密切，而不是完全独立。提倡测试驱动开发Test Drived Development (TDD)，开发辅助测试Developer Assisted Test (DAT)。
朱少民：回复 @崔启亮 - 北京 ISTQB : TDD 和 DAT 同时出现更好，但我更提倡 ATDD （验收测试驱动开发），提倡先确定验证标准（质量的具体要求）。而 TDD 实施起来效率会有些问题，有一定的浪费。
胡争辉：脱离的产品工程的品质保证工程是无本之木，无源之水。首先应当强调产品工程，然后在产品工程中强调需求工程，其次在需求工程的基础上强调品质保证工程。在一个工程中，品质保证超过需求，或者品质保证超过产品都是没有意义的。
朱少民：回复 @胡争辉: 不能完全同意，品质保证可以跨越产品工程，覆盖整个软件的生态链、生态环境。现在软件更多是服务过程，产品的概念越来越淡薄。
程序员邹欣：值得开发，测试，项目管理人员思考。 认可内部测试的重要性, 但更重视产品对用户的长期影响。
朱少民：回复 @程序员邹欣: 差不多可以作为我的软件测试宣言第 6 句： 认可内部测试的重要性, 但更重视产品对用户的长期影响
胖子- 邓晓明：朱老师，我是在上海软测大会得到您签名书的童鞋， 我有两个问题： 1、为什么把认可探索式测试放在前面？为什么不是ST? 另外本句后面个人更倾向于【更强调】 2、最后一句，认可发现缺陷的价值，个人认为有点倾向于人，而后一句又是描述过程改进。以上两方面是我个人看法，请朱老师指正 。
朱少民：回复 @胖子 - 邓晓明: 好问题啊。1. 因为未知，才有探索的空间，因为需求不清楚、时间紧等各种原因，探索式测试才更有效，在一定程度上是因为软件开发本身的问题，例如我称”敏捷开发“为”探索式开发“，测试才被动应付这种局面。2. 最后一句讨论了测试的本质：是发现缺陷呢还是对产品质量的全面评估？
蔡德辉_IT 研发管理前沿：为啥就没人发一个如何保证设计本身的质量杠杠的，而不是靠测试呢？我们认可测试的价值，但出产无缺陷的产品才是我们追求的。
朱少民：回复 @蔡德辉 _IT 研发管理前沿: 有设计原则、设计模式和开发框架等，以及设计、可测试性检查等，都是在设计上预防问题的发生。
jeffsn ：多谢总结，从测试的角度提出了对产品开发的要求。 请问如何定义产品发布前的软件测试工作和用户测试工作的范畴呢？用户测试的工作是否应该有软件测试人员介入？
朱少民：回复 @jeffsn : 一般来说，系统测试工作覆盖功能测试、性能测试、安全性测试、易用性测试等工作，包括各种负面测试等。而用户测试主要针对用户环境、用户数据等进行安装 / 卸载测试、数据和系统的兼容性和安全性测试、用户需求的进一步确认（功能性测试）等，软件测试人员应该介入，和用户（代表）共同实施。
不脱不洒脱：我们现在的探索性测试为零，这是我们团队测试中的一个漏洞环节，因为我本身就认为测试必须具有系统方法和标准的流程体系。这也是我的不足，无可辩解……
朱少民：回复 @不脱不洒脱: 属于哪个行业？什么产品类型？在传统软件行业来看，探索式测试可以作为一个辅助手段。这不能算“漏洞环节”，如果发布出去的产品质量不够好，可以加强探索式测试，反过来也可以完善已有的测试用例。也不要忘记缺陷的 RCA。
评论