3．测试人员第一件事做什么？

答案：打开Raid/BMS，查看指定给自己的Bug，验证已解决的Bug。

接下来，测试人员会…

    根据测试用例检验的Build
    在Raid/BMS中记录新发现的Bug

4．专家会诊

    参加者：项目经理和开发组长、测试组长
    通过Raid/BMS评估每个未解决的Bug
        决定Bug优先度
        可否等到下个里程碑或版本解决？
        谁来解决
    预测项目实际进度和发布时间

缺陷走势图

5．回顾微软的

    构造: daily build
    开发: 解决blocking bugs， 实现功能， check-out， code review， check-in
    测试: BVT， 使用测试用例进行测试
    项目经理/组长: 专家会诊

6．微软的做法解决了那些常见问题？

质量问题

    以前解决过的问题发布时又出现了，需要返工
    无法预估发布时间 过早发布，带来质量和维护问题
    测试发现的问题被忘却或不了了之
    无法衡量测试员和开发员的工作
    程序中的问题往往在发布后才发现

文档管理问题

    文档与程序脱节，文档成为程序结果的描述
    项目组把写文档看成负担

团队协调问题

    开发人员各自为战，进行整合时发现模块衔接中的严重问题 需要作大的改动
    没有保管好公司以往的版本和代码，无法满足用户对旧版本的更改要求
    开发人员离职对项目带来很大冲击，没有人知道代码在哪，或无法读懂

五．提高软件管理的步骤

1. 使用Raid/BMS，将流程管理自动化
2. 使用测试用例管理工具
3. 使用文档管理工具
4. 使用版本控制工具，进行Daily Build
5. 建立代码标准
6. 建立Code Review机制
7. 建立专家会诊机制
8. 建立团队沟通机制
9. 根据需要调整团队结构