51testing-wn 发表于 2014-9-15 21:56:38

XX项目回归测试回顾

XX项目回归测试回顾项目背景:应用网管软件(系统);矩阵项目管理模式;项目参与人员:a.    新功能小组开发和测试人员b.   维护小组开发人员笔者角色:测试人员、BUG管理驱动人员、回归测试驱动负责人、实验室负责人问题汇总:1.    没人愿意主动担当Master的角色;l预设的方案:指定一位主持过Scrum会议的人实施。如果一个星期以后没有志愿者,笔者来担当。l最后的方案:同预设方案l【Good, Could have done better, Improvement】- Improvementl分析:团队成员积极性不高,工作不热情。究其原因大概是因为以下这几种情况。1. 需要付出更多的时间和精力。2. 缺乏系统的理论知识, 但是纸上谈兵的大有人在,即使有实践的机会。3. 笔者认为,已经达到或者超过Master要求的能力。4. 没有什么好处。具体点的说,不会得到物质和精神上的奖励。但实际上笔者还是秉着公平公正的原则,在不同场合把积极分子的表现反应给上级。5. 抑或者是笔者没有得到大家的认同L?!2.    早会开会迟到;预设的方案:开会时,强调其重要性、严肃性最后的方案:会议上强调了重要性;Gmail 增加邮件通知;消息群到点通知;l【Good, Could have done better, Improvement】- Improvementl分析:笔者认为,从矩阵的管理模式这个角度出发,笔者和各个小组成员间没有上下级管理关系,这个是导致工作懒散的主要原因。部门小组成员的行为严重点的说,有点有恃无恐。其次,笔者也是Scrum master的初次实践者,缺少足够的时间经验。采用“结对”『见事项5讨论方案』的工作方式以后,小组成员之间的沟通不足,也不主动。3.    早会开会时常不满员;预设的方案:事前请假最后的方案:到点到位置找人l【Good, Could have done better, Improvement】- Improvementl分析:同事项2。4.    小组某成员埋怨“重复”工作:开完早会,小组成员需要自行在白板上贴上任务贴(便于跟踪小组成员领的具体任务)。在第二天开会前,需要更新测试记录。而在第二天的站立会议上又要汇报三个问题。a)    昨天你完成了哪些工作?b)    明天你打算做什么?c)    完成你的目标是否存在什么障碍?预设的方案:记录并在明日早会提出,由小组成员讨论最后的方案:不用在粘贴任务贴,不用回答昨天完成的工作。只需答复Master当日需要测试的模块和功能,既可实时了解测试的进度和方向,也避免更多的人员集中在某一个区域。l【Good, Could have done better, Improvement】- Goodl分析:小组在实践中逐渐熟悉了Scrum的工作流程和方式,对明显不合理的地方提出了想法。不过在提出这个问题的时候,几乎是以一种狂暴的方式宣泄和埋怨。不过值得可喜的是,小组大部分成员保持了一种理性的思考态度,最后以头脑风暴的方式处理好了暴风头脑的问题。5.    小组部分成员对测试的进度控制力度存有疑虑:a.          参与测试的人员随项目的变化,时有增加或者减少,是否能在规定时间内完成;b.          Testcase的数量在不断的增加:1)PM要求增加对某个功能区域的测试;2)测试过程中不断添加测试用例:主要是free test case.预设方案:白板线性图标跟踪;测试记录表格跟踪最后方案:结合“结对编程”的思想,形成这几方面要点:1)开发和测试人员之间,自由组队。每天由一位小组代表出席,提高开会的效率;2)测试过程中,如果遇到问题,小组成员可互相协助,提高工作效率;3)小组成员需在开会前沟通”问题b和问题c”;4)如遇请假小组成员需告知对方,以便及时了解和掌握人力资源;5)根据前期的历史记录,计算出每天每人需要完成的任务量,以一周的时间周期比较测试的进度。比如,历史平均记录:60;实际完成记录是:45。那这就表明任务落后。l【Good, Could have done better, Improvement】- Goodl分析:这个是本次项目一个重大的improvement,既体现了小组成员积极思考问题、献计献策,也体现了小组的群策群力的结果。6.    小组部分成员测试自己不熟悉的功能模块:看相关文档的少,直接问问题的多;预设方案:1)看文档;2)找到feature开发和测试同事咨询实际方案:同预设方案l【Good, Could have done better, Improvement】- Could have done betterl分析:有部分改观,但改观不大。积极的是始终勤快,把做好事情当成一种工作享受。在学习中成长,在成长中变得睿智。懒惰的始终懒惰,给人一种强烈的依赖性。把工作当成工作,当一天和尚撞一天钟。网上有一句关于问问题,找答案的建议。首先Baidu,Googl, 尝试根据这些线索去分析问题和查找答案,不要来不久一句“答案是什么?”。换成通俗的一句话,“自己动手,丰衣足食”。7.    小组部门成员埋怨,早会参加人多(总共14人),会议时间过长;实际会议安排时间是15分钟预设方案:结对测试。『见事项5讨论方案』实际方案:同预设方案8.    早会开会成员发言时,时有喧哗,说一些无关项目的事情;预设方案:强调其重要性、严肃性实际方案:同预设方案l【Good, Could have done better, Improvement】- Improvement分析:有部分改观,但改观不大。
欢迎板砖,提问和讨论。

kakaxi5221 发表于 2014-9-16 08:08:08

可以逐个模块划分小组人员,避免开会人员过多导致会议时间延长,导致开会中出现的一些比如喧哗和谈项目无关的事情。

51testing-wn 发表于 2014-9-16 16:37:37

kakaxi5221 发表于 2014-9-16 08:08
可以逐个模块划分小组人员,避免开会人员过多导致会议时间延长,导致开会中出现的一些比如喧哗和谈项目无关 ...

模块划分,指的是?

kakaxi5221 发表于 2014-9-16 16:46:30

51testing-wn 发表于 2014-9-16 16:37
模块划分,指的是?

将整个系统根据测试组人员拆分开,2~3中选一个对拆分模块熟悉的,作为模块组长,这样带动性比较大,我们目前就是这么做的

51testing-wn 发表于 2014-9-21 16:29:15

kakaxi5221 发表于 2014-9-16 16:46
将整个系统根据测试组人员拆分开,2~3中选一个对拆分模块熟悉的,作为模块组长,这样带动性比较大,我们 ...

大概明白你的意思了,确认几个责任人,由他们去组织模块的测试工作,具体的工作由小组长去安排和实施。小组会议的时候,由小组组长汇报进度和遇到的问题。这是一个不错的解决方案。但你有没有考虑过,可能组员不会同意。有可能会提出,简单的事情复杂化了。以前的一级会议变成了两级会议。与Scrum组织方式“快,变,组织灵活”的特点相悖。还有现在我们的组员缺少一些担当和责任感,思想也比较僵化。
页: [1]
查看完整版本: XX项目回归测试回顾