想办法让产品觉得只要是需要通知开发的事情，都需要通知到 QA（比如一开始就拉个大群，产品、开发、QA 都在里面）。不要觉得只有提测后才有 QA 的事。

及时更新文档这个估计推行难度比较大，而且文档版本多了之后也容易乱。

需要主动性来让测试尽早进去参与迭代，首先要确保产品文档的 svn 等目录 qa 有权限访问，产品文档更新后会提交上去。测试约定时间定期更新或者找产品下游获悉变更内容。
如果变更后，有需求不明确的，及时沟通反馈，来回几次，产品就会拉上测试一起了。
需求文档不清晰或者口头描述问题，测试可以出版本 checklist 的方式，checklist 里根据程序内容自己备注写清楚变更地方和线上版本的一个特征内容，来规避需求不明确时的漏测。

之前的公司也有这种情况，大多都是开发改完提了 bug，然后开发才说这里改了。后来我们的做法也是跟@chenhengjie123 的差不多，也是专门的需求建个群然后有需求问题都在里面讨论，除此之外只能互相提醒了。

然后对于文档的话，只能靠产品去更新了。与其等产品更新，一般我是自己做记录备忘还比等他该需求靠谱。

前面我们也碰到过这种问题，后面就是禁止产品直接向开发提需求，一切以文档为准，如有变更，需相关开发产品和测试在场评估过后才可以做，确实单纯的只依靠文档还是很难的，还是一句话多沟通

1.需求通知不到位。
qa 可以强势 一点，需求变更没有通知到 qa，qa 可以要求重新估时，甚至可以说明如果不通知 qa 可以不测

2.需求文档更新不及时。
测试以需求文档为主，文档更不更新是产品的问题，最后有问题这个锅产品来背呗

我们小公司的做法是：所有需求变动，都从一个接口人那里走，接到之后接口人会先评估，然后再和开发测试一起开会讨论，这样就避免了需求变动只有开发知道测试不知道的情况，也避免了那种 “一句话需求的情况”。

需求文档不及时这个基本上无解，我感觉不太可能做的面面俱到，我觉得只要大方向没有遗漏，小细节调整的话，在群里喊一声就好了。

1、建群讨论；
2、需求评审：
角色都应该包括，PM,DEV,QA。QA 从需求评审就应该介入

遇到类似的问题都觉得习惯了~~只是觉得很（he）棒（he）

用管理工具 Jira/Redmine + 各个环节评审

会哭的孩子有奶吃 这说明产品或者领导不重视，用点小计策

• 需求管理,看项目管理水平和团队执行力.
• 本身变更控制就需要很严格的,所以一般为了减少变更,通常采用敏捷开发方式.控制迭代版本周期.
  
• 搭建项目管理系统是必须的,这能解决大部分问题,但是前提是团队的执行力要跟上.不要指望以被通知的方式获得需求变更.所有的需求需要进入项目管理系统.
• 确认需求不应该在开发过程中,应该在需求阶段

测试过程中，QA 需要与产品不断的沟通确认需求

公司开发文化决定,楼主的角色可能左右,不过可以提提意见.

需求通知不到位：

这个属于沟通问题，问题在人，不在事。

需求文档更新不及时：

可以尝试使用在线文档，比如 wiki，这样只要有修改所有关注 page 的人第一时间都会收到通知，而且还有历史版本追踪。

当然，问题都在人，不在事。解决了人的问题，就解决了问题。

1.需求通知不到位。
这个问题我们是通过先召开需求讨论，需求评估会来解决的
2.需求文档更新不及时。
这一点我们是尽量精简团队，尽量做到一个 team 的灵活化，然后自己更新文档并通知大家（坐的很近），也会慢慢培养大家的质量意识和主动性

确实很多这种情况
你提了 bug，开发会说这个已经跟产品沟通过了，或者功能改成这样了
就很浪费时间

产品如果没有书面通知 QA 和开发，我们公司是直接扣产品绩效分数。