测试团队的两个困扰，一是测试资源不足经常成为项目团队的瓶颈；二是测试对开发技能了解不够不能深入保障质量。而在业界也早就听说FACEBOOK和GOOGLE的开发测试比很高，具体的测试执行工作都是开发完成的，测试团队的职责是发展测试业务。
那么互联网测试真的适合这样的模式吗？公司内部直接套用FACEBOOK和GOOGLE的方式可行吗？我相信每一个测试团队管理者都会摇头说：不一定，因为每个公司的文化，产品形态，团队的成熟度都不一样，这就会影响测试工作的开展方式和测试业务发展的摸索是不一样的。
那么我们是如何发展测试业务和保障业务质量
我们在开展的研发实践是scrum，scrum中有很多关于开发同学如何在scrum中开展工作的实践案例， 确实scrum给我们带来了非常大的改善，我们吸收了其中的一个精华就是我们把自己作为产品的主人。
Scrum实践的三个特点，这三个特点是结合Agile Value和Agile Principles以及我们项目团队的实践获得的：
一：自我价值，通过数据化运营指导大家认可同一个标准的价值，通过采集产品使用过程中用户的行为和市场反馈的数据来改善需求，增强团队的Owner感和成就感；在做产品时遵循做60%（核心功能）的需求，40%（锦上添花）根据数据反馈决定是否继续； 数据波动直接反应每次sprint发布对产品的影响，功能用户是否喜欢，团队成员成就感增强；
数据化运营会渗透在Scrum的各个过程中：头脑风暴-确定目标；产品会议-细化目标；站立会议-跟踪目标；回顾会议-复核目标
二：透明，工作透明可以帮助我们建立多团队之间和团队内部的信任，会让产品进度可控
三：沟通，面对面的沟通是最高效的方式，所以我们必须坐得近，这样我们的站立晨会会更高效的开始召开，产品会议也是不需要繁琐的预订会议室可以在座位上搞定，有时候头脑风暴也可以瞬间开展和落实。
……………………
查看全文请点击下载：http://www.51testing.com/html/56/n-811856.html
我们在实践中提出开发自测，人人都是测试，来解决在scrum的开展过程中开发和测试在保障质量方面的困境。
一自动化回归体系，开发自测后由开发同学去建立这个质量保障回归体系，如果开发代码可测试性太差直接影响到开发建立质量保障回归体系，会直接让开发愿意改善产品的可测试性；并且开发会切身体会到重复手工回归的痛苦和代价之大，改变不愿意投入时间做自动化回归体系的困境。测试做开发后会从开发的角度思考是自动化回归在哪个层次上建立，用什么方式，用什么工具建立，并且随着产品的演变自动化回归体系必须进行改变，越来越适应产品的发展。
二记录和文档，开发自测时会很羡慕为什么测试这么容易就发现了bug，而开发投入了几倍于测试的成本却没发现，借此机会可以把测试团队的TC编写方式分享给开发团队；而开发团队在写TC时必然会发现不做记录和文档的弊端，难受了就一定会改变原先的看法；测试做开发后也会改变原先任何内容都要文档的习惯，会对文档进行精简，只有最适合的文档没有最好的文档。
三提升测试技能，开发自测后开发承担了质量保障的职责，而测试就可以有时间去承担质量提升的职责。质量保障是指采用已有的质量方法去保障产品质量，质量提升是指创新更好的质量方法去保障产品质量。
四开发自己做自测时效率低，开发自测后开发承担了质量保障的职责，测试就可以有时间去培训和培养开发的质量自测技能，测试就有时间发展更好的质量方法传递给开发，开发自测效率自然就可以提高。
开发自测如何起步：首先功能测试同学分离出“常规测试工作”和“专业测试工作”，“常规测试工作”由PD，开发自测，运营验收完成，“专业功能测试工作”由功能测试同学来负责。目前我们也是在摸着石头过河去分析什么是专业功能测试工作，这样功能测试同学的瓶颈可以解决，质量也得到保障，效率也得到保障。其次功能自测做的好团队，功能测试同学轮岗做开发+专业测试工作，能提升自己的开发技能，把开发技能和原功能测试技能结合，去摸索出新的测试方法去适应开发自测。
……
查看全文请点击下载：http://www.51testing.com/html/56/n-811856.html
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
