51Testing软件测试论坛

标题: 看看我的QA工作 [打印本页]

作者: lzq123335 时间: 2006-5-9 12:33
标题: 看看我的QA工作
各位达人，我从事这个行业快一年了。总觉得越是工作，疑惑越多，越发现自己的渺小。
我先说说自己情况，我们公司没有测试部门，只有SQA部门。
1.一般从产品的代码结束开始介入，即开始介入单元测试，不是像开发人员那样去做单元测试，而是检查他们提交的单元测试报告，然后按照他们的报告内容，对产品变动地方熟悉一下，同时也做测试。
2.然后等到系统测试阶段，和该产品的产品经理(他属于市场部)讨论一下系统测试阶段的事情。其实就是一封邮件过去，让他提前一个星期将测试人员落实。并要他安排的测试人员们写测试用例等等之类(我觉得这个时候写这些测试用例是否太晚了)。如果没有做，那就打电话催那位产品经理。
3.在系统测试阶段，我们SQA部门，每天早上就是来统计一下Bug数据，制成为表格给开发总经理和市场部的总经理们发送过去，让他们知道现在系统测试进行的如何。
.然后直到系统测试结束。这期间执行回归测试，使用wr来检查。

在这些阶段中，我发现一些问题和有一些感想：
1.需求来源主要是
a.在Bug记录中，产品经理可开发小组的主管们讨论一下，
b.产品经理根据客户反馈的意见，以及自己的见解。
两者综合一下，就成了下一个产品的需求。

2.需求不确定性。需求描述不清楚，开发人员根据自己的主观意志来设计。
3.做QA的人，有必要老是催促市场部们(临时的测试部门)的人该干什么了吗？总觉得老是催他们，他们都会厌烦的。谁都不想自己做事情的时候，有人在后面要你干这干那的。可是我们公司QA就是这样的。。。。一些划分职责的文档也有，那些都说清楚了，什么阶段，哪些人该干什么了，可是别人又不按照这些来做。实在是郁闷，也只好这样来做
4.在系统测试阶段，市场部的人才开始组建几个人对产品进行测试，我还没有看到他们有测试用例之类的文件，都是每天坐在那，按照自己的想法，靠对产品的熟悉程度，应用产品来发现bug。
5.做QA的人，最好是在公司呆了几年的，对公司产品很熟悉并且最好有些威望的人。不大适合刚毕业的大学生，没有工作经验，不大受重视。

整个公司的这些问题涉及到的是多部门之间的，隶属于开发部的SQA如何去改变这些问题以及不合理的现状呢？

作者: lzq123335 时间: 2006-5-9 18:15
难道没有什么意见给一下吗？

作者: luoyear 时间: 2006-5-9 18:34
hehe你是QA Tester
这里讨论的QA都是过程质量保证
所以没有人回复哈
可以发表到本站的其他测试板块去

作者: Tender 时间: 2006-5-9 19:10
把你的想法和老大说一下，看看他的反应程度。

作者: lzq123335 时间: 2006-5-10 10:47
这一切流程都是他建立的，他的想法是：我是新人，没有什么经验。所说的基本上都给我否决，我不是那种喜欢争的人。

作者: grace_hh 时间: 2006-5-10 13:24
感觉国内QA的工作有一部分就是tester和document maintain，不知道其他公司是不是这样？

作者: lzq123335 时间: 2006-5-10 15:03
是啊。这样发展,以后tester也不行，qa更不精啊。脚踏两只船的工作内容确实不妥

作者: lzq123335 时间: 2006-5-10 15:11
QA的监督，要做哪些事情

作者: yipan 时间: 2006-5-15 17:41
你们公司可真够乱的，职能不分嘛。呵呵

作者: lzq123335 时间: 2006-5-22 13:29
那你们公司如何进行呢？

作者: oric 时间: 2006-5-25 17:19
标题: QC or QA
Now many companys have the same suitation ,one part of job for QA has always been traced by QA.

作者: ilovejolly 时间: 2006-5-25 20:06
看下cmm或cmmi里对qa的介绍

作者: lzq123335 时间: 2006-5-26 08:35

原帖由 oric 于 2006-5-25 17:19 发表
Now many companys have the same suitation ,one part of job for QA has always been traced by QA.

？？

作者: springsunxixi 时间: 2006-5-26 11:17
有了职责划分，还要有一个制度，明确对于这些规范违反了如何处理，分出质量问题的轻重给不同的处罚或是扣分之类的，然后定期进行审计，并提供审计报告即可，具体的处罚执行由其他部门或领导来执行。

在国内中小软件企业中，测试也好，qa 也好，感觉都不是很正规的部门或职能，常常会成为一个无人作的工作的集中地。也常常是被领导认为是可有可无，不创造价值的部门。如果有裁员，首先就是这些人。

作者: yipan 时间: 2006-5-30 09:48
我们公司是这样划分的：
开发人员进行单元测试，专门的IT工程师进行网络集成测试，然后才到系统测试部进行系统测试。
至于QA，有专门的质量部门（公司级）做，全程介入项目开发。但是开发/测试都有相关的人员兼做QA（产品/部门），发现不符流程的问题及时提出，同时也参与项目审计。
产品经理负责整个产品，项目经理负责研发，测试经理负责测试。从需求分析阶段开始，测试就开始参与，做相关知识学习，及测试用例编写。

作者: lzq123335 时间: 2006-5-30 11:28
你们公司IT工程师是干什么的？

作者: yipan 时间: 2006-5-30 17:43
我上面说的IT工程师是指做产品的网络集成测试，测接口等，和公司里维护电脑/网络等的IT工程师不是一个概念。呵呵

作者: lzq123335 时间: 2006-5-31 09:02
好像我们公司市场部的应用工程师

作者: bjwander 时间: 2006-6-6 22:53
QA在许多方面有两个概念，公司定义不一样，有的就是过程和产品控制兼做，有的是独立分开，如果对项目要求不严格，或者项目比较小，则完全可以不分开，如果项目比较大或者需求比较复杂的情况下，建议分开，这样容易控制项目整体情况和项目生成阶段产品的质量

QA计划、偏差、报告需要根据实际项目情况根据组织级进行裁减制定，并非一成不变，但是裁减流程一定要规定清楚，这就要找出OPF

其实CMMI中各个PA都是相关的，关键看你理解的深度，^_^

作者: Xiaofei104 时间: 2006-6-12 21:58
首先，我得承认，此次事情，测试是有责任的,EBF的验证测试设计对于基本功能的测试覆盖不够

但EBF发布流程是有问题的：

EBF的测试，相对版本的测试有它的特殊性，重点
1。对用户的CR和产品重要缺陷进行验证测试，
2。保证安装EBF后，用户程序的基本功能可以正常使用，

关于基本功能验证测试，EBF的变更内容的提供就尤其重要了（对于EBF的特殊性，大部分功能是不用测试的，主要是针对性测试），测试组很多次提出，需要提供EBF的文件变更列表，即EBF安装后，会变更哪些文件，但是此列表从来就没有人提供给我们，因此我们只会评估对EBF需要修复的缺陷影响的测试面，进行验证测试

产品的变更控制体现的是“全过程测试”理念。本身在软件开发过程中，变更往往是不可避免的，变更也是造成软件风险的重要因素。在EBF测试中，测试组密切关注开发过程，跟随变更调整测试策略，有针对性测试，也会依据需求的变更及时补充和完善测试用例。但感觉我们测试还是很被动！很多的信息，我们都无法拿到！

如果发布一个EBF，没有任何变更列表，我们需要对所有的功能进行全面测试，试问，我们产品的测试成本代价会有多大？？

建议以后对于发布EBF的发布，需要提供变更内容：
1。修复的缺陷和CR（这个会提供），影响产品的文件列表（这个没有）
2。EBF的其他配套文件的变更列表（这个没有）

不过，如针对下面这个问题，
1。Build版本前，需要有EBF文件变更列表，Build EBF后，检查文件是否被正确变更
2。可以通过CompareB EBF前和EBF后的文件，并对照EBF文件更新列表说明，验证测试发现//由于列表没有，因此没有测试
3。对于基本功能验证测试，覆盖测试版本的GA QA测试流程用例，可以发现//是测试需求定义的问题

总而言之，对于以后的测试工作
我们测试过程是需要不断的持续改进的。测试组下步将会引进基于度量与分析的可持续过程改进方法。在这种方法中，对现状的度量被制度化，并作为过程改进的基础。组织可以自定义需要度量的过程数据，将收集来的数据加以分析，以找出需要改进的因素。在不断的改进中，同步的调整需要度量的过程数据，使度量与分析始终为了过程改进服务，而过程改进也包含对度量和分析的改进。
期待测试过程管理将能够不断完善，测试活动能够始终处于优化状态。

作者: railroad 时间: 2006-6-14 15:11
没有测试部门，却有QA部门，太奇怪了

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)