除了将自动化测试工具的基本运维工作拆解后指派给下属,还需要自己负责的测试业务内容进行拆解,从而从庞大的问题海洋中脱身。
在对业务内容进行拆分之前,工作内容非常的庞大和复杂,其中对于测试问题进展的追踪是最耗费精力的。基本的流程主要包括遍历问题,询问研发问题根因,与研发核对修复进展,和测试沟通复测计划,最后确保问题闭环。当负责的业务线数量非常庞大之后,光是遍历测试问题就会花掉非常多的时间,容易陷入碌碌无为的怪圈。
之前尝试过让测试同学负责追踪自己问题的进展,但是下属汇报的风格和质量参差不齐,不得不花时间针对汇报进行查漏补缺,结果花费的时间还比自己做的更多,后来不得不收回下放的业务。
有了之前混乱的经验教训,将问题追踪的内容定义为一张卡片,对格式做了统一规范,再次下方问题追踪的业务时,明确要求汇报时需要以卡片的形式提交。
汇报问题有了固定的模板,就意味着填写的过程中需要和研发人员进行对接。例如表格中的 “问题跟因”、“下一步进展” 往往需要研发输出。在这个过程中不仅让测试人员加强了和研发的沟通交流,还推进了问题的进展,也让测试同学了解到了更多业务中的技术细节。
汇报的卡片更新时间可以交由自动化提醒完成,每次更新卡片都会让系统更新最新的时间戳。如果系统检测到 7 天内未闭环的任务没有更新进展,会自动发出提醒,要求测试同学及时更新进展。
源源不断的卡片最终形成了测试项目管理中的问题日志,采用看板的分类形式,有利于测试项目经理迅速明确当前项目的风险。
如果将卡片的状态置为已修复,那么看板上也会有自动更新对应的状态。同时也可以直接用鼠标将卡片从 “未解决” 的区域拖动到已解决。
原先庞大的测试问题,经过了一轮过滤和筛选后,问题就会比较明确和清晰。一开始下属在上交问题卡片时难免会出现填写有误或者理解有误的情况,所以在遍历问题卡片时,也是一个很好的培训成长下属的机会,灌输自己对业务的标准和理解,从而让团队内部对问题的认识理念达成一致。
模板化思维特别适合基层的管理者,而且可以根据业务程度的不同,选择性的将业务问题的追踪下放给测试人员。
发我简历哈,我问问那边的同事
要不你发我简历,我发给深圳的同事问问,我这边是南京,所以不太清楚
应届生什么的走校招哈,社招全年都欢迎的,随时都招聘
我的天,5 年经验,15K 太低了。。。。
只有南京哈
你好,Maven 是基于 Java 的项目管理工具,建议使用 IntelliJ IDEA Community 构建你的 Java 项目:)
支持
收到
Thanks,狂师,it helpd me a lot :)