需求的可测试性

woza

敏捷模式中强调User Story的可测试性。我觉得在传统模式中，强调需求的可测试性也有非常大的好处。

1. 用户需求以文字性描述居多，如果需求有测试通过标准，那么开发和测试人员都可以有一个容易遵循的规则。
2. 需求有通过标准，说明开发测试以及需求分析人员都达成了共识，减少工作中的分歧。
3. 既然要研究测试通过标准，那么自然就要求QA从需求分析阶段就开始工作。我想这是所有QA都期盼的结果。
4. 如果团队无法设计出需求的通过标准，那可能是需求不够明确或者团队缺乏相关的知识。总之，大家可以在开发前就可以知道这个需求多半是无法完整实现的。

应该还有其他的好处，大家可以来讨论一下。

kf11859

首先给沙发，做广告请不要来51这样的技术网站，做广告不配坐沙发！
LZ谈的通过标准如果有固然是好的，如果没有咋办啊？尤其是在STORY里面，软件其实还没有成型，需要做单元测试的时候，需求里也并没有细化到代码该怎样去写，我们做测试的还不就是靠跟开发人员风暴一下。不过传统的测试流程里，我所经历过的项目，只要是转测试部了，都应该有个通过标准，不会含糊地就叫测试人员去测一下，也没有个目的。如果碰到了LZ所说的没有通过标准的话，我想应该由老大来仲裁一下。

woza

通过标准是大家讨论出来的。不管一开始有没有，只要开发测试需求人员能够达成一致就可以。这个标准不应该是某个人说了算的。

开发人员需要按照这个标准去做开发。如果大家不能决定通过标准，那么说明大家对这个需求还不够了解，需要重新做需求分析。

stilldeeppool

所以需求的核心就是：1.符合用户的业务需求(是符合,不是满足)
                    2.有利于自身利益

当市场人员把用户需求描述成文字时(通俗来讲这还不能叫严格意义上的用户需求,这只是需求分析人员转述了用户的话而已).
1.产品研发团队 + 市场人员 + 需求分析人员+项目负责人坐在一起
就要开始对＂需求＂进行分析,根据＂需求的核心＂来制定各种指标参数　
指标参数确定后,为了验证其正确和可行性.这个时候就需要进行需求的可行性分析
其中一部分需要测试人员的介入,通过测试来判定需求是否合理

当可行性分析结束后.修改需求指标参数.形成正式的产品功能开发指导文档
研发团队依此进行产品的架构设计.测试人员开始写测试计划.产品部门开始制定产品功能文档

而QA是在产品开发到达到QA标准的时候才提交产品功能文档给QA部门进行指标及功能检查

kf11859

原帖由 stilldeeppool 于 2009-7-10 17:41 发表
所以需求的核心就是：1.符合用户的业务需求(是符合,不是满足)
                    2.有利于自身利益

当市场人员把用户需求描述成文字时(通俗来讲这还不能叫严格意义上的用户需求,这只是需求分析人员转述了用户的 ...

理论上应该这样，同时也是希望国内软件公司能够做好项目管理的规范化，以及持续优化。很多时候，按员工的技术特点进行界面清晰的分工，是既符合公司发展，也符合人心的做法。

zhouqing0

原帖由 stilldeeppool 于 2009-7-10 17:41 发表
所以需求的核心就是：1.符合用户的业务需求(是符合,不是满足)
                    2.有利于自身利益

当市场人员把用户需求描述成文字时(通俗来讲这还不能叫严格意义上的用户需求,这只是需求分析人员转述了用户的 ...

其实我觉得这涉及到需求的描述，即形式化的描述需求，这样使得“通过”的标准更加具有可操作性。

但是从项目实践的角度来说，由于用户以及开发人员对需求都不是十分明确，很多地方都是先做一步，再看下一步，这样叠代进行的，
因此在分析需求之初，就把软件需求以及通过标准都明确出来，这是很困难的。

学术界早就提测试性设计，我觉得在需求分析之初考虑“需求通过的准则”，只会更加明确并且细化需求。

woza

如果需求通过标准搞不清楚的话，说明大家对于需求的了解不够。因此，这个需求不应该放在开发计划中。如果强行开发，会导致很多问题。

lky3

要求高的话，应该是需要细到需求规格说明书的。

bydcsgy

关注需求、产品规格说明书、UI设计、代码编写的可测试性