易栈网-膘叔（Neatstudio.COM）

易栈网-膘叔

关于上一篇“遗憾”

遗憾

项目过程中的教训总结

陪客

计划赶不上变化

日志分类

热门标签

日志归档

搜索文章

最新评论

博客信息

友情链接

G1不支持我的博客：
1、默认浏览器打开后，fckeditor中无法编辑，fck的配置文件我改过，是支持chrome（webkit）的，结果还是无法编辑

2、默认浏览器中，附件无法上传，直接显示upload disabled

3、使用opera mini时，验证码始终无法显示

最后上一篇文章是用opera mini用wap方式进行发表的。

遗憾的是，g1居然不支持我的博客，失望啊。

自 WAP 发表

taobaoQA的葵儿之作，任何一个项目都会有总结，善于总结才能抓住事物的本质，否则永远浑浑噩噩的。当然，在不同的职位上，所做出的总结也会不一样，但总有可以借鉴的地方。了解团队中其他人员的问题，结合自己的问题，相信，取精华去糟粕，总可以得到一个相对来说比较适合的方案，给下次开发打下良好基础。

原文如下：

一、项目中如何正确投入测试资源？
五彩石之后，我参与收费线，一度进入了修整期，主要工作是日常。前一阵子有个比较大的项目成立，但是由于人员不够，便决定安排日常与项目兼顾。当时我凭以往经验认为，在项目前期阶段，我们是可以做到将两者兼顾的。但事实是，那段期间并没有按我的计划进行，由于种种原因，也可能是我的时间管理出了差错，我们把多数时间投入到了日常，剧减了前期去理解项目需求的时间。而这一决定直接导致了在UC评审时没能很好的明确把控住，致使现阶段我们的测试成员还在为确认项目中某些功能需求而犯愁。

当这个风险暴露出来后，我曾反思：日常与项目兼顾，以前我可以，为什么现在做不到？是业务复杂度的问题！是时间管理的问题！是团队合作的问题……原因可能还有很多，而我作为项目的测试负责人，前期没将这些风险完全评估出来。即使有一万个理由，也还是一个不称职的测试负责人。

总结：在项目启动时，最好能将资源完整投入，特别是业务比较复杂的项目。若确实出现资源不足，应该及时且坚决地反馈出来。

二、对UC评审的把控。
对UC质量的把控，本该是开发人员的事。但UC写出来，看得最多的则是测试人员。所以测试人员对UC的质量是最关心的。那么从测试的角度，什么样的UC才是可以通过评审的呢？我们现在的流程中还没有完全的标准，这就需要测试人员靠前期对需求的理解来把控。要是前期投入时间不够，自己的工作没做足，在评审时找不出有效的问题。或是由于项目进度，虽然评审出问题，但之后马上进入下个阶段，那么将会导致后期过程中问题多、反复问，此时开发修复完善的积极性又不高。最终致使测试理解需求准备阶段进展较累。这也是前一个问题带来的直接后果。

总结：虽然我们的流程，对特殊的项目可以适当灵活运用，但无论是什么项目，UC对测试人员的指导参考价值是第一位的。这回的教训再次告诉我，在UC评审阶段一定要把握好这个度，那么前期一定要有足够的时间去做准备。

三、项目中的沟通、协调。
一个项目比较大，投入的开发、测试资源肯定也就增多。这期间，成员中出现了沟通上的问题，也曾为之愤愤过，也曾努力协调过……

总结：在测试团队中收集上来的问题，理应站在测试者的角度考虑，但对这类问题也要学会过滤整理。我们每个人的性格不一样，看待问题的态度也不同，作为测试负责人，要综合平时对队友的了解，具体对待。项目组是一个整体，我们的目标是一致的。而且从产品线的角度，大家将是长期合作的伙伴。虽然我们对事不对人，但可以寻找更好的沟通方式，不该因小问题上大和气。

我们的项目业务比较复杂，繁多，所以周期比较长，现在发现了，还可以从某些方面做些弥补措施。但对多数项目来说还是短期的，可能问题发现了要到下个项目中才有机会去弥补。

本来想项目结束后再来好好总结的，不过现在这些教训等到项目结束后，感觉可能就不太一样了，所以想先写出来，以督促自己，也供大家借鉴。

今天小猴过来一聚。当然有原因的。拿一下手提电脑。再加上也已经N年没有坐在一起了。吃了顿午饭，谈了点人生，呵呵。不知何时再聚

自 WAP 发表

随便说说，计划，还是赶不上变化啊
原本打算的N件事，结果被临时的、突然而来的事情全打乱了

« 2024年11月 »