最后一周的测试啦，看看大家对这个项目的想法，我是个QA

项目已经到尾声，产品就要发布，可是心里依然没有底，分析一下原因，总结一下。

A.项目回顾

1.项目是从原来的C/S版本转变成WEB版本；项目从头到尾都是按照USE CASE，编写程序和测试用例，总体执行应该说是有计划的；同时这个项目是按照产品的思想做的，也就是这个产品会给不同用户使用，所以配置很多，见到的产品（Build完成之后，默认配置的产品）或许只有实际功能的一半都不到

2.QA按照USE CASE以及SPRINT的安排，一个SPRINT差不多一个月一个月进行测试

3.Developer 按照USE CASE执行各个功能的实现，每个SPRINT不仅实现新功能，同时解决上一个功能的BUG

4.在新的一个SPRINT之后，QA只是验证上一轮的BUG是否已经解决，不进行全部的回归测试，而总体的BUG数量从感觉上不够的，简单的统计一下，没千行BUG数量可能只有个位数，这个只是老板曾今的统计，我也不懂这个代表的意义，只是以此和CMM的标准比较老板感觉上是不够的

5.项目持续了大概有2年左右，我是中间加入的；总体上有序的，但是由于业务复杂，QA和DEVELOPER的业务知识储备显然是不够的

B.目前要做的事情--针对最后几个版本的测试

1.这个产品的全部的REGRESSION TEST

2.所有新的BUG，新功能的测试

3.新用户导入需要做的针对配置，用户定制部分的测试，目前至少有3个客户需要这个产品

C.人力情况，以及工作的态度

1.总共有11个左右QA，这个产品主要分3个子系统，功能复杂；同时还有3个小产品

2.3个客户测试估计每周需要80个小时的工作量

3.QA基本上没有熟悉全部系统的人，都只是熟悉一个系统

4.需要在不耽误新客户导入的情况下进行完全的测试

5.组织架构是扁平的，基本都是老板看每个人，有小的Team Leader但是基本上Team Leader不会进行工作的分派，习惯的风格是如果有100个BUG要测，一个人从上往下作，一个人从下往上做，做完为止，基本没有详细的Review和对于个人测试过程中的追踪（这个指日常的Status Meeting，以及最后看绩效的时候不会考虑测试以及报告Bug的数量，还有就是个人对于系统的理解的考核）；老板主观上是相信每个人，但是实际过程中由于DEVELOPER对于BUG的逆反心理，以及确实由于需求不清楚的问题，QA只是不够，有误报BUG，或者FAIL BUG的（DEVELOPER会被REWORK的指标）最后造成不太愿意主动的报不太肯定的BUG，和测试没有提及的可能的功能（说的不太准确，但是态度上是这样的）

D.老板的要求，以及员工的反应

1.每人在后面一周时间里面每天至少加班2个小时

2.对于每个系统都需要深入的测试，但是他说没有办法保证每个人都这么做，需要我们表现出态度

3.QA不太愿意加班，以及不太愿意完全担负最后产品的质量问题，理由是USE CASE的质量不高；我只要做完我需要做的事情就可以了，如果做完为什么还要加班？

------加班没有钱而且不能调休，这也是公司的风格，会把这些事情先说清楚，但是不太说直接责任的事情，但是万一出事，似乎会有严重后果，但是却不会在平时过程中把这种义务和责任的关系看的很重，最新想到的是我要多做多少事情,所以就会有QA和DEVELOPER沟通不好的问题---题外话

由于没有具体的要求，所以我觉得最后一周的工作不一定是有效的，而且老板提出要求之后，气氛有点不好，考虑到最后一段时间可能高强度的工作，但又起不到实际的效果的时候，老板可能会最后秋后算账的问题，我不知道这么做？我的担心是，由于只是储备的不足，实际测试的时候，很多配置不会测，最后加班也是磨时间，因为如果配置不测的话，功能至少减半，按照老板的说法是，他没有办法跟踪。。。。。。。

我的想法是，

1.列出每个人要做的事情，分优先级，同时估计需要的时间

2.每半天看进度（因为不是每个人愿意帮其他人测试的），动态调配人力分配

3.测试的内容的根据的按照USE CASE写的测试用例进行测试（要分优先级）----估算人力分配情况也应该按照这个方法进行

在我看来，您所说的是一种理想的境界，维护上千个需求的自动化测试成本会非常高

Thanks.

这是个很好的经验，谢谢

我觉得你一定没有做过packaged software，不是所有的程序都是WebSite或者Tool或者Framework，手工测试对很多东西还是避不开的问题

我觉得mock1234的见识还是吓人一跳的，他说的远远超过我的理解，不过我还是觉得他说的是个很棒的境界，至少是在使用量化的方式解决问题，不过全部的量化似乎很难达到，手工测试的问题就是无法量化，就算是写了天量的测试用例，可是怎么来用这些东西量化质量呢，从代码端，直接写测试或许是个不错的方法，而且从一开始这样做，每一样的事情从一开就做好，最后才希望有不错产品。

不太清楚为什么逆反，会扣工资吗？

这个REWORK指标干啥用的，让qa如此畏惧。

每次都用随机的不同的测试数据？？？你确定你懂测试？？你确定你见过规范的测试用例文档？？
你能区分开单元测试和功能测试？或者说你认为单元测试可以完全代替功能测试？或者你是按照用例去写单元测试？
我算是被你雷着了。

没太明白？莫非你们是开发人员刚实现完成就叫测试人员进行测试？没有版本的概念么？

感觉你们首先是测试用例就写的不完整。测试用例一般和用例说明是对应的，但在产品开发过程中，测试用例也是在不断的完善的（用例说明也在完善）
你们应该有缺陷跟踪系统吧？我是做开发的，从我自身的感觉来说，如果bug不断，开发人员心情是有些烦躁（也不是怪测试人员，有一部分是挫折感导致的），如果让测试人员去提醒开发人员有什么bug，或是开发人员解决了些bug就去通知测试人员来测，这样测试人员是有很大压力的，就像你说的，有的不确定的bug都不敢报。我的想法是：应该尽量减少测试人员和开发人员直接的交流，由项目经理或组长来协调（他们自己首先应该看一下bug描述，乃至按照描述重现一下bug），有不明确的地方，开发的管理人员先去跟QA沟通，bug修改的优先级和督促修改，应该是项目经理或组长去做的。

同意pipilu的意见，很多时候QA和DEV在bug的问题上直接交流过多意义是不大的甚至会影响各自情绪的，很多时候有些QA和DEV对一个bug有不同的意见. 这个时候两个人据理力争是没有任何意义的,可能由于其他的一些因素，这个问题根本就不是他们能解决的.这个时候QA发现问题如果觉得是问题应该首先报告出去，然后每日由开发那边的Lead在defect tracking system去评判是不是一个bug或者是一个duplicated bug，定级别.

我觉得如果Bug如果发现，首先QA自己应该通过bug相关的关键字去搜寻一下近期有没有类似的bug报上，如果没有，应该第一时间抱出去，毕竟是一个风险，虽然此bug还是有可能会成为duplicated,但是到了dev那边一般来收他们更容易知道这是不是一个已知的bug,如果是直接duplicated就行了，不用在报还是不报上耽搁太多时间.

还有我想问你们公司的QA 报的FAIL BUG 多了 会怎样？扣工资？