测试管理分享

针对目前公司测试部门管理比较混乱，根据以往经验，现分享下针对公司测试部门管理实施方案

目前测试部门使用的是“人海战术”，每次发布版本的时候，都是所以的人全部上，这样会增加测试风险。

同时上线后第二天面临着测试部门没有后续跟进上线后的问题（第二天测试部门休息）

现给出以下建议：

1.测试工作方法改进：

调整团队的测试工作方式，实行端到端测试，就是一个人负责一个端的所有方面的测试工作，如：web端 手机端又分为ios端Android端，我相信产品端的质量肯定会有所提高，同时团队成员针对端的能力也会慢慢提高起来，这是因为以前大家做的事情都太乱了，我们还不如先专注做好一个方向，在去做其他的事情，所以我就想到了使用端到端的方法。

2.推广自动化测试。

在实行端到端的方式后，在这期间我们把web端，ios端和android端的自动化测试也推起来，辅助我们完成回归测试，这样会节省很大一部分的时间，同时后期要求每一端基本都是独立一人去完成。这样大家不仅能力提升了，产品的自动化测试也得到了推进，巩固了测试的环节，显然，持续一段时间，产品的质量也能得到提升

3.开展敏捷测试团队的模式

目前从升级的邮件中我们可以看出，每次升级项目都很不确定，这看起来有点不像互联网敏捷团队的模式，但如果我们是以一种轻便地方式来实现，产品主大局，产品需求一般是阐述大概要做什么，但很容易会漏掉细节，谁补，测试人员，不是总说测试比产品经理更了解业务吗，所以用例评审的时候我们就可以体现细节的问题，用例编写和研发实现的周期调整为同期，测试左移，用例编写完成后用例评审，我们也不是说一条条用例地看，对于敏捷，快速迭代，这不是个好办法，那用什么，xmind是个好工具，产品经理能用来列需求，测试也就能用来列测试关注点，测试关注点覆盖产品需求路径，同时提出产品需求未描述清楚的地方，并且通过易用性，功能性，可靠性等一些方法也提出关注的细节，这样既能补全需求，也能前提告之研发哪里有坑，同时也巩固测试的一个关注点和范围，一举多得，可能这说成用例评审有点怪，叫测试关注点评审更好，随便，为解决问题而设计实行适当的方案或流程就好，与此同时，那为产品作版本灰度上线方案，设计灰度的范围以及要关注的功能，同时版本上线之后，做好和客服的对接，做好线上问题收集和整理。

4.提升测试团队人员技能

目前公司测试人员都是通过纯手工测试来完成，我相信在未来的3年内 纯手工测试将会被自动化来替代，所以应该提升整体测试团队的技能，团队里面坚持每月至少一分享的习惯，但不是瞎培训瞎学，脱离业务的技术方案都是炫技，华而不实，我们培训都是为了解决当前工作上遇到的问题的，都是学最能解决问题的技术方案，通过分享，每位小伙伴在培训之前都或多或少去了解培训主题涉及的内容，之后培训的时候大家一起提出不同的看法和见解，经过自己的思考接受学习也是有效。