发布新日志

  • 测试管理(三)

    2013-03-26 13:22:26

    4、沟通协作
    测试之前相关所需:业务背景、别的团队测试经验、开发技术支持讲解、需求讲解、发布支持、测试技术支持
    测试过程中所需:出现问题协调其他团队、难点技术支持、进度及质量出问题时协调开发、bug等级确认调整、发布确认
    测试后所需:组织团队学习总结,指出问题并给出解决方案,相应项目文档积累
    沟通:同上级的沟通让其了解团队的成果、进度、问题,同平级人员沟通提前预知测试中会出现的问题及工作计划,做到早知道早做打算(通过每周经理之间的会议了解),同下级的沟通,了解当前的工作进度及存在的问题。
    5、风险预估及调整
    每日例会:进度、质量、问题
    周报:工作内容总结、问题
    观察:抽查质量、观察成员的工作态度、开发的质量及人员
    沟通:成员沟通、多团队合作时其他团队间沟通,测试开发间的沟通
    技术分析:项目的难度、风险遗漏点、新技术引进
    6、绩效考核
    人员任务的难度(通过分析测试技术、了解需求及任务具体内容得知任务难易程度)、进度与质量(通过需求、用例、执行测试、bug量的统计进行分析,通过监控分析数据得到考核数据)
    工作态度(观察分配任务的接受程度、工作质量,是否消极)、积极性(分配任务时是否积极或任务期间出现问题时是否主动找人沟通解决)、责任心(遇到突发情况时,通过加班观察或出现影响团队利益时的态度或帮助他人的意愿)、团队沟通能力(同开发、需求的沟通能力,组员的沟通能力,同上级的沟通能力)、工作汇报积极性(遇到问题主动汇报或主动汇报当前工作进展)
    测试用例覆盖度、执行测试全面无遗漏、bug质量(重要程度、发现时间、验证时间),通过监控过程中的数据得知并做记录
    测试经理需要在发现组员问题后,记录组员的问题,严重的影响团队利益的问题需要找他沟通解决,非严重问题也需要记录,并观察是否是会一直触犯,并在绩效考核时给予指出。
    考核沟通过程中要做到有理有据,才有说服力,同时也需要思考全面及客观,让组员心服口服,从而树立自己的威信。考核过程中要注意方式方法,功劳及错误,都要指出,并给出自己的建议。(具体如何实施,具体场景)
    7、团队发展及激励
    团队知识积累:技能知识(数据库字段语句、测试工具、测试报告、bug分析记录、需求文档、用例库、bug积累,线上问题分析记录)
    团队沟通平台:用例平台、bug平台,SVN管理、需求共享平台、代码及发布平台、测试环境
    团队人员职业规划:了解其性格及工作意向,根据其水平指引其努力方向,团队知识分享
    团队人员风险预估:平常观察其动向,并根据市场进行评估
    团队人员储备:任务分配过程中进行逐步培养,并做好人员储备,根据其性格及意向,并做相应培养
  • 测试管理(二)

    2013-03-26 13:20:41

    2、任务分配
    总任务量:按照新功能模块或受影响模块,编写用例的数量,执行测试用例的总量,测试工具开发量,背景知识学习时间量,配合别的团队的工作量
    任务重要等级:核心模块功能,测试难度大的模块,改动较多的模块--》改动较小、影响较小的功能--》未受影响模块功能
    人员等级、能力及时间:人员能力等级、技能,每个人工作量(人天),每个人按照每天6小时的工作量评估。
    时间任务人员平衡:达到团队中人员的工作量相近,难度与人匹配,同时考虑不同层级每个人的发展,工作积极性及意向,及做相应的风险预防。
    任务职责:约定每个人的工作内容,做到责任清晰可追踪,边界地带责任到人不出现扯皮现象。
    发布人的职责---》项目中指定或固定人员,版本控制严格保证测试环境的正确性,记录测试发布中的相关点
    需求用例人员--》需求到模块化之间出现的需求的确认变更跟踪及用例的补充 由 功能的模块化测试阶段人员负责
    用例执行及bug--》按照分配的功能模块执行用例,提交bug,等待bug修复且版本发布后,验证bug及相应功能点,持续追踪直到被解决。通过bug平台查看bug量及相应的严重等级,大致了解软件的质量及测试人员的执行状况及用例覆盖度。
    用例编写人--》基本按照模块化谁测试谁编写的原则,也可作相应调整,根据时间及工作量调整。
    用例复核--》任务中指出相应的功能的复核人,做到交叉复核,复核后的结果email组内发出,相应用例编写人员补充修改用例。中间可以通过查看邮件内容得知大致情况(用例编写人的工作,用例复核人的工作)。
    用例评审--》由用例编写人发起会议邀请,在规定时间周期范围内,组员自行调整安排,但是需要督促执行。

    人员风险预防:
    平常观察-->人员的动向(是否经常出去接打电话,请假),对待工作的态度有无转变、工作情绪
    沟通了解:通过面对面的沟通了解,通过其他同事口中获取
    分析:薪资与技能是否匹配,工作兴趣及意向,人际关系情况
    3、任务执行及监控
    任务执行进度、质量(如何检查)
    每个任务阶段的监控手段:
    需求阶段:需要组员用邮件的形式发出需求中存在的问题及疑问点,通过查看邮件中的内容,得知组员研究需求的程度(全面性及深度)。前提是经理要对需求了解深入。
    用例编写:将每天编写的用例发布到用例平台上,每天站立汇报工作进展。前提是需要有一个用例平台可以统计发布组员的用例数量。
    用例执行:通过用例平台执行用例,通过平台统计每日每人的用例执行数及阶段内的总量,从而来确定当前的执行进度。用例的执行质量,是否遗漏或测试不全,可以通过经理抽查或在回归测试阶段,出现的相应的bug来分析总结(按理说不应该在回归阶段出现的bug及bug总量分析),从而来确定模块化测试人员的质量。
    bug量:通过bug平台,每日发布组员的bug量(bug所处的阶段及严重程度及有效性),通过bug的质量就可以组员的测试状况及工作能力。测试经理可以通过bug总量及修复状况,督促开发团队配合解决。同时抄送开发及需求团队(可以建立一个虚拟邮件组),起到督促开发解决bug的目的,同时也让开发经理了解开发的质量及解决bug的进度,同时也让需求人员了解当前的软件质量及测试的工作量,从而对以后要是出现项目延期提供数据依据。前提是搭建一个bug平台,需求开发测试都有相应的查看权限。
    用例评审:通过需求讲解,从而知道组员的需求理解状况,是否偏离或出现误解,需要细致知道每个细小功能点的内容,用例中是否有覆盖,从而进行风险预防,从而也可知道组员的需求理解能力。
    用例复核:组内人员交叉复核,邮件通知组内复核结果,测试经理需要关注邮件内容,得知组员的用例编写能力,并也要持续跟进用例补充情况。
    其他手段:
    例会:组员给出今天所做任务,明天所作任务,今天任务过程中遇到的问题
    软件功能未实现或质量较差影响测试--》测试经理需要督促开发解决问题(并给出解决时间点)或让组员养成自己去督促开发解决的习惯,让此作为一种工作积极性的考核。测试经理也需要分析问题的严重性,然后和相应的开发经理进行沟通,找到问题根源,以便减少此类事情出现的概率。
    有别的任务插入需要解决--》经理需要根据两个事情严重程度进行分析,然后进行调整。别的任务严重,先处理别的任务,同时任务量及时间上可以做些细微调整。如果不重要,可以先放放。
    工作量太大预估时间不够--》组员需要给出具体的原因,bug太多,还是技术难度大,还是组员自身的技术水平能力不够。经理需要分析原因,并协助解决问题。
    其他事情请假影响进度--》尽量加强组员的工作积极性,并养成一种工作习惯氛围,自己的事情尽量自己做好,每个人有每个人的工作量,每月的请假量也作为一种考核方式。
    观察:通过平常观察或邮件反馈,详细分析并及了解当前组员工作内容,查找缺失点及风险点、进度是否与预期偏移,及时发现督促并解决。

  • 测试管理(一)

    2013-03-26 13:17:25

    1、测试计划
    测试内容:根据项目需求说明书或产品需求或业务技术调整,分析要测试的相关产品或项目(新产品或受影响的产品)
    测试范围:详细分析,具体到相应产品下的模板或功能(整体功能或局部功能)
    测试时间:紧急项目一般已订好节点,项目组预留的测试时间; 非紧急项目,可根据工作量任务的大小来规划测试时间。给出总体测试时间,细分测试需求分析时间、测试用例编写时间、测试复核时间、模块化测试时间、回归测试时间、上线时间,这其中时间应给出相应buffer,用来处理突发或紧急事件。这其中需要了解开发的相应开发周期,系统设计、详细设计、编码阶段、总体提交或分功能提交相关时间点,要是团队要实行单元测试或接口测试,可以在开发编码阶段介入并给出单元测试时间。根据开发的提交时间点,来规划各个时间段内的测试任务。考虑工作重复度、技术风险、开发质量、团队合作带来的问题等,给出相应的应对策略,做到合理高效,保证计划遇到问题是可调整的,带来的损失是最小的。
    人员:根据人员的能力等级(初级、中级、高级)、性格(UI\逻辑\流程)、工作态度(细心--细致的活、耐心--繁琐细致的活、积极--紧急、沟通--需要合作完成的内容),根据任务的性质和人员进行匹配,并综合考虑测试时间及工作量,以及风险预防,以及为后期的项目做储备。给予了一个具体项目和人员,具体怎么搭配,如何合理高效,达到目标,还有待思考?
    测试策略:单元测试、模块化测试、集成测试、回归测试(测试的轮数根据测试时间、相应的软件质量及bug量、整体的预期标准进行调整)、性能测试(根据项目的特点进行取舍)、安全测试、兼容性测试、实用性测试,充分分析系统需求及市场人群定位及软件使用环境(客户端、浏览器、网络、目标人群--年龄行业背景、是否是高并发),来决定测试策略。以及测试过程中针对某个有难度测试点,需要开发相应的测试工具或脚本,以及测试知识背景的了解。每轮测试过程中关注点不同,模块化测试关注流程及整体功能、回归测试关注逻辑及深层次问题及其他相关问题。
    测试标准:
    开发提交版本标准:开发提交测试的软件质量是否达到测试标准(流程通顺无重大影响测试缺陷)
    模块化测试结束标准:一级、二级bug修改结束且已验证完毕
    回归测试结束标准:一级、二级bug修改结束且已验证完毕,查看3级、4级bug分析并调整相应的级别,且已经修复完毕。
    预上线测试标准:部署到与开发环境等同的环境中,随机进行测试验证,无重大bug。
    需求变更标准:开发、测试、需求三方确认同意后,走需求变更流程。
  • 绩效考核(转载)

    2013-03-21 23:34:49

  • 如何管理好测试团队(转)

    2013-03-21 22:42:22

Open Toolbar