[如需转载，请在转载时注明出处，并保证本文的完整性]
拿到需求规格后，还应该要做的事
以自己理解的方式，与需求负责人或项目经理再进行一次确认(Validation)，确保开发出来的软体符合客户(或规范)的需求
2、软体QA的V&V落实：（make sure）
Validation(确认)：确认工作产品符合客户的需求(do the right thing)
Review（或评审手段）
Verification(验证)：使工作产品符合设计上的品质(do the thing right)
Testing（或测试手段）
作对的事比把事情作对更重要
do the right thing rather than do the things right
3、做事情要想想做的目的，而不是仅仅去做自己的事（how to do）
始终告诉自己是产品的质量人员，目标是使得品质持续改进。而不仅仅是个用例执行者或缺陷的记录者。
以上仅是个人经验所整理出来的一些建议之谈，描述直白，仅供参考
王小丽 2010-05-14
补充一点：找出一些潜在的需求，把这些需求列出来，然后进行确认，减少后期的麻烦
金鑫 2010-05-14
王小丽 2010-05-14
金鑫 2010-05-14
李琴 2010-05-14
我们测试在需求阶段投入很多，拿到需求文档需要仔细查看，有一次我的项目就找了几十个需求问题。 一些是需求方写错了，一些是需求方不知道的潜在规则，一些是站在用户角度建议修改的。 总之拿到需求直接测试肯定上线后很多BUG
李超 2010-05-15
需求评审：
1.第一步肯定是测试人员自己看客户的SRS，从中找出问题，并上报给PM，由PM与客户确认
2.PM会首先跟开发人员作需求的review工作，将发现的问题与客户沟通
3.PM给测试组讲解需求，业务，此时测试人员再次提交确认需求中的细节问题，提出后由PM与客户确认
4.同开发负责人（大项目下一般分多个开发小组，每个小组有自己的组长）讲解其负责的模块需求及业务，与上一步基本相同，不过由于讲解人不同，他们的理解可能也有所不同，这时也可能发现些问题，同样这些问题会反馈到客户确认
5.测试组的check list review，由测试人员讲解需求及业务，并讲解其中的测试点，开发人员同样要听，若遇上与开发理解不一致开发会提出来，这些问题同样可能反馈给客户确认。
6.之后开发人员就可以开始设计，测试组的设计工作也要开展服，测试计划，测试用例。。。这些东西都是需要评审的。。。
不管这个模块是不是你需要测试的都需要去听，毕竟同一个系统内部的一些接口是少不了的，多听听没有坏处，你也有发言的权力。
马嘉鑫 2010-05-15
要找一些有深度的bug，确实要自己往深了想，考虑更多的方面，有些东西往往是需求没有写出来的，只有测试过程中实际操作了，才会发现原来还有这样的问题
楮迎春 2010-05-24
楼主所说的与需求测试有些相似。
谭明 2010-06-23
恩，值得参考
曹垒 2010-08-24
我们公司最麻烦，拿到需求先测试需求，然后根据需求写网格，再根据网格写用例，为的就是方便追踪和完善需求变更吧，感觉业务分析这一块还是蛮重要的
杨森 2010-08-24
高人指路
金鑫 2010-08-24
曹垒 2010-08-25
金鑫 2010-08-25
