文章

如何保证质量?

现在,我依然能碰到一些敏捷开发者和团队,他们在项目中还未采用自动化实践,比如微测试,自动化集成测试和集成测试。这种现象存在主要是因为三种原因:

1.开发者没有看到它的价值

一些开发者技术好经验足,他们很少出错,自动化测试对他们来说是个额外的负担。当一些初级开发者在忙着改bug时,他们往往在做更重要的事,比如把他们的技术应用到系统架构上。如果团队中有这样一批开发者的话是很难实施自动化测试的。 Read more

画地为牢,还是勇敢开始?

 

scrumcn1387164103

Q:交付压力太大,根本没时间学习TDD,也没有时间做UT,如果要做,需要在排期的时候留出足够的时间!

A:写出有质量保证的代码,RD自己就是直接受益者,在投资收益关系如此清晰的情况下,你为什么还在犹豫?写不写UT,要不要用TDD的方式开发,要不要改变当
前edit and pray的状态,追求cover and test,是RD的个人追求问题,不是一个交付问题。

另外,需要反思,是交付压力太大了,还是交付能力太差了。

Q:需求变化了,功能代码要重写,测试代码也要重写?岂不是双重浪费?

A:功能代码不再适应当前的需求了,可以在测试代码根据需求改动后的第一时间收到反馈,这是不是一种浪费?如果是,那么,无法及时获取反馈,而产生的线上故障算什么?

 

作者:李大桃

原文地址:http://hi.baidu.com/whoistonyli/item/0d4959e2cc0f2afdea34c928

Scrum中的测试:人少事不少

导读:Scrum团队以小著称,团队中一般只有一到两名测试人员,那么这一两名测试人员在Scrum团队中又是如何开展测试工作,起着什么样的作用呢?

Scrum敏捷开发有一个明显特征就是重团队,轻部门,每个团队里面包含了开发、设计、测试各种角色,Scrum团队以小著称,团队中的测试人员一般只有一到两名。

在传统的瀑布式开发 中,测试人员经常因进入测试阶段的条件不满足而需要较长的等待。而在Scrum敏捷开发中,测试人员需要尽可能早的开展工作,“等待”在Scrum开发的测试中已属一种错误概念。

测试人员应具备三方面的能力:编码,测试和分析。不同的阶段对测试的要求不同,在功能测试中偏重编程能力,在系统配置测试中偏重分析能力,Scrum团队中的测试人员需要将这三种能力融会贯通,才能适应迭代过程中的诸多变化。

测试是软件开发中必不可少的一部分,那么Scrum团队中测试人员又要如何开展测试工作呢? Read more

关于测试和测试人员

本文的作者Sriram Krishnan是一名程序员,曾在Yahoo和微软工作过,开发过很多软件,曾被纽约时报报道,写过一本书,本文是他的一篇博客。

这些年来,我对测试工作、测试人员,以及整个软件质量管理体系形成了一些明确的观点。受一篇关于Facebook的测试的帖子的启发,我想把这些写下来,用以拿给人看。有些观点是有争议的。事实上,即使在交谈中稍微表现出这样的看法,都会招致人们的鄙视。

大多数的开发团队并不需要一个独立的测试角色。即使有一个,他的所有的开发时间比上所有的测试时间应该 >20:1。证据呢?光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook,还是30年前最初的NT团队,很多伟大的产品都是出自没有或很少测试人员的团队。 Read more

Scrum交互瀑布式测试

有时候,在Scrum中对用户故事进行测试的时候需要在最后进行一些瀑布式的步骤。在这里我所阐述的情景是基于这样一种情况:在Scrum流程中,需要在Scrum流程的最后阶段进行一些顺序性的步骤来对所开发的功能进行测试。这些步骤在我们的组织中是必须的,而且这些步骤是为了产品发布的瀑布式流程,因此,我们不得不处理在Scrum中进行瀑布式流程的情况。然而,据我所知,遇到这种情况并不只有我们。我们把这种情景叫做“Scrum和瀑布式的交互”(详见Michele Sliger的《Bridging the gap: Agile projects in the Waterfall enterprise》)。我认为这种情形应该是很常见的,因为在一个组织中Scrum的实施一般是循序渐进的,也就是说会存在Scrum和瀑布式同时存在的时期。 Read more

如何进行测试自动化的成本估算

对于自动化测试团队而言,容易犯的一个典型的错误是:没有选择恰当的测试用例来实现自动化。
大部分测试自动化项 目失败的原因主要归咎于被测试应用程序的快速变化、不恰当的测试用例、不可靠的框架、脚本编程的问题。分析这些问题的根源,我们可以看到,自动化测试必须 分阶段逐步开展,而不能局限在某个阶段完成自动化测试。因此,建议自动化测试从选择那些重要的、合适的测试用例开始,然后慢慢地扩展到其他方面。这样会带来较低的维护成本,但是实现更重要的业务价值。
那么如何选择合适的测试用例呢? Read more

敏捷测试需注意的五种危险行为

如果开发团队采用了敏捷方法,那就意味着程序员需要做更多的软件测试。然而,这并不是说软件测试人员就没事做了。他们需要调整,并学会与以往不同的测试方式。

DragonFire公司的顾问Janet Gregory认为,对用户需求的测试尤为重要,“除非经过测试,否则不能认为任何业务需求已经完成。

STAREAST测试展会(STAREAST Conference and Testing Expo)上,Gregory讨论了“新晋敏捷测试员的危险行为与陷阱”,并解释了敏捷测试员所应做的工作。她指出软件测试人员经常做出的危险行为,这些危险行为可能带来的风险,以及如何规避这些危险和风险。 Read more

敏捷测试的启示

最近,好像整个软件开发界都在讨论和实践敏捷方法,做什么事情都要敏捷,开发要敏捷,测试也要敏捷。

什么是敏捷?

敏捷宣言:个体和交互比过程和工具更有价值;能工作的软件比全面的文档更有价值;顾客的协作比合同谈判更有价值;及时响应变更比遵循计划更有价值。-

敏捷开发是递增式的、迭代的、不断调整的开发模式。在敏捷开发中,工作被分解成“故事”,也叫特性或用例,组合成任务分派给不同的程序员。敏捷开发讲求合作,结对进行编程,避免个人拥有专门的知识,代码属于项目组共有。在敏捷开发中不存在回退,讲究持续地集成,单元测试(通常使用测试驱动的开发方式),持续地进行回归测试。

敏捷测试是指在敏捷开发模式中的测试。敏捷测试包括单元测试(通常由程序员完成)和可接受性测试(通常由测试人员完成)。 Read more