1. TC是test coordinator的缩略语,它负责测试的协调和监督。主要进行如下工作:
Ø 进行测试工作量估计,制定测试迭代计划;
Ø 分配测试任务与协调人力;
Ø 组织测试团队参与讨论需求,需求确认;
Ø 制定测试方案以及用例的书写模板与存放地址;
Ø 负责组织用例的Review;
Ø 引导项目组成员进行测试执行、测试结果分析和报告活动;
Ø 缺陷的管理与统计;
Ø 风险的把控;
Ø 进行测试技术、测试用例设计、测试工具使用上的培训;
2. TC在实际项目中的职责
1)项目系统的全局把握,对系统的整体分析:
根据SRS积极与开发PM沟通,尽快尽早把握系统的整体,分析整体系统,清楚系统是属于哪种类型的系统,比如是中间件类型的?还是WEB界面类型的?还是接口方面的?还是客户端方面的?还是服务端方面的?整个系统的框架、结构原理是怎样的?等等。
2)再分析系统,清楚系统中哪些地方是很脆弱的地方,哪些地方须要考虑并发性等,系统是否须要性能、压力、可靠性、稳定性等等的测试;
3)具体的每个小模块是实现什么功能的?如何与整个系统交互的?通过什么方式来实现的?传递什么参数?业务处理逻辑与哪些相关?
4)测试环境硬件、软件、操作系统、数据库?如何搭建?公司里能否保障到?自己该如何获得这些资源?
5)收集对SRS的疑问,跟开发PM确认;
6)向PM提出系统问题、疑问,提出建议,根据测试经验给出系统的设计不足等等方面问题通过对整体系统的分析,分析出测试需求,并用文档将测试需求点清晰列出;
A、在前期介入SRS熟悉阶段,必须对SRS做分析,明确系统是做什么的,要实现什么功能;
B、能从字里行间找出系统的关键字,找出测试重点,提炼出性能需求、并发需求、压力需求参数等等,关注文档中的数字,或举例方面的数据;
C、系统的稳定性、可靠性等等方面的考虑
D、关注数据库的性能、优化、异常等;
总之,要从SRS文档里找出有价值的测试问题,先提炼、再分析、再列出、再考虑如何测试?是否借助测试工具?该工具如何获得?是否须要编写测试脚本?是否须要编写数据库测试脚本?
(7)根据测试需求编写测试计划、测试方案,明确项目计划时间、资源、须要的技能、技术知识等等;将文档发给测试经理做评审活动;
(8)指导测试组员熟悉掌握系统、每个负责模块内容,技术指点,指导编写测试用例;将测试用例文档发给测试经理做评审活动
(9)开发即将转系统测试时须要做的工作:
A、从系统测试用例中挑出覆盖系统基本功能、重点功能的用例给项目经理,以便开发部做转系统测试前的ST测试工作。
B、负责在缺陷库建立项目、各成员访问权限;
C、指导测试组成员搭建测试环境,提前做好测试准备工作。
(10)开发转系统测试后须要监督指导的工作:
A、取有效的版本;
B、指导测试人员做ST测试工作,ST测试主要是包括安装测试,看能否安装成功;然后将系统从头到尾按流程跑一遍,查看基本功能、重点功能是否实现?是否有受阻模块,导致不能进行下一步测试的?或导致整个系统都不能运行的?一般ST测试是半天~1天的时间。如果能跑通,基本功能正常则转ST测试成功,否则转ST测试失败。转ST测试失败后,将版本打回给开发人员,并将问题反馈给各位负责人及相关领导,以便及时解决问题。
(11)查看测试人员测试用例执行情况,监督测试人员是否将有问题的测试用例直接将执行结果标识为:OK,或不认真执行测试用例等情况;各个方面的测试是否到位?测试执行过程中及时沟通、了解自己的测试人员情况、及时收集问题,反馈问题给测试经理。测试时间的提前、延迟等情况都应及时反馈给测试经理,以便测试经理了解资源状况。
(12)在回归测试过程中,出现前一轮提出的问题单未修改,则直接打回问题单。
(13)回归通过的问题单,TC督促项目测试人员关闭,项目结束,通过的版本,缺陷库里不应有遗留问题。
(14)缺陷库里的问题单不能随便关闭,有争议且未改正的单可作为悬挂的单遗留在库里。
(15)系统测试完毕,TC收集各模块测试人员的测试报告,进行汇总,整理出一篇总体报告,发给测试经理做评审活动。
(16)关注测试过程中数据收集,负责版本质量,确保测试出的版本是合格的。
(17)鼓励测试组人员写项目总结,自己汇总或总结项目过程中的经验,每出一篇优秀总结文档都会有精神或物质奖励。
(18)团队建设:团队的战斗力;团队的业绩;版本的质量。
(29) 每天汇总工作情况:
A. 熟悉SRS情况及项目进度情况;2)项目测试用例编写效率、项目测试执行效率;B.每个测试人员每天的工作绩效统计;4)项目周报;5)项目结束的总结报告,包括:提交的系统测试报告、缺陷分析报告。