看看我的QA工作

lzq123335

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


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

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


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

lzq123335

难道没有什么意见给一下吗？

luoyear

hehe你是QA Tester
这里讨论的QA都是过程质量保证
所以没有人回复哈
可以发表到本站的其他测试板块去

Tender

把你的想法和老大说一下，看看他的反应程度。

lzq123335

这一切流程都是他建立的，他的想法是：我是新人，没有什么经验。所说的基本上都给我否决，我不是那种喜欢争的人。

grace_hh

感觉国内QA的工作有一部分就是tester和document maintain，不知道其他公司是不是这样？

lzq123335

是啊。这样发展,以后tester也不行，qa更不精啊。脚踏两只船的工作内容确实不妥

lzq123335

QA的监督，要做哪些事情

yipan

你们公司可真够乱的，职能不分嘛。呵呵

lzq123335

那你们公司如何进行呢？

oric

Now many companys have the same suitation ,one part of job for QA has always been traced by QA.

ilovejolly

看下cmm或cmmi里对qa的介绍

lzq123335

原帖由 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

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

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

yipan

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

lzq123335

你们公司IT工程师是干什么的？

yipan

我上面说的IT工程师是指做产品的网络集成测试，测接口等，和公司里维护电脑/网络等的IT工程师不是一个概念。呵呵

lzq123335

好像我们公司市场部的应用工程师

bjwander

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

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

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

Xiaofei104

首先，我得承认，此次事情，测试是有责任的,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测试流程用例，可以发现//是测试需求定义的问题


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