从我对测试主管工作的记事以来,就在印象中保留了这样的一幕。记的刚进一家公司时,我团队中的人员就开始经常会有下属跟我说抱怨,公司的需求工程师让我们太失望了。需求如何如何不好,然而,多少有些经验的我,当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比,的需求跟公司的需求人员的需求做了比较这时才发现,发现,原来我们公司的需求人员还是做的得不错的,。让测试人员把心态调整过来是测试主管的另外一件事。试问,,如果是你做需求作为需求工程师,是否会比他们做的好吗得更好??有了这样的基调,就可以让然后建议测试人员去总结不清楚的地方,给需求人员一个相对比较具体和明确的意见,这样顺利的了解了需求。
其实有时候不是流程不对流程在这其中并没有太多值得指责的地方,而是相互的理解与支持,换位思考而对流程的执行态度,却是更加关键的。我们不得不学会如何换位思考,并更多地从他人的角度来看待这些问题。
同样的问题还出现在还有需求变更上,很多测试人过不了这一关,。总是他们指责研发人员,让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番,其实不难了解,,其实需求变更对研发工程师来说是更大的麻烦,。他们需要修改设计,、代码,相较而测试只要需改测试用例,他们的工作确实更加麻烦。简单来说,就ok了,其实大家要分析什么样的需求变更最可怕,而不是眉毛胡子一把抓,其实测试对需求变更并不可怕,怕的是只有在提交时才发现,导致测试时间不够,才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行,。也许有人会说你也需要说:,说的倒很容易,如果研发不按照你的要求做怎么办!其实这里你只要用我所采用的方法是用数据说话,在项目进行时统计发生过多少次这样的事情,让研发管理层知道,让项目组之间有一个比较,。一方面,如果是一家公司重视质量的公司,必然会引起重视;另一方面,从质量管理部门角度本身出发,也应该推动公司重视质量。,随着时间的增加,需求变更给测试人员的反馈一定会有下降的趋势,。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事,要允许别人他们犯错,对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度,则要与研发部门沟通清楚,,如果研发不认可的情况下还可以请上级进行评估一下。
上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情,某些工作,也许并不一定是测试部门的优势,而另外一些,则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点,可能大多数从功能测试上来一路走来的测试人员是无法做的到,这时要善于利用资源,不一定要测试做,可以从通过流程上保正有人来做积极调动其它部门的同事。,或是找有能力的人来做,测试可以进行监控。其实这种技术含量高一点的测试,对人的因素要求更大高,可以借助研发团队一起来做会有更好的效果,。记的第一次做Oracle数据库性能监控时,就是请的Oracle的DBA专家帮助设计了性能参数,成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高,严重的限制了测试的发展,希望测试的同行能真正的提升测试技术水平,把这些高难度的测试做起来,而不是仅仅只是工具上玩玩,。只有真正提升测试团队的技术含量,这样别人才会更信赖你,这也是我这么多年来的一点经验。如果你对开发很精通,、同时又精通对测试颇有研究,、善于诊断性能与架构上的问题,、经常会帮助研发部门解决一些他们无法解决的事情,、同时又还懂的如何做测试管理,并了解研发人员的心态,那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。