在不规范的项目，QA如何有效的工作
公司现在有一些项目由于受到交付压力等情况，很多时候没有文档话的项目计划，项目组的目标就是完成几天完成项目经理的进度，整个项目压力很大，作为QA，应该如何有效的介入，有效的工作 我个人的看法是放弃测试用例的撰写，按照requirement或者specification来划分测试模块（如果连requirement都没有的话......找pdef或相关人员沟通）。之后让熟悉相关模块的测试人员负责相关测试。测试强度用时间来进行度量。同时分析BUG数量（严重性加权）/测试时间以及BUG数量/代码行数（考虑软件架构等问题）来总结产品的质量（这个对于经验要求比较高了）。比如说BUG行数/代码行数太小，说明软件里潜在的BUG可能比较多。BUG数量/测试时间应该逐步下降，当达到某一阀值得时候认为软件可以release或者go with condition.回复 1# 的帖子
这种情况不好弄不过最起码的需求和设计应该有吧（可能不是规范的那种，可以随意些）；然后就根据这个编码了
编码阶段测试人员编写测试用例，然后执行测试，然后就ok了
其中代码评审、测试用例的编写，偶觉得不能省略掉；
这是偶个人所想，希望大家给我提出改进意见 原帖由 wangjingying 于 2/3/2009 18:45 发表 http://bbs.51testing.com/images/common/back.gif
我个人的看法是放弃测试用例的撰写，按照requirement或者specification来划分测试模块（如果连requirement都没有的话......找pdef或相关人员沟通）。之后让熟悉相关模块的测试人员负责相关测试。测试强度用时间来进行 ...
我觉得用例是根本，如果连用例都没有了，如何去测试？从哪下手？
例如，PM或者leader给你一个模块，就让测试人员去测试，怎么测？测什么？如何得到预期与实际之间的比较？
也许很多人会选择按照日常使用习惯去测试，其实日常使用习惯也是用例，只不过没有被具体化而已。
个人看法，不求苟同！ 可能我这里的QA和大家理解的不一样
我说的QA是从过程角度考虑的
我们对日外包经常会遇到这种情况，我个人的想法，就是任何一个项目，无论是什么原因，都要求制定项目过程定义，以项目过程定义为标准，QA根据过程定义进行检查，发现问题，由项目相关利益者进行判定，一个项目可以没有项目计划，但是经历几个阶段，每个阶段的输入和输出准则，如，品质目标等要明确，QA根据这些进行检查，主要关注的就是进度情况、配置管理、阶段品质分析 我觉得对于不规范的项目，QA的管理见解是：
1.首先要保持QA的信息是最新的，最全的。如果QA知道的信息是片面的，过时的。后续的内容就没法管理了。即使管理了也是白说。
2.其次，有相关的项目任务时间节点。在项目进度表上，我对不规范的项目，到不期望有什么正常的文件化的进度表。有时，项目经理以邮件形式提交给我。只要这个近期的细化时间和大的时间节点说明清楚了，我也认了。
3.最后，我就关心的是产品的质量。测试的bug情况和测试覆盖情况是我关心的内容。甚至，我会查看测试的检证物。
从对日QA来说，每次要提交给日方的最主要的还是各个阶段的品质分析报告。从写报告的角度来说，充足的数据是为写报告能提供有力的证据。评审的指摘数，指摘要因分析。障害得要因分析等是关键。余下的就是结合对项目产品的了解写了。 1、明确项目经理的测试目标，和测试时间。如果项目测试的目标高，时间不够，尽量给项目经理提出，由项目经理来决定是降低测试目标？还是延长时间？还是增加测试人员。
2、理解项目的需求。通过需求文档，demo，向需求人员请教等方式尽快理解需求。
3、根据需求的理解，画出软件的功能框架图和业务流图，并且功能框架图和业务流图通过项目经理和需求人员，开发的组长的认可。
4、根据功能框架图的功能点和业务流图的逻辑，直接进行测试，等测试完成后，对本次测试的场景进行总结概括记录，为下一轮的测试做准备。 1.活动
2.活动的过程四要素：人，技术，方法，工具
3.活动的质量要求 原帖由 yangxiaowen0622 于 2009-3-7 21:25 发表 http://bbs.51testing.com/images/common/back.gif
我觉得对于不规范的项目，QA的管理见解是：
1.首先要保持QA的信息是最新的，最全的。如果QA知道的信息是片面的，过时的。后续的内容就没法管理了。即使管理了也是白说。
2.其次，有相关的项目任务时间节点。在项目 ...
弱弱的问一下，如何保证QA的信息是最新的？ 邮件群发，参加项目组的会议。 只能通过密切的沟通来进行，注重实效，忽略形式。
页:
[1]
