宜昌建站刷排名有百度手机刷排名
本周四中午，亮亮拉着我和琦琦一起说了下SRM项目的情况。
财务侧反馈，因为预算模块BUG较多，不具备UAT测试的条件，所以暂停测试了。问题较多，在前一天财务系统接口人也给我反馈了，让我关注下，我只是没料到事情一下子就变得这么困难和不可收拾了。
3人的小会中，亮亮表示，这个延误并不会影响到项目整体计划，财务后续可以随着更大范围的UAT一起继续测试。针对这个情况，再考虑到如下几点
-
后续有更大规模，几百人的UAT
-
产品模块太多，外采、自研之间的接口也非常复杂，上线前后也会面临大量的回归测试
-
目前还没有自动化测试Case，琦琦准备集中在2天把自动化做出来，但也存在很大风险
我觉得组织层面必须做点什么给团队以支持了。团队当前的测试资源太少，只有琦琦一个人，还兼岗了部分产品工作，我就想是否可以引入一个外包测试资源短时间支持下。
说干就干，和我的Leader以及采购负责人沟通后，认为很有可行性，虽然Leader让我再慎重考虑下，但我还是坚持推进这个事情。
但是，有点意外，在听到这个声音后，琦琦给我私信，说当前阶段不建议加入一个外包。我马上拉了亮亮和琦琦快速碰头对齐下。
琦琦的主要观点，系统比较复杂，新来的人难以快速进入状态，还需要额外投入时间来培养；亮亮也表示了类似的观点。我稍显奇怪，因为如果测试Case或产品文档比较齐备的话，这个问题应该不存在。但亮亮和琦琦表示，产品文档不是最新的、测试Case的颗粒度不够细致。而且，琦琦认为，只要自己的自动化脚本能顺利完成并跑起来，就能够比较好地解决资源不足的问题。
我还是认为，有个测试能投入到工作中，还是可以帮助我们做很多常规的测试任务的。很多复杂场景短时间难以掌握，但标准路径、上线回归等也需要有人来做，这样就能解放亮亮和琦琦做更多、更重要的事情，我们的产品经理花很多时间来做测试，我也很痛心。
琦琦仍然坚持了自己的观点，亮亮看来被我说服了，表示同意，这样3个人表决2比1通过，我继续去推动这个事情，琦琦也接受了这个结果。
其实我可以自己决定，但我觉得，经过充分讨论后，事情的推进会更顺利、工作也更容易开展，毕竟加入的测试同学是需要亮亮和琦琦来带领工作的。通过充分讨论，给予团队同学更多的尊重和参与感，对于大家共同的决策，会更有执行力。