编写背景:
5
月份测试的一个项目由于需求变更频繁,修改新需求出了些小事故,一直很想记录这件事情,但由于
6
月份忙于找合租房子,就一直没有记录;如今回忆这个小事故,想记录记录,让我想起了收费系统;好快,
8
月份来了,今年的收费系统的性能能否经得住考验,心中有些牵挂。离开这个系统就快一年了,不知道它运行的好不好。
也许有的人认为用这个题目来形容测试工作有些夸张,
^_^
,之所以会起这个题目,是因为我当时有这样的感觉。
回头看,事情是这样的,这个系统业务、功能不是很复杂(嘿嘿,对于我来说),但需求给的不够细(应该说用户不知道这个系统具体能帮他们实现什么,但是他们需要这样的系统来便于管理),等到系统做出来后,刚测试好,就马上要上线了。期待啊,这是大家的心血,加班那么多天赶出来的软件,就要开始用了,这是部门内所有成员的第一次合作成果。第一步的业务功能用的反馈效果还可以,用户提出的多是字面描述上的修改。第二步的业务功能在使用的前两周,用户突然提出了很多新需求,并且要求在短时间内修改好,不影响上线使用。
就这样在短时间内,在开发人员人力紧缺的情况下,解决这个新需求后的程序提交测试后,出现了很严重的问题。离上线的时间越来越近,开发人员、测试人员就像医生在手术室里抢救生命,过了用户的使用期,这个系统做的再好那也用不上了。终于在早上的凌晨,系统的严重问题都已经解决,可以顺利上线使用,身心很是疲惫,还好的是大家辛苦的付出,软件还是活过来了。
出现这样的现象,原因是:新需求的修改策略出现了失误,开发人员过分的修改了程序。这更一次提醒了我,工作一定要把握和认清楚自己的目的和范围,一定要做适用的工作计划;只有这样工作才是有效率的。对于领导安排的没有做过的高压力工作,可以接受,但是要提醒领导自己的能力和情况,不要对结果抱乐观,自己只能是全力以赴的去做。
做测试工作很累,因为要站在不同角色来思考和测试所开发的软件;站在技术支持人员的角色,就希望软件容易维护;站在用户角色,就希望功能使用简单、好用;站在测试人员的角色,就想知道这样的设计会出什么样的问题等等。除此之外还要想办法使用有效的方法快速测试软件。
做测试管理工作也很累,因为想要带好队伍,把队伍发展好、管理好;要做决策,要承担决策的风险;心里压力比较大。
其实干哪一行,想干好,都很累,为什么那么累了还一直充满热情的做下去,也许就是因为爱好,它能激发人本身所不知道的潜能。