51Testing软件测试论坛
标题: XX项目回归测试回顾 [打印本页]
作者: 51testing-wn 时间: 2014-9-15 21:56
标题: XX项目回归测试回顾
XX项目回归测试回顾
项目背景：
应用网管软件（系统）；矩阵项目管理模式；
项目参与人员：
a. 新功能小组开发和测试人员
b. 维护小组开发人员
笔者角色：
测试人员、BUG管理驱动人员、回归测试驱动负责人、实验室负责人
问题汇总：
1. 没人愿意主动担当Master的角色;
l 预设的方案：指定一位主持过Scrum会议的人实施。如果一个星期以后没有志愿者，笔者来担当。
l 最后的方案：同预设方案
l 【Good, Could have done better, Improvement】- Improvement
l 分析：团队成员积极性不高，工作不热情。究其原因大概是因为以下这几种情况。1. 需要付出更多的时间和精力。2. 缺乏系统的理论知识， 但是纸上谈兵的大有人在，即使有实践的机会。3. 笔者认为，已经达到或者超过Master要求的能力。4. 没有什么好处。具体点的说，不会得到物质和精神上的奖励。但实际上笔者还是秉着公平公正的原则，在不同场合把积极分子的表现反应给上级。5. 抑或者是笔者没有得到大家的认同L?!
2. 早会开会迟到;
预设的方案：开会时，强调其重要性、严肃性
最后的方案：会议上强调了重要性；Gmail 增加邮件通知；消息群到点通知；
l 【Good, Could have done better, Improvement】- Improvement
l 分析：笔者认为，从矩阵的管理模式这个角度出发，笔者和各个小组成员间没有上下级管理关系，这个是导致工作懒散的主要原因。部门小组成员的行为严重点的说，有点有恃无恐。其次，笔者也是Scrum master的初次实践者，缺少足够的时间经验。采用“结对”『见事项5讨论方案』的工作方式以后，小组成员之间的沟通不足，也不主动。
3. 早会开会时常不满员;
预设的方案：事前请假
最后的方案：到点到位置找人
l 【Good, Could have done better, Improvement】- Improvement
l 分析：同事项2。
4. 小组某成员埋怨“重复”工作：开完早会，小组成员需要自行在白板上贴上任务贴（便于跟踪小组成员领的具体任务）。在第二天开会前，需要更新测试记录。而在第二天的站立会议上又要汇报三个问题。
a) 昨天你完成了哪些工作？
b) 明天你打算做什么？
c) 完成你的目标是否存在什么障碍？
预设的方案：记录并在明日早会提出，由小组成员讨论
最后的方案：不用在粘贴任务贴，不用回答昨天完成的工作。只需答复Master当日需要测试的模块和功能，既可实时了解测试的进度和方向，也避免更多的人员集中在某一个区域。
l 【Good, Could have done better, Improvement】- Good
l 分析：小组在实践中逐渐熟悉了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】- Good
l 分析：这个是本次项目一个重大的improvement，既体现了小组成员积极思考问题、献计献策，也体现了小组的群策群力的结果。
6. 小组部分成员测试自己不熟悉的功能模块：看相关文档的少，直接问问题的多;
预设方案：1）看文档；2）找到feature开发和测试同事咨询
实际方案：同预设方案
l 【Good, Could have done better, Improvement】- Could have done better
l 分析：有部分改观，但改观不大。积极的是始终勤快，把做好事情当成一种工作享受。在学习中成长，在成长中变得睿智。懒惰的始终懒惰，给人一种强烈的依赖性。把工作当成工作，当一天和尚撞一天钟。网上有一句关于问问题，找答案的建议。首先Baidu,Googl, 尝试根据这些线索去分析问题和查找答案，不要来不久一句“答案是什么？”。换成通俗的一句话，“自己动手，丰衣足食”。
7. 小组部门成员埋怨，早会参加人多（总共14人），会议时间过长;
实际会议安排时间是15分钟
预设方案：结对测试。『见事项5讨论方案』
实际方案：同预设方案
8. 早会开会成员发言时，时有喧哗，说一些无关项目的事情;
预设方案：强调其重要性、严肃性
实际方案：同预设方案
l 【Good, Could have done better, Improvement】- Improvement分析：有部分改观，但改观不大。
欢迎板砖，提问和讨论。
作者: kakaxi5221 时间: 2014-9-16 08:08
可以逐个模块划分小组人员，避免开会人员过多导致会议时间延长，导致开会中出现的一些比如喧哗和谈项目无关的事情。
作者: 51testing-wn 时间: 2014-9-16 16:37
模块划分，指的是？
作者: kakaxi5221 时间: 2014-9-16 16:46
将整个系统根据测试组人员拆分开，2~3中选一个对拆分模块熟悉的，作为模块组长，这样带动性比较大，我们目前就是这么做的
作者: 51testing-wn 时间: 2014-9-21 16:29
大概明白你的意思了，确认几个责任人，由他们去组织模块的测试工作，具体的工作由小组长去安排和实施。小组会议的时候，由小组组长汇报进度和遇到的问题。这是一个不错的解决方案。但你有没有考虑过，可能组员不会同意。有可能会提出，简单的事情复杂化了。以前的一级会议变成了两级会议。与Scrum组织方式“快，变，组织灵活”的特点相悖。还有现在我们的组员缺少一些担当和责任感，思想也比较僵化。
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) |
Powered by Discuz! X3.2 |