本次考核来得比较突然,也来得比预期的早得多,可以说是猜中了开头,没想到结尾.

被考核后总体而言是失败的,也暴露出相当多的问题.除去专业知识及技能考虑,这些暴露出来的问题中很大一部分其实是我们不愿做或者没有形成习惯导致.
实际上从本次考核内容来看,真正测试专业性的东西比较少,或者根本就不会深入,考核的更多的是平常工作中的积累,业务知识积累,劳动成果积累,测试思路积累及处事方法积累.
有积累就需要展示,除了口述我们的处事行为,方法,更多的我们需要出示让人看得见的东西,那便是文档+案例,而这些可以说我们中间没几个人是做得足够的,希望大家从今往后自己主动收集,有序整理,我们需要养成这种工作习惯.这些工作可能会增加我们的工作量,但对团队,对个人都是有益无害的事情,初期可能需要新建或者制作,请大家克服当前,想想我们的qc上相关东西,现在和半年前相比,效果已经体现出来了,等完善后修改起来就应该就不像现在这般困难.
这次我大略总结,我们严重不足的并且可以做的有以下几点:

编写测试计划

虽然当前我们所谓的测试用例相比半年前已经有了很大的进步,但大家应该都很清楚,那些东西是经不起检验的.
有空大家翻出自己写的测试用例看看,也许自己都看不懂.当初为什么这样写,这样写的目的是什么,照这个测试用例去执行是否能执行下去?我们很多任意操作描述和留空白是没有差别的,最好我们能写上具体需要鼠标键盘操作什么,竞争对手要做什么.这也是个长期的过程.
由于流量产品线的特殊性,我们写的东西基本上没人能帮忙审阅,也没有时间给咱组织评审,在测试用例编写或者完善过程中我们可以征求研发意见,并体现在测试用例中,这个也是考核的内容之一.

测试总结/缺陷分析

这块我们几乎是没有做,甚至是发生事故之后也没有进行总结过,责任首先在我,但我们还是有必要着手做.

起步阶段我们可以在做完一个项目后将缺陷总结归类下,回头看看这些发现的缺陷是怎么发现的,有多少不是通过执行明确的测试用例发现的,为什么没有写进测试用例?缺陷都集中在什么地方,什么操作容易导致问题?

总结后预期结果应该是再次审视我们的测试用例时能够发现用例不曾覆盖的部分并使测试用例越来越完善.测试过程中能够针对以往缺陷集中的地方更加关注,更加详尽进行测试.

缺陷反馈/项目进度通报

此工作我们偶尔做,但还做得不够.不要求每天做,但当出现影响项目进度缺陷时我们需要让运营让领导知道,毕竟出现这些事件时会让测试工作量陡增甚至翻倍,最后项目延期运营还有点不乐意.

从今日做起,有缺陷有可能导致项目延期的事件请通过文档,通过邮件反馈出来,有项目完成而运营无安排时一样的通过邮件告知测试完成并提供测试报告.

文档积累

我们都做了不少事情,但我们甚至拿不出证据,有时连自己都想不起来,这就是问题,因为自己没有记录.

所以,大家做了就记录吧,最好都是电子文档或者邮件,有一天会用得到,别人也可以用得到.

测试工具

这个就不多说了,大家都知道纯手工测试是没前途的.在没办法不做测试前大家还是慢慢开始学吧,搞通了能用于现在的插件测试最好,一点用不上也没关系,学到的东西是自己的.

就这么多吧,大家对我们当前的工作有什么想法或者对我们现在的小团队有什么想法和建议可以提议讨论下.