2015软件测试开发工作总结

转载地址
2014年底加入现在的测试开发团队，至今仍然在挣扎奋斗中，从几个问题和关键点入手总结下我的测试开发工作。

　　测试开发组的第一用户群体是谁？
　　2014年在TID质量大会听了章屹的主题分享，印象比较深刻的是他说的测试工具开发的第一用户群体是“开发工程师”而不是“测试工程师”。我也逐渐认识到了这点。
　　首先从质量决定论上来说，测试越来越左右不了产品的质量，或者说从一开始就没有左右过产品的质量。“质量是构建出来的，而不是测试出来的”，相信很多人都认同这个观点。当然我们身为测试工程师本身总是觉得自己的工作很重要，你们开发应该遵守规则，按流程开发，测试不过关不能上线。可是实际情况是什么样呢？常常是“测试通过要上线，即使测试通不过只要有没严重问题也要上线”。有人说这是个人职业操守的问题，我却感觉这是“存在即合理”的现状。一刀切的质量标准不适用于追求快速迭代的互联网产品。那么我们要么帮助测试工程师逐渐提前介入到开发流程中，要么直接服务于从项目一开始就影响产品质量开发工程师。
　　再从用户数量上来说，原来2007年在Gladon开发测试比是1:1，现在是4~5:1，或者更高。很显然如果服务于用户群体占多数的开发比服务于测试价值更大。
　　还有一点很重要，从工具文化的接受程度来说，开发往往发牢骚最多的是“工具真TM难用”，而测试往往在心里嘀咕“MD，又让我用一个新工具”。所以如果定位用户为开发，那么只要站在用户角度开发出切实业务场景又好用的工具就可以了。但是面向测试群体，你非要把一个新的工具使用强加到现有的工作流程中真是难上加难。就拿部署来说，如果我是测试，我给开发说一声“帮我部署个**应用”，总比拿一个本来不是很好用的工具费劲巴拉折腾半天仍然搞不定要好。
　　
　　最重要的是业务落地
　　流程上属于关键节点的工具，比如出包、部署、代码质量等等公司级别的工具开发组已经实现了。其他刚需的工具也大都有成熟方案或者开源工具了。那么业务团队真正需要的是什么呢？我们工具开发组可以做的是什么呢？应该是找到现有工具方案和业务团队实际情况之间存在断层的衔接点，真正和业务结合起来，服务于业务，这才是我们业务部门的工具团队的价值所在。重复造轮子是可耻的行为，不能说为了学习Jenkins的原理，自己开发一套相同的系统出来，我们可以弥补开源方案的缺点，比如确实实际业务场景的支持，权限系统与公司的对接，数据的整合等等。
　　
　　节奏一定要快
　　每个测试开发组的成员都应该真正去业务团队体验一下什么叫做996，尝试为了线上验证通宵熬夜的感受。参与过业务团队的具体迭代开发，面临真正的业务压力，才知道为什么如果不够快，就将面临生存的问题。而常常实际情况是，测试开发组慢条斯理做着与业务不怎么沾边的工具和系统，心里还在偷着乐，“还好我没在业务组做开发或者测试”。这样的结果只能是与业务脱节，逐渐边缘化。
　　
　　避免闭门造车
　　把外部的先进的知识和工具引进来，并把内部的实践经验分享出去。常常是我们吭哧半天解决的问题，别人早就有成熟方案了。或者大家都在说代码质量很重要，线上质量很重要的时候，我们仍然在紧紧盯住测试环境质量，并且死磕自动化测试。
　　而且不光要与测试同行交流，还要多和开发交流，深入了解现有系统架构及技术的特点，比如我们部门处于公司整体技术架构的哪个层面（基础架构、中间管道、还是上层业务），我们应该关注的质量重点在哪块（代码质量、架构质量还是性能稳定），开发和测试团队对应的痛点是什么，我们应该提供什么样的工具。还要和业务和产品人员多交流，了解现有系统的业务组成，分析不同系统及应用的重要程度和关注点，帮助产品和业务人员提供工具支持和数据支持。
　　
　　输出实践而不只是输出系统
　　很多工具和系统是结合实际场景使用的，比如持续集成系统，自动化测试工具，都是和工程实践紧密结合的。如果仅仅拿出来一个系统交给业务团队使用，往往结局是被废弃掉。应该首先找到试验团队形成系统与实践结合的案例，然后再给别的业务团队推广培训，才能够逐渐使用起来。
　　
　　重视数据目标而不只是功能目标
　　做软件开发的都或多或少有这样的特点，总想开发出足够牛逼的系统，拥有足够多的功能。常常定目标的时候说，“我这次要实现什么什么功能，下次要增加什么什么功能”。最后功能越累越多，系统却越来越没人用。我们是不是应该换一种思路，以用户使用量、系统稳定性、团队业务数据提升等指标来衡量我们的工作更好一些呢。
　　找到突破点优于全面平庸
　　人力有限的情况下，要想全面服务整个部门的业务团队，只会落到全面平庸的下场。因为每个业务团队的实际情况不尽相同，摊大饼把自己拖入泥潭的教训要吸取，不如聚焦于天使用户，首先满足他们的需求，其次再去考虑全面推广。
　　流程上也要单点突破，比如持续集成完整流程，很多团队都难以很好落地。但是如果换一种思路，比如A团队重视代码质量，那么就通过提供工具方案及实践案例可以帮助A团队实现代码质量目标，提高A团队这个用户的满意度。而不是一味要求团队必须全面实施持续集成完整流程，这样导致用户对我们敬而远之。
　　总结
　　测试开发的工作注定我们必须是创新型团队，无法按部就班去实现需求。没有人能明确告诉你确切的需求，需要我们不断去探索，去学习，去创造价值。