51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 10124|回复: 10
打印 上一主题 下一主题

[讨论] 在不规范的项目,QA如何有效的工作

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-2-27 16:22:24 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
公司现在有一些项目由于受到交付压力等情况,很多时候没有文档话的项目计划,项目组的目标就是完成几天完成项目经理的进度,整个项目压力很大,作为QA,应该如何有效的介入,有效的工作
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-3-2 18:45:37 | 只看该作者
我个人的看法是放弃测试用例的撰写,按照requirement或者specification来划分测试模块(如果连requirement都没有的话......找pdef或相关人员沟通)。之后让熟悉相关模块的测试人员负责相关测试。测试强度用时间来进行度量。同时分析BUG数量(严重性加权)/测试时间以及BUG数量/代码行数(考虑软件架构等问题)来总结产品的质量(这个对于经验要求比较高了)。比如说BUG行数/代码行数太小,说明软件里潜在的BUG可能比较多。BUG数量/测试时间应该逐步下降,当达到某一阀值得时候认为软件可以release或者go with condition.
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-3-4 16:39:00 | 只看该作者

回复 1# 的帖子

这种情况不好弄

不过最起码的需求和设计应该有吧(可能不是规范的那种,可以随意些);然后就根据这个编码了
编码阶段测试人员编写测试用例,然后执行测试,然后就ok了

其中代码评审、测试用例的编写,偶觉得不能省略掉;

这是偶个人所想,希望大家给我提出改进意见
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-3-4 17:10:21 | 只看该作者
原帖由 wangjingying 于 2/3/2009 18:45 发表
我个人的看法是放弃测试用例的撰写,按照requirement或者specification来划分测试模块(如果连requirement都没有的话......找pdef或相关人员沟通)。之后让熟悉相关模块的测试人员负责相关测试。测试强度用时间来进行 ...

我觉得用例是根本,如果连用例都没有了,如何去测试?从哪下手?
例如,PM或者leader给你一个模块,就让测试人员去测试,怎么测?测什么?如何得到预期与实际之间的比较?
也许很多人会选择按照日常使用习惯去测试,其实日常使用习惯也是用例,只不过没有被具体化而已。
个人看法,不求苟同!
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2009-3-7 15:08:07 | 只看该作者
可能我这里的QA和大家理解的不一样
我说的QA是从过程角度考虑的
我们对日外包经常会遇到这种情况,我个人的想法,就是任何一个项目,无论是什么原因,都要求制定项目过程定义,以项目过程定义为标准,QA根据过程定义进行检查,发现问题,由项目相关利益者进行判定,一个项目可以没有项目计划,但是经历几个阶段,每个阶段的输入和输出准则,如,品质目标等要明确,QA根据这些进行检查,主要关注的就是进度情况、配置管理、阶段品质分析
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2009-3-7 21:25:33 | 只看该作者
我觉得对于不规范的项目,QA的管理见解是:
1.首先要保持QA的信息是最新的,最全的。如果QA知道的信息是片面的,过时的。后续的内容就没法管理了。即使管理了也是白说。
2.其次,有相关的项目任务时间节点。在项目进度表上,我对不规范的项目,到不期望有什么正常的文件化的进度表。有时,项目经理以邮件形式提交给我。只要这个近期的细化时间和大的时间节点说明清楚了,我也认了。
3.最后,我就关心的是产品的质量。测试的bug情况和测试覆盖情况是我关心的内容。甚至,我会查看测试的检证物。


从对日QA来说,每次要提交给日方的最主要的还是各个阶段的品质分析报告。从写报告的角度来说,充足的数据是为写报告能提供有力的证据。评审的指摘数,指摘要因分析。障害得要因分析等是关键。余下的就是结合对项目产品的了解写了。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2009-3-18 13:43:45 | 只看该作者
1、明确项目经理的测试目标,和测试时间。如果项目测试的目标高,时间不够,尽量给项目经理提出,由项目经理来决定是降低测试目标?还是延长时间?还是增加测试人员。

2、理解项目的需求。通过需求文档,demo,向需求人员请教等方式尽快理解需求。

3、根据需求的理解,画出软件的功能框架图和业务流图,并且功能框架图和业务流图通过项目经理和需求人员,开发的组长的认可。

4、根据功能框架图的功能点和业务流图的逻辑,直接进行测试,等测试完成后,对本次测试的场景进行总结概括记录,为下一轮的测试做准备。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2009-3-18 14:11:27 | 只看该作者
1.活动
2.活动的过程四要素:人,技术,方法,工具
3.活动的质量要求
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2009-3-19 16:32:22 | 只看该作者
原帖由 yangxiaowen0622 于 2009-3-7 21:25 发表
我觉得对于不规范的项目,QA的管理见解是:
1.首先要保持QA的信息是最新的,最全的。如果QA知道的信息是片面的,过时的。后续的内容就没法管理了。即使管理了也是白说。
2.其次,有相关的项目任务时间节点。在项目 ...

弱弱的问一下,如何保证QA的信息是最新的?
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2009-3-19 20:32:50 | 只看该作者
邮件群发,参加项目组的会议。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2013-2-19 16:53:00 | 只看该作者
只能通过密切的沟通来进行,注重实效,忽略形式。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-5-20 22:43 , Processed in 0.084553 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表