Automating Acceptance Testing in an Extreme 01

angelcc216

Lisa Crispin
Senior Test Engineer
Tensegrent
6100 Greenwood Plaza Blvd
Greenwood Village, CO 80210
USA
1.303.268.4621
lisa@tensegrent.com

Tip House
OCLC, Inc.
www.oclc.org
6565 Frantz Rd.
Dublin, OH 43017
USA
1.614.761.5139
tip_house@oclc.org

Abstract


In eXtreme Programming Explained [1], Kent Beck compares eXtreme Programming (XP) to driving a car: the driver needs to steer and make constant corrections to stay on the road. If the customer is steering the car, the XP tester is navigating. Someone needs to plot the course,establish the landmarks, keep track of the progress, and perhaps even ask for directions.

This is all complicated by the need for speed.XP testers have to drive in the fast lane. To be the windshield and not the bug, you need a lightweight automated test design and lightweight test tools.

sss666

To be the windshield and not the bug-瞎翻了,

在极限编程的(理论)解释中,Kent Beck比较了XP与开车:司机需要握好方向盘并不断修正,以保持车行驶在马路上.如果客户正在决定目的地(注:决定着软件需求),XP的测试员在奔向目的地,那么需要一些人先去试验下路径,建立路标,跟踪进展,还要去问路.

这对于速度需求来说是个最大的麻烦.XP测试员不得不快速地奔跑在小路上.或许你需要一些轻量级的自动测试设计和轻量级的测试工作,它们会成为你的挡风玻璃而不是麻烦.


评论:
1.虽然过程改进是比较凝重的,但XP无疑是过于单薄地站在了编程人员的利益立场上,或许解决不成熟的过程改进靠着淡薄的立场意义不是很大,认真研究过程的概念和实施就不会那么凝重了.未来的软件过程将应该结合过程改进和XP的各自优点才好.
2.整个论证过程缺乏基本的三段论的严密性,随便看看尚可,不可深究,呵呵,更象是思维简单之人的白日梦幻.