目前公司在需求管理上，基本是最开始一个小的需求规格说明书，在过程中，不断新增或变更的需求，再也不更新，基本上之前那个需求说明书最后都没什么用了，需求都变了。开发的软件多为项目类，toB 型。
很多的需求，都是跟负责编码的开发人员口头传达一下，测试人员到提测时都还不知道需求。
有些需求/设计评审或讨论，也是小范围项目负责人跟开发沟通下，也不记录，更没有文档。
测试人员的要求是，没有需求规格书也可以，至少有个地方有些记录，哪怕 excel 简要说明也可以；没有评审也可以，至少拉着测试人员一起沟通。
反馈后，领导的意思是，测试按照需求规格书来测，太理想化了，没有哪个公司能做到需求管控的那么好。他不是很关注需求，更关注是软件有没有编写完成。
请问大家的公司，需求不需要严格管控么？可以只是口头沟通（只跟某个开发沟通），然后也没有记录么？提测时，测试人员没啥测试依据，只能测试时熟悉系统。
软件测试培训机构排名文章源自玩技e族-https://www.playezu.com/186816.html 文章源自玩技e族-https://www.playezu.com/186816.html
玩技站长微信
添加好友自动发送入群邀请
rainbow-shownow
玩技官方公众号
官方微信公众号
PLAYEZU
未知地区 1F
像这种流程问题一般是在小公司提现明显，较大公司都会有健全流程和多种角色去 cover, 根本不需要测试操心，像你们应该是有项目经理，项目经理都不管理怎么指望测试去管理，但是你可以管控研发的提测，研发提测是我们测试开始的重要一环，可以通过制定研发提测标准从而让我们测试有据可查。严格管控，严禁口头沟通（口头沟通后也会补文档和邮件），所有需求必须经过评审，所有变更均有文档记录。
你领导管理有问题吧，需求管理这么大的漏洞，他竟然不关注，你应该先给他说清楚需求管理和质量的关系，转变下他的质量管理理念。
你们这种情况，可以要求新增或者修改需求，必须邮件通知，如果没有通知，可以给缺陷分组加个列个需求变更引起。统计一下因为需求管理导致的缺陷，用数据说话。当需求有功能变动增减，要求产品在需求单上添加备注，并跟产品沟通一下，有需求变动跟开发沟通好后，也要及时告知测试同学我们公司需求说明书的内容会由产品通过 Axure 体现为原型，需求变更也要求同步更新原型文件当面沟通是肯定的，但是需要补充文案，或者会议通知三方修改原型早期快速迭代的产品最好的需求管理反而是脑图形式的测试用例，由于脑图天然的结构化，通过测试人员梳理后的场景做索引与聚合，补充历史需求文档的版本及实际页面截图与代码 CommitID 作为快速迭代的需求管理与资料存档是不错的选择，亲测有效，值得尝试我们也是小公司，文字需求一般是在腾讯文档里，UI 在蓝湖；每次需求不完善，研发那边基本上是直接和产品使用聊天工具沟通，测试这边发现不完善就要求产品落实到文档里业内很多现成的项目管理工具可以使用，如果管理没有流程化，那至少需要轻量级的工具去沉淀和追踪，比如产品文档管理，类似文档类的免费工具非常多，如：腾讯文档，还能协同合作；比如 API 接口归档工具：如 showdoc；都是非常轻量且极易上手的。但还是需要领导有项目内容管理的 sense，才能推进工具使用的落地。以前公司都是再 wiki 文档管理的，有更新也有文档记录，现在的话，主要再禅道管理，但是如果有需求更新，很多其实还是 qq 沟通，记录性其实不咋好1、首先，需求作为开发与测试并行工作的主要来源，是肯定要有沉淀的（团队之间的讨论是为了澄清需求，理解一致）。
2、至于选择用什么来沉淀，最简单的就是 word,或 excel 了，但这些文件管理有个弊端，就是没有版本的概念，每次维护更新了什么内容，主要靠人工记录（尽管也可以采用工具来比较），如果忘了记录，时间长了，很可能需求文档维护人员自己也忘了改了什么。此时，如遇某些需求项（特别是细节需求）没实现或没测试，明显给质量带来风险。
3、需求作为公司产品的重要资料，建议采用需求管理工具，如开源的 testlink 有测试需求管理工能，可用来给团队管理需求。并在上面建立与测试用例之间的追溯，这样需求变化了，有版本号，具体变了什么，内容可查看。jira 用的是钉钉里面的项目管理，需求评审，开需求会议，设计出图，研发实施，测试，产品验收都有严格的时间节点，哪一个节点逾期了，会有提示的项目管理用 Teambition 工具，开需求评审会，做个任务排期表，有新增内容就添加在上面，研发时间来的及就加新需求，来不及就说明确说出来，以免之后出事，自己全背锅