总结经验贴,欢迎提意见
文档中不许有套话
所有文档中,对于
试用于两个以上项目的文字, 不允许出现,必须全是"干货"
项目任务时间中包含评审时间
比如:概要设计的三天中包含"设计评审"时间,自己的任务有的提前或者稍延后是可以的,但不能影响其它人
过程中不沟通,最后评审才发现问题的需反省
研发不自测不得提交给测试工程师
此类现象属于不尊重测试工程师,没啥好说的
测试经理有权拒绝测试
不符合测试流程,提交版本混乱,质量差 等可以拒绝测试,产品质量问题 测试经理需直接向小pac汇报
意见的沟通:
平级间尽量进行有建设性的提意见,即提意见时附带解决方案
无解决方案时反应给部门负责人,由负责人想办法,防止认为是"抱怨"的误解出现
经验分享:
为呱呱维基做贡献 我们不同部门间在犯同样的错误,请
分享你的经验,这样你才能学的更多
技术经验,协调经验,项目经验,沟通经验均可,你牛就请证明这一点
开发-开发间协作:
提供的接口和模块需完成自测(测试工具or白盒测试or测试工程师测试),不得靠连调测试,那是在耽误大家时间
开发-测试间协作:
开发提交的安装包/程序 需完成测试经理提供的冒烟用例,无用例时完成基本自测,基本功能都不能用就给人家测试不是拖人后腿么
邮件使用:
通知类使用邮件,需要互相了解的面谈或者电话,禁止把邮件当论坛使
复盘:
项目总结,月报,部门例会是用来共同复盘和分享经验的,这个非常有用,请重视
质量不单是测试的事情:
测试不可能测到所有出现概率再1/10000以下的bug的,需要开发人员靠自己的设计和编码实力,逻辑思维水平来保证
任务分配:
任务分配坚持S.M.A.R.T. 原则,并提前告知
项目不等人
项目中有人请假等需安排人代为行使相应的角色,让大家等某个人是不合适的,请假人的主管要保证这一点
会议是统一认识的,不是现场解决问题的
会议主要是用来 任命,通知,整体沟通的,禁止出现会前不沟通,会上两个人激烈争论, 其余人员集体打酱油的情况
尤其是目前的需求会等,必须事前讨论过
重要不紧急的事情需要优先做,否则天天是即重要又紧急的事情
项目必须有 核心需求&上线时间
公司的战略需要各个版本去落地,每个版本必须配套相应的"使命"与"核心需求",而且要有"时间线",否则一个版本无休止则后续版本无机会!
出现争议由上级间解决
项目中各方出现争议或者问题不得搁置或者"冷处理",必须分别反馈给上级领导,由上级领导间协调解决,已经出现过因"搁置"而严重影响项目的情况