• 当我们在谈项目成功时我们在谈什么?


    当我们在谈项目成功时我们在谈什么?Internal Sharing To Test Engineer.

    工作上做了许多项目,最终都是成功的,但是过程曲折,有很多不顺与需要改进的地方,往往我们在做完一个项目后,就觉得万事大吉,顿时就松懈下来,不做总结,不反思下过往,急着投入到下一个项目中去,又开始了腥风血雨的征程。so,我们在谈论项目成功时,应该谈写什么?

    一、总结

    • 项目中最大的阻塞事情是什么?为什么会有?
    • 项目中让自己觉得最困难的是什么?怎么产生于解决的?
    • 流程上有什么问题?
    • 交流/反馈上有什么问题?
    • 自身问题? 
    • 其他

    二、指出问题、改进问题

      指出问题是为了更好解决问题,我们在项目过程中一定会遇到各种各样的问题?如果抱着不解决的或者拖延的态度,问题最终还是会在那里膈应着你,所以在项目中,可以从以下几点入手解决:

    • 记录问题。
    • 分析问题根源。凡事的产生都会有一个根因,试着去分析,深入的思考,看透现象的本质。
    • 解决问题,先自己尝试解决,无果的话就及时反馈上级,切不可阻塞进展。
    • 最后以日报形式记录总结,反馈给相关责任人

    三、如何提高交付效率

      做项目的目的是为了公司挣钱,自己挣钱,体现自我价值。而面对竞争日益激烈的市场,【快、稳】是保证公司能迅速占领一席之地的法宝。项目需要快速交付,版本需要快速迭代,需求随时又可能会改变,对于测试人员无疑有较大的压力,这时候,抱怨肯定解决不了任何问题,带着情绪工作也不会有好的结果,那么,如何面对这些压力并提高交付效率呢?

    • 测试用例:黑盒测试,以测试用例为基础,需要不断的打磨自己的项目测试用例,如何设计高质量的用例,是优先要考虑的,否则面对复杂的系统,没有用例的支撑,就会面临许多的漏测。
    • 测试策略:知道怎么测,哪些是重点,哪些是客户最关心的模块,往往能第一时间发现最要紧的问题,并及时反馈到开发去解决。问题发现的越早,成本就越低。所以测试策略很重要。
    • 项目计划:项目计划里有开发的项目计划/测试的计划/客户验收确认的计划等。知道了计划,就需要提前对每个计划节点的目标做准备,做好相关资料/环境的构建。
    • 开发版本质量差怎么办?:其实版本的质量保证,最终靠的还是开发人员,因为他们是bug的创造者,测试人员只是站在另一个角度去帮助开发发现自身代码逻辑的错误,而不是制造问题的人。所以有的领导说让测试保证质量,这是不可能实现的,因为测试只能发现到问题,而无法参与解决解决问题,更无法保证开发不引入新的问题。所以,开发的版本质量差,测试最直接有效的办法就是版本打回,不再投入(如果有明显的致命/严重bug),以此方式反推研发改进版本质量,重视自测流程等。当然,开发的内部结构优化,如何保证转测版本质量等,不在这里细谈。
    • 需求来回变动怎么办?:2019年经常看到程序猿与项目经理干架的新闻,大概就是因为需求变动太频繁了吧。哈哈哈~,那么对于测试而言,需求变动要做的,就是针对需求做好分析并设计对应的测试用例,静候需求的下发与功能验证,保持平静的心态。因为需求一般是客户/市场/产品设计者产生,下发到项目经理审核后给到开发(审核的作用不大 - -),程序猿小声抱怨一番后,摸一摸光亮的前额,开始分析/敲代码,一顿操作后,又变更了一个需求,走上述流程后,程序猿开始大声抱怨了,但最终也还是得改,几次反复以后,就看到了我们上述的新闻。所以,需求真正下发到测试还是有一定的过程的,及时已经到转测阶段修改,应该也不会太多次,而测试也只能是抱怨或强烈抗议项目经理冻结需求~,保持平静的心态对待,还是有必要的,兵来将挡水来土掩,做好该做的。
    • 客户确认周期长怎么办?:如果是和客户合同定制的产品,而客户有存在确认周期长的问题,如果做好前三条,其实也是静观其变。测试无法与前端直接沟通,只能去催市场销售人员等,但是一切的前提,只要保证自己的工作做好,客户1来不会反馈很多问题,2是催多了容易黄,也不会催。

    四、分析Bug的产生周期及原因

    • bug的产生阶段:需求期?设计期?代码期?
    • bug的产生原因:需求不清楚?设计错误?代码失误?测试环境局限或数据不足?培训不到位测试人员没理解功能?
    • 为什么没有在测试阶段发现:测试用例设计失误?研发流程不完善?测试资源不足?测试时间太紧张?测试工程师失误?
    • 以后想项目中避免同类bug的方案?如何举一反三发现更多的bug,找出研发的设计漏洞?

    对于bug产生的原因分析,有助于真实的解决实际问题。

    五、如何构建质量系统

    • 充分了解每次版本发布的设计变更/逻辑变更
    • 设计有效的测试用例
    • 固定有效的测试环境
    • 制定有效的测试计划
    • 与相关人员进行review并改进
    • 随时掌握研发进度
    • 对任何可能影响到测试的变动要警惕/敏感
    • 及时作出反馈,汇报风险
    • 根据需要及时更新测试用例及测试计划
    • 了解项目负责人的编码/工作习惯,提前识别风险点
  • 相关阅读:
    eclipse配置Tomcat The superclass "javax.servlet.http.HttpServlet" was not found on the Java Build Path
    解决掉你心中 js function与Function的关系的疑问
    英语 one day
    合并两个有序链表
    有效的括号
    探讨前后端分离
    菜鸡发现腾讯视频bug
    最长公共前缀
    字符串转整数
    回文数
  • 原文地址:https://www.cnblogs.com/aszeno/p/12204501.html
一二三 - 开发者的网上家园