培训元模式最近在帮客户设计一个微服务进阶版培训的材料,整理的过程中我意识到这类事情我已经做过好多次了。比如在ThoughtWorks的P2能力建设项目,3周3页面工作坊等等,我觉得应该将设计课程/设计培训中的模式、原则和实践都提取一下,形成一个元模式(即关于培训的培训)。一个培训中的活动,按照时间顺序可以分为三个步骤:设计培训内容培训前期准备培训中的一些实践设计培训内容根据经验,只有那些正好处于瓶
2016-11-14/3300 人阅读/9 人点赞
聪明的测试经理在自动化测试工具选型时,会首先做些小规模的试验,然后根据综合性的标准来做选择。通过试验使其能更加明白管理和应用好自动化测试工具也是非常重要的。成功的工具选型并不能保证其在公司内成功的运用。大多数的公司买完测试工具后,都只是成为纯粹的摆设或者说“案例”,仅仅是由于某种或其他原因,导致公司无法从投资中获得预期的效益。相比工具运用起来所需要的内部成本,购买工具的成本仍然是相当小的。测试管理
2016-11-13/4061 人阅读/6 人点赞
接上篇《用Selendroid做手机自动化测试(一)》http://www.testwo.com/article/7973.1.3.上下文切换正如上述描述,Selendroid可以使本地和混合的应用以及手机web自动启动。当一个Selendroid测试启动后,本地模式会默认被激活。可用的上下文可以通过以下检索:selendroidDriver.getContextHandles();当一个webv
2016-11-11/4174 人阅读/1 人点赞
几年前,我的团队从瀑布模型转到敏捷模型,现在转到DevOps。对企业而言,在生产环境一天多次部署新软件,最具挑战性的转型问题之一是需要革新测试。在持续部署和集成的时代,没有太多时间让QA团队发现问题并踢给开发人员。因此在开发结束后,产品上线前去测试程序的时代已经过去了。在这段走向DevOps的旅程中,我想出了一个非常简单的框架,并且改变了我对测试的看法(然而我的主要使命是产品经理)。从功能测试角度
2016-11-10/6082 人阅读/0 人点赞
网站:http://selendroid.io版本:0.11.0系统环境要求:已安装Java和AndroidSDK授权&定价:Selendroid项目已经被Apache2.0License授权支持:GoogleGrouphttp://groups.google.com/group/selendroidSelendroid是一个自动化测试框架,可以跑遍原生Android、各种应用(APP)以
2016-11-09/8314 人阅读/10 人点赞
在我写这篇文章时,首先进入我脑海的是CemKaner的话-“最好的测试人员不是发现缺陷最多的人或者让最多程序员尴尬的人。最好的测试人员是让最多的缺陷得到修复的人。”那么-发现最多的缺陷和让最多的缺陷得到修复这两者之间的区别是什么?难道不是很明显记录在缺陷管理系统里的任何缺陷都应该被修复吗?答案是否定的。有很多因素比如推广产品的时间,日程表上完成项目的时间,开发在不切实际的紧张日程中工作等。迫使公司
2016-11-08/6625 人阅读/7 人点赞
本文首发于InfoQ:http://www.infoq.com/cn/articles/QA-in-Production-practice2015年11月ThoughtWorks发布的技术雷达提到一个新的主题——产品环境下的QA(QAinProduction),2016年4月再次提到。这个主题第一次出现在技术雷达,就深深的吸引了我,当时我就给测试团队成员转发了这个内容,但同时脑子里也产生了这样一系
2016-11-03/2915 人阅读/0 人点赞
敏捷测试人员通常被称为质量分析师、SET、测试工程师和QAlead,以及其他一些名称。我已经做了一段时间的测试了,下面我将基于如何在敏捷团队中做好测试分享一些个人观点。在本文中,将用QA来代替敏捷测试人员。即使在敏捷团队,大多数人也会把QA当作一个独立的角色使之与其他团队成员区分开来。我认为这是一个过时的概念。QA和开发人员的区别在于思维方式的不同。那么QA之间又有什么不同呢?QA可以分为三类:业
2016-10-30/3498 人阅读/6 人点赞
UncleBob2014年5月1日我想念JimWeirich。我想念他的笑,我想念他的好脾气。最重要的是,我想念他去年和最近几年教我的东西。我感到如此失落。去年Jim做了一个叫“DecouplingfromRails”的演讲,讲解了怎样去重构一个Rails框架APP,从而从Rails框架代码解耦事务逻辑。这个演讲很精彩。如果你有时间听下这个演讲,它将会给你带来很多倍的价值。这个演讲的最后时刻Jim
2016-10-29/2975 人阅读/2 人点赞
QA角色-它到底是什么?我已经见到过好几次,那些打算用敏捷开发的公司将项目里做自动化测试的QA角色,仅仅视为一个瀑布模型的测试人员。我的意思是因项目需要做手动测试的人,也会看到测试代码(当然后者取决于很多因素)。在我看来,这种描述对我所认为的QA角色在广度和深度上是一种伤害。我经常花费相当多的时间跟客户解释这个角色的其他方面,以及每一个方面带给团队和产品的价值。这样解释了几次之后,我发现做一张(只
2016-10-28/3878 人阅读/3 人点赞