查看原文
其他

我看了几遍:中外两美女对话敏捷测试

The following article is from STTME软件测试技术方法与效率 Author 耿晓倩

对话:Lisa Crispin(左) 与 Christina Geng(右)

地点: Cocoa海滩,奥兰多,佛罗里达,美国


初次见Lisa注:《敏捷软件测试:测试人员和团队的实用指南》和 《深入敏捷测试:整个敏捷团队的学习之旅》的作者),被她蓝绿色的刘海吸引。她说,“年轻的时候我就喜欢颜色怪怪的头发但没有勇气做,后来跟自己说等我老的时候一定要做,现在我老了。” 然而,Lisa给我的感觉却是无比的青春活力,她时而开玩笑、爽朗大笑,时而严肃认真指正、批评行业怪现象。无论一起与她做测试研习会,还是吃饭聊天都很享受,她经常会旁征博引的给我讲很多有趣的小故事。


Agile开发在很多项目中备受争议,焦点之一是:如何面临快速迭代所带来的产品质量保障的挑战。向敏捷开发过渡中,软件测试如何适应新的开发流程是敏捷测试想要解决的问题。它包括很多方面,如组织、人员、流程、工具以及沟通、协作。Lisa和Janet在撰写书籍和制作网上课程的同时,她们也不遗余力地打造敏捷测试社区文化,让更多从业者受益并贡献于敏捷社区。


当然,并非所有产品开发都适合敏捷模型,那也并不在关于敏捷测试的讨论范围内。

(Lisa Crispin的著作)


开始


Christina Geng

你和Janet Gregory是敏捷测试的第一批传教士,写了著名的书籍 Agile Testing: A Practical Guide for Testers and Teams 和  More Agile Testing:Learning Journey for the Whole Team。敏捷测试的成功与敏捷开发的成功是密切相关。您认为成功地过渡到敏捷最大的挑战是什么?


Lisa Crispin

我认为最大的挑战之一是大家对敏捷的理解并不够准确。我认为一旦团队开始进行两周的迭代以及每天的站立会议,他们就会快速地适应。在敏捷下,我们必须要学习更多的新技能,其中很重要的一项是整个团队负责质量和测试。大家必须共同努力,在产品中构建质量,包括自动测试和手动测试,构建测试的基础设施,从而可以有信心频繁地交付增量迭代。这一点必须得到管理层的支持。团队中的每个人都需要参与一些测试活动。管理层需要激励团队学习测试技能,如果开发人员只是编写特性而不进行测试,那么敏捷方法很难奏效。


要求开发人员必备技能中包含测试技术会很有帮助,管理层需要将其纳入到他们绩效考核中。因此,我觉得有必要对管理人员进行测试方面的普及,通常情况下,他们对测试的理解并不很准确。很多开发经理和业务经理说想要高质量产品,但他们并不理解这到底意味着什么?为什么他们需要做出巨大的投资?质量最终会带来回报?如果团队太专注于速度,就会走很多的弯路,而且会走得越来越慢。只有团队专注于质量才能获得长期的快速发展。


几周前,我在mabl.com上发表了一篇博文(注:Lisa已加入智能测试创业公司mabl Inc),讲的是:如果团队专注于向持续交付转型,并采用DevOps文化,那将实现敏捷转型。当你必须真正专注于我们将如何交付的时候,一周两次,一周一次,也许更频繁。你就会意识到我们确实需要自动化测试,真的需要单元测试,确实需要尝试测试驱动开发,想要尝试所有的敏捷实践等等。我们应该从目标开始,然后做所有需要做的事情去支持这个目标。然而,对于敏捷的目标,它太模糊了。很多人都觉得敏捷的目标是做得更快,这是不对的。

Christina Geng

开发团队想要敏捷开发的原因之一是因为人们认为它将有助于更快地交付新特性。因为开始没有做好,往往到了开发后期,测试就会成为一个瓶颈。测试任务需要放到开发人员工作清单的优先列表中。

Lisa Crispin

是的。因为即使他们同意你的观点,测试也仍然不是他们的首要任务。所以这是为什么我说他们的管理层必须加入这个变革


我所在的上一个团队,开发总监知道测试自动化的重要性,我们有很多自动化测试,但我们在投入生产时遇到了问题,因为我们需要进行探索式测试。因此,他把测试技术作为开发人员的职业阶梯的一部分,让每个级别的开发人员都有一定的测试自动化和探索式测试的能力。他希望测试人员教开发人员探索式测试。我们经常通过与他们结对工作让他们知道测试人员是如何测试的。我们有时也帮助他们编写测试,并且提出一些问题:如果你这样做会发生什么?或者你应该在这里加一个负面测试用例?帮助他们形成测试思维。我们给他们做了一个启发式的小清单,还使用了伊丽莎白·亨德森的测试速查表(Elizabeth Henderson's test cheat sheet)。有时,我们也会写新的工具去帮助他们提高测试效率。这种方法很奏效,因为如果开发人员真的可以很早发现了那些很容易修复的bug,他们可以从中感受到多做测试的好处。

Christina Geng

有人说一个3岁的男孩可以在视频游戏中找到bug,制造公司的CEO可以在金融应用程序中找到一些问题,这说明每个人都可以做软件测试,测试没有技术含量。另一个说法是:如果测试人员可以做测试工作,那么比测试更懂技术的开发人员更加可以做?您怎么看?


Lisa Crispin

开发人员当然可以学习更多的测试技术做更多的测试工作。你知道Alan Page和Brad Jensen有一个AB测试播客(即:https://testingpodcast.com/category/ab-testing/),在过去的几年里,他们提出了所谓的“现代测试原则”。他们的愿景是:测试员成为教练,他们指导自己的团队,直到他们的团队不再需要他们。我认为这可以在一些风险较低的商业领域起作用。但对于那些与钱密切相关的金融服务或对商业或生活至关重要的任何应用程序,我认为你仍然需要测试专家去做深入的了解业务知识。你知道我已经做了30年的测试,我真的可以把所有这些技能转移给某人吗?不!我认为我们需要测试专家就像我们都可以学习一点关于用户体验设计或用户调研一样,但对于大多数应用程序,我们仍然需要设计专家。


Johanna Rothman在几周前的一篇博客文章中说:“在敏捷的早期,我们说 ‘好吧,我们都会成为通才,我们都会拥有所有的技能。’ ” 她说:“你知道发生了什么吗?我们的专家学会了如何协作,如何更好地沟通,如何互相传授技能。但专家仍然存在,不同的是他们不在是孤立无援的。他们与团队凝聚到了一起,这是关键。” 我非常同意这一点。我想我们是需要专家的。我认为专家们正在努力转移他们所掌握的技能,但一个人不可能什么都会。一个人没有足够的时间和精力去知道一切。

Christina Geng

也许大型分布式平台的开发是一个典型的例子。系统本身具有数以千种以及高度可定制的配置,开发人员花时间了解组件之间依赖关系已经是一个庞大而复杂的工程,像客户一样将所有的点连接在一起,对于开发一个特性或组件的开发人员来说是很难的甚至是影响特性的整体开发效率的,因为它需要深入场景分析和对产品特性有广泛的了解。

Lisa Crispin

领域知识真的很重要,我曾因为深入钻研领域知识而为软件质量贡献了很多价值。开发人员必须专注于他们正在编写的一些小段代码,那是他们必须做的。他们没有时间后退一步,去学习让事情发展成这样的整个业务。如果测试人员在,是可以帮助他们的。

Christina Geng

所以我们不应该期望开发人员做好所有的测试工作

Lisa Crispin 

没错!


Christina Geng

日积月累,自动化测试用例很容易变得效率低,运行及维护成本昂贵。你觉得什么样的测试自动化策略可以在持续发布中保持高效?


Lisa Crispin

开发人员必须进行自动化。同时,他们也需要测试人员在自动化方面提供帮助,并进行手动测试。我个人经验是,测试人员和开发人员协作会得到最好的结果。因为测试人员非常擅长设计测试用例,我们需要这些技能集合能够有效地结合在一起。现在很多科学数据支持了我的经验,这不只是某人的理论,它是一个事实。我希望这有助于说服更多的开发人员和他们的经理。当然,测试不只是自动化测试,因为产品不仅有服务级别的API测试,而且还有UI测试,测试要通过界面探索,然而这却是许多开发人员想要避免的。


Christina Geng

但是年复一年,自动化测试就会变得巨大而难以维护,测试结果也会开始变得不那么可靠。


Lisa Crispin

是的,这的确是一个挑战,我们也曾一直受困其中。我们需要确保我们有正确的测试以及足够的测试覆盖率。我们不希望说:哦,那个测试总是失败,我将忽略整个测试结果,这是非常危险的。有一个行之有效的办法是,如果那个自动化测试不重要,那就删掉;如果那是必要的自动化测试,就要让它变得结果可靠。我们应该对我们的测试有信心我认为分析和推敲出最小的自动化测试集合至关重要,这样我们可以腾出时间来,我们可以做基于高风险功能的探索式测试。其实,有些特性做手动测试更加有效。自动化测试和手工测试需要一个组合。对于持续交付,我们显然不能手动地快速完成所有测试,但我们可以使用发布功能切换之类的方法。我们部署特性,然后保持关闭,打开它只是为了我们进行测试,测试后我们可以将它打开给所有人使用。现在有很多技术可以用,同时,我们仍然必须让专家在需要他们的地方提供帮助,进行协作。


Christina Geng

我在testingindevops.org论坛中看到一个新词“DevTestOps”,您能讲讲这是什么意思吗?


Lisa Crispin

在我们刚开始提出这个词“DevTestOps”时,已经有人用过了。我之所以喜欢这个词,是因为对我来说测试是开发的核心。不知你是否读过2009年Jez Humble和David Farley出版的Continuous Delivery一书。在他们完成并出版这本书之前,让我做其手稿的技术评论员。我说:我的团队做过一些相关的演练,但我并不是这方面的专家。他们说:不,我们想让你审阅一下。我读后发现这是一本关于测试的书,整本书都是关于测试的。测试是持续交付的核心,Jez Humble非常支持我的说法。“DevTestOps”这个词有些人喜欢它,有些人说你在分离测试和开发,因为测试本是开发的一部分。这点我当然知道。其实,我是想让测试人员知道,我们需要学习未来的DevOps实践、DevOps文化、部署中的持续交付——这是软件的发展方向。在持续交付中,测试技能是需要的,同时我们也需要进化。测试人员最擅长的风险分析、识别模式,我们还会使用像Splunk这样的工具监控生产,我们会观察到其他人没有注意到的模式,这都是我们的思维方法和过程。我们可以使用应用的可观察性来查看生产中人们如何使用我们的产品的。很多测试人员如果听到DevOps这个词,都会感到害怕,因为他们看不到测试。有些人对成为测试自动化人员不感兴趣,但他们想做测试。他们会担心,在连续交付中我们有时间做手工测试吗?我们需要向他们展示,所有这些测试活动仍然是必须发生。我们只是在使用一些技术来帮助我们用不同的方式来做测试。所以这就是这个网站(testingindevops.org)的目的,网站上有很多链接,书籍,视频和播客。我们也会收到非常棒的访客博客帖子。我们也希望更多的愿意贡献这个社区的人提供访客博客帖子。我们将一起提高人们的意识,并让人们对此了解而受之鼓舞。


Christina Geng

由Alan Page和Brent Jensen创建的现代测试原则,他们称之为“敏捷测试人员的进化”。他们指出,有了这七个现代测试原则,测试人员可以开始从质量所有者转变为质量大使、交付价值,并改善团队的质量文化。您认同他们的思想吗?


Lisa Crispin

在很多业务领域,我认为这是不可能的。至少团队中有一名测试专家要做一些专业性强的测试。开发人员思考问题的角度不同,他们会在有限的时间内把注意力放在他们正在工作的有限制的事情上。这时,我们必须有人着眼于大局,所以我们需要测试人员。团队中的测试人员不一定需要很多。在我的上一个三十人的开发团队中,我们有三个测试工程师。在这样的规模下,我们不可能测试所有开发人员的所有输出,但我们可以帮助开发人员学习故事(user story)级别的探索式测试。测试人员可以在故事级别编写探索式的章程(Charter,指导探索式测试的执行)。当完成了足够多的故事的测试,测试人员可以与产品经理、设计人员或开发工程师一起,在更高的特性(features)层次上进行探索式测试。


如果团队的开发人员提高测试技能并且构建质量,那么团队就可以配置更少的测试人员。如果开发人员没有进行测试驱动开发或者没有自动化单元测试,那么移走或者减少测试人员的方法是不会奏效。即使我们在功能测试中进行完全自动化,通常也不能取代单元测试中的自动化。开发人员必须想要构建高质量的产品,事实上他们也确实是想。我知道每个开发人员都想提供高质量的产品,但是如果他们受到的压力只是为了让产品的特性上线。或者更糟,在下一个版本发布之后,他们再开始强化功能和增加自动化测试。这就像,我因为太忙于学习游泳,所以没时间呛水。我们不应该是质量大使,而应该是推动者。我们是帮助提醒每个人如何做测试和保证产品质量,然后帮助他们实现目标,让他们拥有各项技能来实现目标,这需要整个团队的承诺和诉求。


Christina Geng

您认为团队中开发人员和测试人员之间的健康比率是多少?


Lisa Crispin

没有任何一个设定的Dev:QA比例可以适用于所有团队。团队需要问问自己,我们面临的最大问题是什么?你遇到的最重要的关于质量的问题也许是:测试是瓶颈。那么,你就需要看看团队是如何做测试。你可以招更多的测试人员,或者招不同类型的测试人员。从2003年到2012年,我在一家金融服务公司的团队工作,这是一款高风险的软件。软件是用于退休账户的,与钱相关。这是一个很小的团队,但我们的表现令人难以置信。编写代码并不太难,但是要确保功能没有问题,并且每一个单独的边缘案例都没有错误,这是很有挑战的。我们说的是钱,必须精确到小数点后六位。如果你搞砸了,这是很难挽回的。我工作的最后一个团队是一个项目跟踪工具;如果他们的项目停工一段时间,没有人会有大麻烦,因为这对重要的商务影响不大。虽然问题会让人感到烦但它并不会造成很大的损失,所以并不严重。三十个开发人员只有两三个测试人员的另一个主要原因是,团队要有质量文化。在团队中,有结对编程、测试驱动开发,大家关心探索式测试。在这种情况下,有更少的测试人员是可以的。所以要看具体情况来确定。


Christina Geng

如何使用数据驱动来度量产品的质量?


Lisa Crispin

衡量质量始终是一个巨大的挑战。我一直在想这件事。Anne-Marie Charrett在这方面做了一些有趣的研究,但不同的图表在不同的领域会绘制出不同的质量图。其中一个有效地衡量软件质量的标准是:人们是否在使用这些给定的功能?如果他们不使用它,是因为他们不需要吗?还是因为它很难使用?什么时候他们会来尝试这个功能?对于新功能,我们最好持谨慎发布的态度。我们可以做一个薄片式的、最小可行的产品特性并将其推出,来观察用户如何使用它,采访使用者以获得用户的反馈。我发现Widget可以有很大帮助(我说的是基于网络的应用程序),用户可以点击Widget并给出宝贵的反馈。我们跟踪的另一件事是“愤怒点击”。有时候,生气的用户会疯狂的点击一个按钮。


我们团队的测试人员每周都会收集指标数据,例如有多少新的客户问题进来,有多少愤怒点击,不同功能的使用率是多少等,并将这些广泛的指标数据放在办公室的大显示器上。我们团队经常与客户沟通,特别是与新客户。昨天,我们团队与一家公司电话沟通,该公司对我们说,他们需要在移动设备上使用我们的应用程序。我们请了很多部门的人来听客户在移动端的需求。


产品经理了解特性的质量衡量指标也是至关重要的,如果一个产品人员来找我要一个新功能,我会问,我们如何衡量它在生产中是否成功?我们现在就应该知道衡量指标是什么。很多时候产品人员甚至不能回答这个问题。


Christina Geng

你认为像人工智能和机器学习这样的技术可以帮助我们测试吗?


Lisa Crispin

mabl正在使用机器学习进行视觉检查。机器学习一定数量的运行,如10次运行,它可以识别屏幕的哪部分是静态的,屏幕的哪部分是不断变化的。一个零售网站,他们可能使用弹出式横幅为一个新产品做广告,机器学习知道我要忽略页面的这部分,因为它总是不同的。如果页面的静态部分发生变化,它会发出警告。它允许用户读取基线,如果有问题,就需要介入进一步调查。


机器学习做测试不是万无一失的。我认为它确实有助于节省时间。另外一个例子是页面加载时间,机器学习算法可以给出平均页面加载时间,如果发现数据上升了一定的百分比,就给出一个警告。然而,机器学习非常依赖于你训练它的数据,如果你给它错误的训练数据,它可能是危险的,因为你可能会得到错误的结论。所以在我们使用它,并广泛依赖它之前,我们必须对它有更多的了解。我们必须更好地知道如何用正确的数据训练它;考虑所有的可能性,尽量避免它的危险性。软件测试不像自动驾驶汽车测试影响那么大,我们产品的主要部分是启发式的和一些代码。每个人都希望AI能解决我们所有的问题。我们的能力也正在朝着这个方向迈进,很多机器学习工具可以基于数据提供用户使用信息,例如真正的用户在应用程序中做了什么。毫无疑问,机器学习可以分析并了解用户界面中最有价值的部分。我们的测试覆盖范围怎么样?测试用例是否对这些页面进行结果验证?甚至可以自动生成高可用的测试用例。机器学习将对许多类似的事情有所帮助,但我们需要清醒地意识到我们使用的不是魔法而是我们的工具。我为机器学习带来的可能性感到兴奋。


Christina Geng

有一些研究已经证明了我们可以使用人工智能来做一些软件开发工作。


Lisa Crispin

开发人员告诉我,人工智能更有可能做开发人员的工作,而不是测试人员的工作。因为当我们使用机器学习时,我们必须使用测试数据,以了解它是否验证通过,可以进行训练。我们必须测试机器学习算法。给一台机器两万个某种编码方法的例子,让它学习如何编码,这是可行的。但是,你能给机器一个人的判断吗?


Christina Geng

最后,请您给一些刚刚做测试的人一些职业上的建议。


Lisa Crispin

我认为重要的是要知道你的贡献到底是什么,是发现产品缺陷吗?所有这些都可能是沟通问题。产品需求没有很好地表达最终想要的东西,或者开发团队误解了业务的需求因此看起来像是一个缺陷?这都是沟通不畅的问题。我听过很多人说软件开发是20%的编码技能、80%的沟通和协作,也就是所谓的软技能。花时间在你的软技能上,因为它们是最难学习的,比如沟通,倾听,观察技能,批判性思维技能,以及很多其他方法来做到更好的沟通。你还需要意识到你的无意识偏见。测试人员非常容易测试我们期望看到的内容。我们必须能够注意到我们事先没有预料到的事情,了解一些未知的东西。保持思考对于测试人员来说是必不可少的。相对而言,不要过于担心你的技术能力,因为它更容易学习。

Christina Geng

谢谢你,我想这些建议并不只是为新测试者,对所有测试人员都是通用的。

Lisa Crispin

我想是的。我们参与学习测试自动化,或者编码,或者学习很棒的技术。然而,我可以教任何人如何编写代码,但我不能教别人如何批判性地思考。我可以给他们做练习来改善思考性的技能,然而,能讲清楚如何做到这一点并不是那么容易。


Christina Geng

非常感谢Lisa,感谢你的宝贵时间与分享。


结束


Lisa Crispin 简介

Lisa Crispin 是一名测试倡导者,就任于MABL,致力于探索软件社区测试中的领先实践。Lisa Crispon与Janet Gregory合著的书籍有:“敏捷测试简要” (Agile testing Condensed:a Brief),“更多敏捷测试:整个团队的学习之旅”,“测试人员和敏捷团队的实践指南” ,“敏捷测试要点视频课程”,“敏捷测试的整个团队方法”,Lisa被同行评选为敏捷测试领域最具影响力的人。更多请访问www.lisacrispin.com和www.agiletester.ca

Christina Geng 简介

从事软件测试及管理工作,就任于Splunk旧金山总部软件测试总监;喜欢与行业中的前辈学习交流以避免井底观天、闭门造车。

参考:

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存