随着公司业务的发展,项目越来越多。每启动一个项目都涉及到各角色成员的入场,前期团队小,通常都是只安排一个QA。作为项目中唯一的QA,又是新项目,一切要从无到有,QA要有很多事情关注。
入场前(可选)
QA进项目前,做一些入场前的准备工作。
1,对inception阶段的产出物进行阅读,理解项目的核心交付价值与目标。
2,项目技术架构了解,不熟悉与陌生的技术,网上查阅资料或其它方式进行了解。
3,了解项目成员,不同角色的人员进行一波信息收集,粗略了解一下每个人工作方式与特点,方便后面入场后,快速磨合。
4,如果是要入驻客户现场,那可能要提前了解一下客户现场的工作模式和合作方式,以及客户要求的一些技术栈。
5,客户现场的项目,可能还需提前了解一下规章制度、安全要求等等。
提前做一些准备工作,以至于到场不那么慌乱或茫然,一些知识的提前了解,也有利于入场后更快速上手。当然,在入场后再了解也是可以的。
进场后(必选)
进场后,以最快的速度与团队熟悉,并了解现场的工作方式与流程,以及客户现场的各项限制和规定。然后,尽情的投入到QA角色当中去,逐层展开你的工作。奉上十个小锦囊供参考。
1、项目业务价值与项目目标
首先要了解项目的背景,主要解决什么问题,它的核心价值与交付目标是什么。这一项不仅是QA这个角色要关注的,每个项目成员都要熟悉,在我们整个交付期,都要时刻关注目标与行进的方向,观察核心价值与目标是否偏离,避免走了太久忘了初衷。
2、项目干系人
要熟悉客户干系人、组织架构。这也是项目每位成员需要了解,在之后的工作中,各角色或多或少会涉及到与客户的合作,了解清楚客户干系人,有利于日后处理问题更能对症下药。
3、测试环境
由于是新启的项目,环境也要尽快准备。首先要确定需要哪些环境、什么要求、怎么定位,QA找团队以及客户方相关人员,一起讨论确定。提醒一下,一定要求各类环境基础设施或第三方软件的版本与配置与生产环境一致,不然后面会遇到各种坑。
QA环境: QA日常测试验证故事卡的测试环境。
UAT环境:类生产环境,通常是用户进行UAT验收测试的环境。
PROD环境:正式发布的生产环境,真正用户使用的环境。
注意,以上各类环境具体的部署方式以及资源要求,与各人士尽早讨论确定。比如:部署方式,部署架构与资源分配情况,性能与安全方面的要求等。QA环境要早早准备,不要影响QA测卡。对于UAT和PROD环境可以上线前一个迭代准备好就可以,通常客户现场在部署上有各种走审批,所以尽早做准备更好些。
4、测试策略
QA是项目质量的Facilitator,要邀TL和团队一起讨论制定测试策略。
第一、自动化测试策略
怎么定。如,单元测试、Api测试、端对端集成的测试框架与测试覆盖。提醒,最后了解一下客户方有没有测试覆盖的要求指标。比如,公司CI上的静态扫描工具的测试覆盖不低于70%。
第二,要与BA及客户讨论非功能性需求指标,制定相关测试策略。最常见的是性能、安全、兼容性
测试。比如,性能方面具体多大量级、多少并发、响应时间等指标要求。安全方面的要求有哪些,要覆盖到哪级别安全测试。兼容性测试
第三,到了客户现场,不论项目采用何种开发方式,敏捷也好、瀑布也罢。QA一定要注意,除了故事卡的Review、KickOff、SignOff、Testing等,必须要多看、多想、多尝试、多引导、多沟通。为的是做到所有的风险、问题、缺陷要尽早反馈、提前预防、快速响应
。
最后,质量人人有责,全团队的共识。
5、测试文档
国内绝大部分的客户方都有要求编写各类验收文档。比如,测试用例、缺陷分析、测试报告等,提前与客户方沟通。了解背景,沟通确定哪些能不写、少写、简单写。对于一些为了走流程或形式的文档,尽可能少投入团队太多精力,要把钱花在刀刃上。
比如,当时在某银行的客户现场,行内有要求,上线必须提交详细的测试用例、缺陷报告、测试报告文档,有审核。在我们敏捷开发模式中,重沟通,少文档,不会花太多时间去写这样的用例文档等。于是,找客户IT方负责人沟通,对方也很认同我们的观点。但由于行内规定,就采用简单高效的方式写、尽量不花费太多时间。最终,用Jira上的敏捷故事卡和缺陷卡直接导出(写卡时把相关属性填写好)。这样大大节省了团队在文档上的投入成本、也响应了客户流程上的规定。
6、与团队契约
在整个项目实践过程中,有一些必要的约束可以大大提高效率或降低风险,所以不防一试。比如,在项目上制定过KickOff公约和Desk Check公约等。
比如,真实经历,DeskCheck卡时,要么一上来IE功能挂了,要么环境没好,要么数据没弄,围了一圈儿人在那等。后来制定了公约,结卡成功率上来了,效率也提高了。
KickOff公约: 集齐BA&UX&QA, 阅读故事卡后,带着问题来开卡。
Desk Check公约: 准备好环境与测试数据,用IE11自测全部AC,集齐BA&UX&QA,再进行DeskCheck。
重构公约:临近上线不重构,如有特殊请联系BA&QA&TL,风险评估后实施。
7、持续集成
一定要尽早集成、持续集成。这一点容易被大家忽视,有的团队把集成放在最后,风险太大。所以,作为QA时刻关注尽早拉通,持续集成。
8、上线流程
QA别忘了上线流程也要落实。有哪些审批、约束等。
比如,某银行的上线流程要求提前一周PO发申请邮件。完成UAT验收测试后(提交测试报告),才能走上线审批流程,产品包与数据库部署分开走申请,审批最快当天完成、慢则两天。部署只能在晚上7点之后进行。所有的环节了解之后,确定上线流程表以及相关安排,与客户方拉通一遍完整的上线流程避免遗漏导致问题。
如:PO邮件申请上线 -> UAT验收 -> 定包 -> 提交验收报告 -> 上线审批 ->部署(应用+数据库+沙箱)-->上线验证-->发布。
提示:建议维护上线部署Checklist,虽然很多都已自动化部署,但还少不了有一些步骤涉及到人工参与,为了避免或降低上线失败的风险,部署手册与检查项很有必要。
9、线上事宜
上线发布之后,对服务进监控、对日志监控、对使用情况进行监控,发现问题及时响应。QA刚入场后,还没上线,还不急着线上QA的工作。但需要提醒团队某些事情要提前做。比如,有一次刚上项目,发现POC阶段的开发没有任何日志,两周后就要第一次试上线,没日志出了问题只能抓瞎,有时大家太忙容易疏忽一些事,QA需多想着多提醒。
10、质量意识传递、赋能
QA在项目中很关键一点是要传递质量意识,影响项目成员的质量意识不断增强。通过日常合作、交流或者分享Sesson,把你的知识与经验传递给团队中的每个人,培养大家的质量意识。人人都是QA、质量人人有责,这样的团队,项目质量还能不高?
对于入驻客户现场的QA通常还有个任务,不仅展现你的专业树立公司品牌,还要赋能于客户团队成员。除了多分享Session、多交流。在日常实践中,直接Pair也是很好的方式。
总之,作为质量的Facilitator,QA有很多事情要做。所有有利于项目进展与内部质量的机会,都不会轻易放过。加油吧 QA!