我的任务是将我的团队的重点从“可以做任何事情”的团队转变为更面向服务的团队,即我们可以为您的测试提供框架,而不是在那里执行实际测试。这种关注点的改变是为了支持内部交付团队。
我要问的是以前有没有人遇到过这种情况,他们能否传递任何建议或文章链接,为我指明正确的方向。
谢谢,
史蒂夫。
我的任务是将我的团队的重点从“可以做任何事情”的团队转变为更面向服务的团队,即我们可以为您的测试提供框架,而不是在那里执行实际测试。这种关注点的改变是为了支持内部交付团队。
我要问的是以前有没有人遇到过这种情况,他们能否传递任何建议或文章链接,为我指明正确的方向。
谢谢,
史蒂夫。
我曾作为测试人员在团队中工作,并作为工具开发人员在团队中工作。斯图尔特谈到了过渡,所以我不会谈论更多,但我认为我可以添加一些有用的信息,说明您可以期待什么以及您在新角色中可以关注什么。
您将成为一个开发团队,为真正的客户生产产品。您越早意识到这一点并开始像真正的产品团队一样行事,这对您的客户来说就越容易。确保将工具视为产品,制定修复和部署这些工具的计划,为这些工具创建高质量的文档(如果还没有)——决定如何处理支持。不要低估修复错误所花费的支持成本和时间,即使只有少数客户,它最终也会占用您的大量时间,尤其是在您没有围绕它的流程的情况下。如果您有多个团队成员,您甚至可以考虑让其中一个“在点”或 1 层一次提供一周的支持,以避免随机分配人员并允许他们进行正常工作。
准备好说不,并证明你的优先事项是合理的。既然您有多个客户,他们将有自己的议程,并将推动解决他们的高影响问题。解决此问题的一个好方法是让您的每个客户团队的代表定期开会并参与规划过程,为您提供反馈并将您团队的信息带回各自的团队。这将使他们能够就您的团队应该关注的错误和功能达成共识。
最后,很容易陷入一种模式,在这种模式下,您可以为客户想要的一切创建工具,而在您知道它之前,您正在遭受功能膨胀的困扰。你有一堆不连贯的工具可以做“一切”,但它们令人困惑、难以找到、难以弄清楚等。你的团队需要对质量保持坚定。与真正的产品团队一样,您的团队最好创建和维护一些非常有效的编写和维护的工具,而不是拥有一堆编写和维护不佳的“快速修复”工具。
希望这是有用的信息。祝你好运 :-)。
我认为将您从实际执行的测试中移除将很重要。您需要确保测试标准不会随着团队的撤离而下降。
交出测试执行过程并传递经验需要时间。您可能希望逐步逐一移除您的团队并监控测试水平。当您准备好从您要移交给的团队和团队成员的反馈中移除更多团队成员时,您会有所感觉。
请记住,您将从测试执行过程中删除经验,这将需要时间让任何将执行您的测试的人获得该经验。