像这种流程问题一般是在小公司提现明显，较大公司都会有健全流程和多种角色去 cover, 根本不需要测试操心，像你们应该是有项目经理，项目经理都不管理怎么指望测试去管理，但是你可以管控研发的提测，研发提测是我们测试开始的重要一环，可以通过制定研发提测标准从而让我们测试有据可查。

严格管控，严禁口头沟通（口头沟通后也会补文档和邮件），所有需求必须经过评审，所有变更均有文档记录。

你领导管理有问题吧，需求管理这么大的漏洞，他竟然不关注，你应该先给他说清楚需求管理和质量的关系，转变下他的质量管理理念。
你们这种情况，可以要求新增或者修改需求，必须邮件通知，如果没有通知，可以给缺陷分组加个列个需求变更引起。统计一下因为需求管理导致的缺陷，用数据说话。

当需求有功能变动增减，要求产品在需求单上添加备注，并跟产品沟通一下，有需求变动跟开发沟通好后，也要及时告知测试同学

我们公司需求说明书的内容会由产品通过 Axure 体现为原型，需求变更也要求同步更新原型文件

当面沟通是肯定的，但是需要补充文案，或者会议通知三方修改原型

早期快速迭代的产品最好的需求管理反而是脑图形式的测试用例，由于脑图天然的结构化，通过测试人员梳理后的场景做索引与聚合，补充历史需求文档的版本及实际页面截图与代码 CommitID 作为快速迭代的需求管理与资料存档是不错的选择，亲测有效，值得尝试

我们也是小公司，文字需求一般是在腾讯文档里，UI 在蓝湖；每次需求不完善，研发那边基本上是直接和产品使用聊天工具沟通，测试这边发现不完善就要求产品落实到文档里

业内很多现成的项目管理工具可以使用，如果管理没有流程化，那至少需要轻量级的工具去沉淀和追踪，比如产品文档管理，类似文档类的免费工具非常多，如：腾讯文档，还能协同合作；比如 API 接口归档工具：如 showdoc；都是非常轻量且极易上手的。但还是需要领导有项目内容管理的 sense，才能推进工具使用的落地。

以前公司都是再 wiki 文档管理的，有更新也有文档记录，现在的话，主要再禅道管理，但是如果有需求更新，很多其实还是 qq 沟通，记录性其实不咋好

1、首先，需求作为开发与测试并行工作的主要来源，是肯定要有沉淀的（团队之间的讨论是为了澄清需求，理解一致）。
2、至于选择用什么来沉淀，最简单的就是 word,或 excel 了，但这些文件管理有个弊端，就是没有版本的概念，每次维护更新了什么内容，主要靠人工记录（尽管也可以采用工具来比较），如果忘了记录，时间长了，很可能需求文档维护人员自己也忘了改了什么。此时，如遇某些需求项（特别是细节需求）没实现或没测试，明显给质量带来风险。
3、需求作为公司产品的重要资料，建议采用需求管理工具，如开源的 testlink 有测试需求管理工能，可用来给团队管理需求。并在上面建立与测试用例之间的追溯，这样需求变化了，有版本号，具体变了什么，内容可查看。

jira

用的是钉钉里面的项目管理，需求评审，开需求会议，设计出图，研发实施，测试，产品验收都有严格的时间节点，哪一个节点逾期了，会有提示的

项目管理用 Teambition 工具，开需求评审会，做个任务排期表，有新增内容就添加在上面，研发时间来的及就加新需求，来不及就说明确说出来，以免之后出事，自己全背锅