新鲜的测试工作规范及评估标准
刚制定的测试部门工作规范及评估标准，各位同仁帮忙看下有哪些不适合的地方。本没有学过测试，但已经做过了几年的测试管理，凭着经验写的，欢迎大家拍砖 支持一下。 看看先 测试在集成之后就结束了？个人看来，集成和系统测试两个的侧重点还是有一点点区别的。此外测试计划的制定应该让项目经理参与进来。让测试负责人和项目经理共同编写，有利于为测试团队赢得时间等资源上面的优势。此外，单元测试和集成测试，测试人员参与的程度很高，这要求测试人员拥有很高的编码能力和丰富的集成测试经验，而且对需求和设计的文档要求非常高。各个公司的人员能力不同，看实际情况而定。
此外，文档的管理加个编号吧，方便你们管理的。
个人见解，不负法律责任，哈哈。 用户手册由测试人员编写有利有弊。个人感觉弊大于利。主要考虑测试人员对系统整体的把握不一定非常OK，而且用户手册的编写有很多文字的东西，可以考虑安排个专门的写手。
评估标准中对于完成质量的好坏如何判断？这一块应该不怎么好评判。依靠Defects流失率，还是依靠其它的什么。我感觉缺少量化的标准。 原帖由 caine 于 2010-6-2 11:22 发表 http://bbs.51testing.com/images/common/back.gif
测试在集成之后就结束了？个人看来，集成和系统测试两个的侧重点还是有一点点区别的。此外测试计划的制定应该让项目经理参与进来。让测试负责人和项目经理共同编写，有利于为测试团队赢得时间等资源上面的优势。
此 ...
是的，目前是在集成测试之后就结束了，当然过程中穿插无数次的回归测试。
另外，测试计划是由项目经理评审的，所以也适当参与了一些。
单元测试其实是指模块测试，不涉及开发的。涉及编码的单元测试由开发人员自行测试
谢谢你的意见，欢迎再次讨论
[ 本帖最后由 wcp_856 于 2010-6-3 10:50 编辑 ] 原帖由 caine 于 2010-6-2 11:31 发表 http://bbs.51testing.com/images/common/back.gif
用户手册由测试人员编写有利有弊。个人感觉弊大于利。主要考虑测试人员对系统整体的把握不一定非常OK，而且用户手册的编写有很多文字的东西，可以考虑安排个专门的写手。
评估标准中对于完成质量的好坏如何判断？这 ...
我个人认为用户手册还是由测试人员来写比较合适，测试人员应该对整个系统比开发人员要熟悉的全面，我们有内部的文档审核员，但不负责文档编写，只负责审核
评估标准中我觉得太量化的东西容易误导，所以我现在努力完善这个标准向不太量化的方向发展，希望能够充分调动积极性。
谢谢你的意见~ hi，再多嘴几句哈。
如果标准不能够被量化，我个人认为不要使用。模糊的东西会让人很难去操作，受执行者的个人感觉影响较大。而且结果出来后，也很难有说服力。一定程度上会降低标准的威信力。不知道这个评估标准执行后会不会有money上的奖励。如果有的话更要注意不要搞模糊的东西。 谢谢 谢谢！ 不错不错，下载研究一下 看看先.................. hi，再多嘴几句哈。
如果标准不能够被量化，我个人认为不要使用。模糊的东西会让人很难去操作，受执行者的 ...
caine 发表于 2010-6-3 13:52 http://bbs.51testing.com/images/common/back.gif
嗯嗯，确实太模糊的东西给人不真实的感觉
量化的东西体现在绩效评估中了，制度和规范中没有体现 本帖最后由 archonwang 于 2010-9-28 15:28 编辑
粗看了下，方向方面比较明确，需要从整个工程角度考虑测试方面的相关工作，但是从规范上看，具体实施方面可能存在难度，着眼于相关项目测试经理的个人能力。
尤其要注意对测试工作成果的体现。
规范上需要体现的是各项工作的操作细则、交付内容说明及对应的处理规则，汇报机制以及评审和相关审核。
有点乱，参考。 还是不错的 谢谢分享 下了看看 看看先... 看看先... 做为部门体系文档，首先文档模板不够规范，如，页眉缺少公司logo,缺少流程图，角色
其次，缺少量化的质量目标和方针
建议楼主学习下cmmi，会有帮助的
页:
[1]
