测试一般的工作流程是这样的：
l 参与游戏设计的讨论，预测并记录新设计可能会产生的隐患
l 得到游戏设计方案，制定测试方案，列举测试用例。等待版本发布
l 根据最终版本的更新修改测试用例，进行版本用例验证
l 对新版本进行常规测试，也就是每个版本，无论是否有修改，都会去再测试验证功能是否正确的那些用例
l 反馈测试结果，提交bug，更新测试用例，等待新版本
一个测试用例就是一个测试点，尝尝就是策划的一条更新记录。将一个版本的内容细分成一个个小的测试用例点，是主测试的主要工作。主测试就是通过管理跟踪这些用例点的状态来了解测试情况的。
由于测试可分为白盒测试于黑河测试两种。因此当我们提供给测试新的功能或者更新清单的时候，不仅说明修改前后的区别，还需要给出修改后的新数据。前者用于黑盒测试，只从结果去验证；后者用于白盒测试，通过观察对比数据，寻找可能出现的问题。
从立场上来说，测试在接收到一个新版本的时候，应该是一个对游戏一点都不了解的状态，因此，每次给测试提出新功能或更新时，要尽量说明清楚，即使一个对游戏什么都不了解的人也能看懂的最好了。这时候对于策划来说，经常出现改起来很容易，说明改了什么很困难的情况。于是，很多策划在提新功能和更新说明的时候，尝尝省略、忽略一些内容。这会导致测试无法正确掌握信息，到头来还是会提很多奇怪的bug或者无法测试，引发更多的工作量。因此，策划在工作时，应该时刻记录，哪怕花费比制作还要多出一倍的时间在记录这些制作内容上，也是值得的。只要做到这点，与测试合作将会非常容易和高效。
当我们自己玩游戏发现问题的时候，应该先报告给测试进行复现验证，形成新的bug。这样每次的问题修改都会留有记录，如果是自己偷偷的修改掉了，其连锁引发的问题，可能会被自己忽略。留下bug记录的话，能减少这种情况的发生，至少再发现问题是有据可查的。
作为主管，应该向测试提供功能的负责人表，什么东西是哪个人负责的。这样方便测试在测试过程中及时进行沟通。