人的烦恼源于记性太好 忘记过去才能重新开始

发布新日志

  • 项目总结--针对当前的工作情况进行总结

    2009-07-19 20:24:12

    很久很久没有做过总结了。
    得出的最大的结论就是,人不能懒惰,要天天总结,要月月总结,并且时时刻刻进行总结。我自知还是做不到这一点,而且是差很远,个人太懒惰了。基于这个懒惰,我已经一个月没有干活了,导致的结果就是,测试部这几个月都没什么成绩,没什么作为。
     
    项目终于向上线进军了。应该还有两个月的时间。刚刚安逸的过了一个月,这个月立马就暴露出来很多很多问题,测试做的不够,开发修改程序错误太多。于是,今天的总结会,针对开发人员的问题总结了很多,但是针对测试人员,依然还是没有目标,每次都是这样,讨论着讨论着,都是以开发人员为主了,貌似没我们测试人员什么事情。吃完饭,还是和领导讨论了一下,强行要进行测试方面工作的讨论。终于给出了目前的工作方向。让我不再迷茫混乱了。至少我知道目前该做些什么了,而不是每天素手无策的等待着问题的出现。
     
    分配问题,一定要给自己留出余地,否则,重要的问题都压在自己这边,而又无暇顾及的时候,欲哭无泪。只能重新调整一下方案,以目前的工作重心来安排工作。先集中力量,然后再测试各自负责的模块。
     
    对于之前说的,当一个开发人员的同一个功能模块,反复出现问题的时候,测试和开发其实都有问题,测试不全面,程序本身写的就有问题,所有的问题其实都只是表面的,根本的流程和业务之间的关系没有理顺的话,程序的修改永远都只是停留在表面,所以,问题就像水里的木头一样,按下这头,那头又浮起来了。
     
    要抽出时间来检查一下他们测试出来的问题,以及问题的跟踪情况。发觉张的做事方式有些问题,其实还是领导发现的,平时基本上我都只管自己。其实我自己做事的方式也很有问题,只是我还没发现问题在什么地方,我想最好能跟领导之间做个交流,看看他们觉得我的问题都在什么地方。
     
    其实相处了这么久,每个开发人员容易发生什么问题,以及个人的做事方式,差不多了解了,剩下的就是根据他们的特点去关注问题。有的开发人员,修改问题容易引进新的问题,并且解决的速度慢,不催促就不干活,不去问就永远不给你回复。有的人就很自觉,交流协作都很容易,做事积极主动,效率高。测试也就有重点了。
     
    这么大的项目,三个测试人员,我还要每天负责一些乱七八糟的事情,真正测试的时间很少。尽在进行协调和讨论了。测试技术我真的是没有一点提高,咳。张呢,工作也不积极了,工作的情商也不高,要多督促。丁,新来的,积极,有热情,但是业务不熟悉,测试效率还是不高。要想这么大的项目,没有问题,是不可能的,只能是尽量少一点,但是此起彼伏的出现同一个或者类似的问题好像也是不应该的。多督促自己,多督促他们,提高工作效率!
     
  • 项目小结。针对不规范的测试。

    2008-09-09 21:03:33

    进继续教育组已经快半年了,有些疲了,慢慢的就习惯了为了工作而工作。

    个人心得体会:

    1.测试计划一定要订,不一定执行,虽然计划总是不适合,并且总是处于变化之中,还是需要计划,大的小的,都是要订一个的。

    2.不要指望开发人员能帮你进行测试,有这个想法还不如让他们做单元测试。

    3.不同的测试阶段测试的重点是不同的。在项目最开始,主要保证流程能走通。流程走通了以后再进行功能的完整测试,包括界面,一些不影响功能使用的,以及边界等方面。

    4.测试的过程中尽量多和项目经理或者开发人员交流测试的情况,有什么问题,可以让他们出出主意想想办法。往往他们总会给你提出有建设性的意见。

    5.和开发人员之间有什么矛盾,不要憋在心里,要直接交流,虽然有一些聊天或者联系的工具,还是以直接交流比较好,前提是不影响他工作的情况,以及在不频繁的情况下。(有时对一些开发人员的做法很是恼火,但是如果心里压抑着,做事就会很郁闷,所以强迫自己去和开发人员交流 。比如,有一个开发人员,把我提交的问题,全部都以不可再现的解决方式提交,我大为恼火,哪那么多不可再现的,具体情况,你具体备注一下,什么都没有标识就全部不可再现。再加上当时和他关系有点说不清楚(总感觉他对我有意见),所以那时我很郁闷,想了好久,还是决定直接和他说说,哪些是不可再现的,哪些是不属于他的功能,哪些是不需要修改的问题。和他说的时候,其他开发人员也都在,大家在一起笑笑,然后说说,事情就这么给解决了。我重新打开这些bug,他重新提交一下问题解决的方式。后来有什么不懂或者有异议的他都直接和我交流,这样大家做事又恢复了和谐。)

    6.多进行交流。无论是和开发人员,还是和测试人员。流程这东西,交流的越多你就理解的越多。有时候交流了才知道,原来他们是这么实现的,于是你就知道自己该如何设计测试。交流的时候,一定要多听听别人的想法,不能想当然,但是也要把握自己的立场。

    处理不好的问题:

    1.有些开发人员,写出来的代码质量很差,导致修改的时候,一而再,再而三的出现问题,双方都很恼火的时候,该如何解决这样的情况,还不是很有办法。一方面,要考虑他的心情,改的次数太多,他要疯了。而我,因为每次流程走不下来,也快崩溃了。所以有的时候还是尽量以开玩笑的方式对待这些,既不让自己郁闷,也不让他觉得你是故意刁难他。结果就是,他的问题改了很多遍才勉强能使用。让项目经理或者小组组长去批评他?我感觉这样适得其反。现在的年轻人,脾气都大的很。万一不爽,走人。怕怕,得罪不起。

    2.总感觉测试受开发人员的制约太严重。有的时候,明明感觉任务很紧很重,可就是力不从心。你加班的时候,开发人员不加班。流程走不下去,根本没办法。我想还是跟公司的测试以及开发的环境有关系。记得有一个贴子说是公司测试部要先进行一个预测试,通过了才提交到测试人员手里。而我们这边是测试人员直接使用开发工具把程序弄过来进行测试,根本不存在什么版本控制以及预测试的说法。这也不是我一个人能说了算的。哎。

     

     

     

Open Toolbar