标签:
1.理论与实践差异
问题场景:计划和风险(进度、质量等)在实践操作中有偏差
解决办法:计划先行,尽早暴露不好的风险,最小成本处理
2.研发质量提高
问题场景:功能调整影响原功能(反复、验证成本)
解决办法:自测、草稿设计、草稿场景验证
3.测试质量提高
问题场景:常规、非常规测试,功能点测试要点不足
解决办法:多业务场景测试用例、功能点测试要点罗列
4.计划执行偏差较大
问题场景:过于理想评估计划,实际执行不可预期偏差较大
解决办法:要做充分计划,罗列计划要点,预留足够缓冲时间
5.集中测试对进度干扰大
问题场景:功能开发调整完毕,集中提交,测试验证时间较长
解决办法:局部交付,做阶段性验收测试,确保已验证功能稳定性
6.客户验收缓慢
问题场景:客户迟迟不愿验收,是因为一些不太愿意说、做的事情要做完
解决办法:多与客户沟通,找到客户顾虑,解决痛点,推进下一步
7.后期测试发现重大漏洞
问题场景:发现重大漏洞,虽不是我们这边导致的,但对整体项目影响不好
解决办法:项目经理要多想,要替客户多想,把控范围、进度、质量、风险等
8.注意与客户沟通方式
问题场景:与客户沟通,不要用理论的形式交流,多关注客户的痛点
解决办法:注意把控不同角色关注点,平静、平和、淡定,莫着急,平稳推进
注意良好沟通方式学习,平息对方顾虑和急躁,以合作共同解决为出发点
9.多做一点,可减少很多成本
问题场景:研发提交的功能总会留一个小尾巴,测试覆盖测试也不太严谨
解决办法:在不超范围前提下,如果只是成本(进度、质量、实现难易程度)很小,风险很小,
对功能优化、功能Bug修复、功能体验升级,那就随手多做一点,可以达到很好的效果
10.客户提出的无理要求
问题场景:客户针对模糊的需求提出可扩展的无理要求,甚至超需求的无理要求
解决办法:跟客户很好的沟通,把范围往小了圈定,针对最根本的痛点,满足最小的需求
不是不做,可以做,往小了做,解决目前最紧急、最根本的痛点问题,以解决问题为宗旨
11.客户提出的需求和问题
问题场景:客户说要对某个功能设计进行修改,客户说要实现某某需求
解决办法:客户告诉你的未必是他真的想要的,需要多场景、多角度帮他分析,让他自己深入分析,并告诉你结论这到底是不是他想要的
如果不具备快速验证发布条件,不需要那么快的响应速度,避免朝令夕改,很是头痛和疲惫,帮他们深入分析,让他们想清楚他们真正想要的是什么
1.研发提交测试流程
问题场景:
研发修改Bug完毕,未进行代码发布,直接将Bug状态进行修改,测试回归Bug,未通过是因为未发布。
假设 昨天测试提交的Bug,昨天开发改好了,把Bug状态改为 已解决,却没有进行发布。
今天测试登陆,看到Bug已解决,进行回归测试,验证还是不可以。其实 是没有发布导致,浪费测试时间。
解决方法:
为提高团队运作效率,大家有成效的工作。
研发修改完Bug,在相关调整功能发布之后,再到Bug管理平台修改Bug状态。
2.缺陷提交规则
问题场景:
测试测过的功能,还潜藏着严重的Bug,或是一些不合理的逻辑操作、不合法的数据操作还是会有Bug产生。
用户使用场景测试不全,只进行符合规则的数据进行测试,却没有进行非法数据、非法操作进行测试,测试深度不够。
测试使用操作不方便,不好用,跟常规的使用习惯不一致。
解决方法:
测试为确保项目质量,需要进行多浏览器、多边界值、各种可能的用户场景、不合规的操作、不合法的数据进行测试。
Bug都要登记Bug管理平台,严重Bug需要研发进行解决,非严重Bug研发酌情处理,
非严重Bug登记,也是以防问题或是好的优化建议被遗忘(优化需要讨论确定修改方案),为孵化产品做优化储备,提高产品易用性、提高用户体验。
3.为什么要组织相关评审活动
评审的目的是为了在真正投产前,进行设计把握,整合大家的意见,以确保该项文件或是该项活动是正确的、有价值的,降低一些不可预期的成本损失。
如:需求的遗漏、设计的不合理、项目管理的不到位、质量风险等等。
4.某模块问题层出不穷
问题场景:
研发对一个功能完好的模块进行功能调整,导致产生不必要的Bug和问题,而且未经充分测试直接丢给客户。
尤其是在推动用户验收,进行验收测试的时候,更需要保持运行环境的稳定性,如果出现重要模块的重大Bug很不好。
解决方法:
研发对功能进行调整,不能盲目自信,一定要自测,且覆盖到相关的使用场景;
如果研发没有时间测试,一定提交到测试部,让测试人员进行充分测试,不能把未经测试的代码直接发布丢给客户使用。
5.研发工作被打扰
问题场景:
来自客户的问题、现场同事的问题、测试同事的问题,直接找到研发这边处理的,都会对研发的开发工作造成中断。
研发一旦被打断需要重新梳理思路,容易导致代码不严谨,潜藏一些Bug在里面。
或是陷入整天忙于处理问题,而忽略主体功能开发工作;处理的小问题,而影响大功能。
解决办法:
紧急严重问题,及时响应处理;非紧急严重问题,可参考如下建议:
(1).客户的问题、现场的问题,及时记录汇总,集中抽时间,向研发请教或讨论;
(2).测试的问题,登记Bug管理平台,集中抽时间,向研发反馈问题,沟通状况;
(3).项目经理把关,项目经理有责任保护研发团队的开发工作不受干扰,可以帮助协调处理、登记非必要问题;
(4).研发自我把控,告知相关人员,研发工作相对重要,请将问题记录,在某天某时找我沟通,确认问题细节;
6.常规功能的常规验证和提示
问题场景:
有些功能缺失常规的校验逻辑,基本的验证逻辑不能得到保障,不合法的数据得不到控制,影响项目的质量。
对于可以明确对应不合法操作或不合法数据的,最好可以提供明确的信息提示,便于客户、测试、开发自己理解。
如:表单页面,两个起始日期的大小校验;上传附件功能,文件格式校验、文件合法校验(exe程序)、文件服务器找不到;
表单录入存储,基本的邮箱、手机号码、输入长度、输入类型、非法字符录入、SQL注入等等
解决办法:
常规功能的常规验证,可以建立问题知识库,而不是仅仅存在每个人凭经验的脑海里,梳理出来。
研发每次开发常规功能时,要注意逻辑的严谨性,确保最基本的验证必须通过;
测试每次测试常规功能时,必须先把基本验证,验证通过才可以进行业务测试或高级测试;
这个可以慢慢的汇总积累起来,可以来自个人、来自团队、来自外部开放的资源。
标签:
原文地址:http://www.cnblogs.com/SanMaoSpace/p/4924661.html