在开始讨论这个话题之前,我想先举一个真实的例子:
有一对夫妻住在同一个房子里,但相互之间不沟通,或者说他们之间没什么好沟通的。他们只有在重大事情发生的时候才用简讯沟通。否则他们都太忙于自己的生活,也没有时间去打扰(照顾)对方。长年累月下去会发生什么?一次挫折、些许挫折、表面的愤怒、一次爆发就会发生。只有更多的沟通、更少的争执、一些认同和相互之间的鼓励才能使一段关系更加稳固。
现在,将上面的情况和软件项目周期比较一下。
研发人员和测试人员之间的关系在某种意义上是类似的,他们都为一个项目而努力并致力于项目的成功。世界上没有一个项目的成功是因为工具、预算、代码或者基础建设。项目成功的真正因素始终是人。事情的成功往往和一个团队是分不开的。
在捋清主线以后,我希望你能深入的理解为什么测试人员和开发人员必须要像一个团队一样的沟通和工作。
为什么测试人员和开发人员必须要像一个团队一样的沟通和工作?
首先,让我们概况下开发人员和测试人员以团队的方式工作的好处:
1.默认情况下项目是成功的:
当一个项目不会因为一些琐碎的问题和自尊心而导致开发团队和测试团队经常性的争执,这个项目是成功的。大部分时间下,开发和测试团队在玩一个任务分配的游戏.是的,就是bug分配.每个人都想证明问题是来自其他人.如果能够明白问题最终是归属于项目内的并且试图把问题一起解决,那么所有的问题都会引刃而解。
2.个人的成长:
每个人都会成长,因为这是一个良性竞争,并且没有阴暗的争斗。想法被分享和建议被接受给每个人进步的机会。
3.团队成长:
团队成员之间的互相了解和互相尊重最终会使得一个团队变得更强大更有竞争力。
4.为未来而学习:
每个人都会在交付一个成功的项目后获得学习。一个团队未来的项目也会变得更成功、更便捷,更顺利。
好的,现在我们知道协同工作与仅作为一个开发或一个测试人员相比是有优势的,但是又应该怎么去运作呢?
测试和开发人员:沟通是关键。
协同工作的想法:
1.工作时放下自我:
知情或不知情的情况下,我们把自我带入到工作的地方。我们认为我们做的最好(对此毫不怀疑),但这并不意味着其他人做的不好。
如果一个开发人员认为他所有他研发的模块中被报告的缺陷都是无知的,愚昧的,恶意的或者有意的侵犯,那么这里的缺陷应该是自我问题而不是bug本身。如果一个测试人员认为他报告的bug被拒绝是因为开发人员想要伤害他们,是因为开发人员不想解决bug,是因为开发人员认为这个测试人员不能正确地理解事物或者因为开发人员认为他是一个开发者并且做的最好……测试的想法和bug都会因此减少。
通过展现并实践自我,我们正试图把自己脱离成长,并把他人从工作中脱离。
所以如果有可能的话,不要把自己当成是一个测试人员,首先把自己当做团队的一员,努力正确地做事。当bug被拒绝的时候不要感觉受到打击,而是努力去弄明白原因。在预估的测试时间结束后也不要停止测试。不要小看自己,接受开发是一项伟大的工作并且最后不要因为你从其他人的工作中找出问题而过于骄傲。
2.实事求是:
作为一名测试人员,最痛苦的时候就是当你提的bug被拒绝。实事求是、试着了解背后被拒绝的原因、尝试理解你误解了什么,如果你认为你所提出的设想情况是正确的那就试着继续前进,试着说服开发人员或项目经理.
3.确定项目的优先级:
总是关注着大局,根据实际情况确定事情的优先次序。项目比一个bug或者个人更重要。放下你的自我,去到开发人员的办公桌前,讨论、分享、理解和工作。
4.耐心点:
事物不会轻易改变,所以耐心点,坚持你所做的好的事情。如果有人给你带来消极的情绪或者开发人员不认同你的建议或者bug,也不要轻易放弃。
5.分享观点,但并不强制执行:
开发和测试团队之间频繁的沟通有助于双方生成更多的想法。开发人员可以建议有关如何更好地测试一个特定的模块,同时测试人员可以展示如果去修正缺陷。为新建议和新主意敞开心扉。
6.接受人是会出错的:
在发现一个严重的bug后,不要在开发人员面前打趣它。要知道测试人员在时间和预算紧张的情况下的工作方式和开发人员是一样的。没有人可以创造一个没有bug的软件,否则测试就不会存在。所以要理解你的角色并帮助纠正问题,而不是取笑他们。
7.要知道多个团队肯定比一个团队要好:
一个测试团队一旦和其他的开发团队脱离,就不会有任何生产功能。当测试人员调整自己以适应立足于开发者之间,发展一种相互关系并创造一个良好的环境。当所有开发人员和测试人员一起工作时,对双方都是一个双赢局面。
8.敏捷和结对测试:
喜欢敏捷方法、协同工作、结对测试、与开发人员合作、频繁的讨论和会面,更少的文档,对每个人的工作给予同等重视和尊重。
我将总结一下几点观点:
如果你认为你是个清洁工,那么你永远都只是清洁工。
但是,
如果你认为你正试图使世界变得更好,更干净,赶上垃圾收集器,并且有策略地努力做事,这个世界肯定会变得更好。