郁闷的bug管理

以前的公司是个外包公司，也许就是因为外包测试的缘故，测试流程比大公司却要规范很多。

别的都不说了，只说bug管理，说起来别是一番郁闷！

上一个项目还好一点，但是与BYS相比，那就是一个字：乱！这个项目本来指望会改进一点，毕竟经验都是慢慢攒起来的，总是会进步。而现在，接踵而来的bug，更是让人眼花缭乱，这些bug几乎是处于无人管状态。要知道，bug是项目最后评估的一个主要的衡量标准啊！老大对我们只是一味的要求bug的数量，而不管其质量，每天追着我们要bug。这样难免造成有时候为了交差而去提一些自己也不确定的bug，至于它是有效或是无效，那我就不管了，反正我今天提了5个bug，已经很不错了（虽然这种想法对于测试人员很要不得，但是在这种压力下，有时候也是一种对策）。于是乎，每天都有十几几十个新的bug加入到bug database中，至于有没有效，有无duplicate，无人问津，老大不管，就没人去管。

众所周之，bug是有生命周期的。从一开始的new到open,resolve到最后的close,每一个状态都是相应的负责人员去修改的。从这些状态中，我们每一个测试人员，开发人员以及项目管理人员都能够清楚的知道这个bug现在的状况，从而更好的有针对性的去跟踪进而去解决。然而，我们的bug，提上去了，就一直是new状态，没人去管（老大也许会看几眼吧）。等到一个新的build来了，解了一些问题，于是，leader把所有new的全改成open，再为了去verify一些解决的bug，而把那些相应改成resolve好让我们去reopen或是close。无语啊，那个无语啊。。。

每次verify bug的时候真的是很头疼。一张buglist，每个人去verify自己的bug，这样还会好一点。这次不知道怎么了，咵一下leader给我们一张excel表，是所有bug列表。我一看头都大了，所有的new，open，duplicate，close的bug全在那里。丢下一句话，把所有severity为A和B的new和open的都验证一下，不管有没有解决。这样要浪费多少时间啊？没有release note，也许有，可是我们从没见过。没有针对性，盲目去做，效率必然大打折扣。

verify之后，leader又说了，你们在CS（我们的bug database）上把你们verify的bug状态都改一下吧，我把状态都改了。我一看，果然都改了，所有new和open的都改成resolve了。我傻眼了，约莫有200多个吧，我们四个人去做。

我也曾经尝试着和老大说过我的想法，说说我的想法，表面上老大是点头说确实是这样，是得改进，但是实际上却没有效果。也许我的话没有什么价值，既然这样，那就算了吧，我又何苦去自讨没趣呢！

只是觉得这样做下去，没有意义，没有激情，没有斗志了。。。