晚餐:敏捷测试以及其它问题

总是感觉需要学习的东西太多,所以喜欢参加各种技术聚会。我是一个非常好的听众。还刻西游记中佛祖座前的黄鼠、大鹏么?听也是得道的一种方式。:)

1. 引子

9.27,正是敏捷测试大师Janet Gregory来连授课的时候,被邀参与见面,并且能将自己的疑惑提出来,幸甚。因为英语不好,结果汉英夹杂的提问,多亏有李兄翻译。

我去年10.29日正式组建的这个部门,在近满一年的时候能够得到这么有益的指导,明年和以后的发展又多了新的稳定因素。

回来之后就想动笔。关联的内容太多,比如一想到某个关键词,比如单元测试,就想到我们的团队居然基本上还没有使用。还有一些新项目即将启动,又需要策划相关事宜,更让思路如同天马行空。一写起来就感觉,想的时候如同泉涌,下笔之后似若无魂。拖拖拉拉一直到现在(2011.09.30)也没有写完。

2. 抛砖

作为一个不到一年的新团队,我们经历了1,2,3,5,8…(哦,我们的发展过程好斐波纳切)的人员成长。要对新人灌输理念,又让给新人适应的时间。每来一个人,特别是有过传统开发方式的人加入的时候,调整和适应的痛苦都会影响整个团队。虽然开发方式/结果,客户的满意情况都还不错,我们一直以来坚持的无测试策略虽然省了成本,还是出现了一些问题。所以我们的问题是:

Q: 作为小团队,我们目前没有专职的测试人员,测试工作主要由程序员和用户来完成。在性能调整等方面我们还是需要测试人员的。

A: 现在有没有出现问题?如果没有出现问题,那就没关系。长远看来,没有测试是不可能的。
Q: 如何引入测试人员?比如计划引入一个测试人员,如何能让他在未来能够组建起一个测试团队?他是否需要具备一些编程知识?

A: 这个需要根据情况来定。测试人员如果懂得编程知识更好,这样沟通起来就更高效。提出的问题更有针对性。但是一个测试人员不提倡同时参与两个项目。两个项目的不同之处会影响他解决问题和工作的效率。
Q: 成本控制,我们在团队初期不会投入太多费用。

A: 支付:现在还是未来。
Q:  改进策略,是否可以让现在的结对编程程序员,进行角色互换进行结对测试?在一定的条件下,是否可以将比较适合的那个人转换为专职的测试人员?

A: 进行互换结对测试,可以。但是进行程序到测试人员的转换?他们的思维方式不一样,工作的重点是不一样的,为什么要这样做呢?

3. 聆听

每个人都是参与者。参与和了解意味着效率。

Planning Poker Card

这种方式对于预估项目规模很有意思。不过由于我们只是一个部门,搞得太欢乐对其它部门会有影响,这个可以在条件成熟的情况下进行。

4. 引玉

设计上我们采用的敏捷框架,给我们提供了一种特别有力的帮助,我们可以在项目初始,直接由UI设计人员将界面原型设计完成,采用DEMO数据(一般会耗时1周或2周),让用户对应用系统有最直观的认识。代码编写人员也方便进行编码工作。遇到的遗憾是有个客户认为程序已经做完了(当然这是沟通之过)。这种方式您认为有什么优缺点?

为了提高新程序员的入职效率,我们在实施一种 copy-cat learning方式的学习方法。将成型的类似程序提供给新的程序员进行抄袭,在强化他们编程基础的同时,也可以完成他们经验的积累。这样在我们差不多每周进行的技术交流中就可以提出更有效率的问题。在开发的过程中,结对的有经验程序员也可以逐渐将为何如此这样的编程理念传授给他们。采用这样的方式,一般一个编程新手可以在大约1个月左右就可以真正参与到项目中去了。这种方式您认为有什么优缺点?

在向客户提交程序的时候,Google大神的beta策略影响了我们,我们一直在尝试一种保持beta状态的交付方法。保证稳定的业务实现,我们可能提供简朴的UI给用户,并逐步在上面增加方便用户使用的实验功能,有些UI可能会提供稳定和实验两种方式。敏捷的开发方法,让用户有了更灵活的选择。这种方式您认为有什么优缺点?

5. 尝试

仔细分析当晚所听所学,对我们的团队改进非常有益。作为一个敏捷开发的探索者,个人认为它应该印证一种态度、是一种方式,而不应该是一种规则。它不会是是军规,第一,你应该如何如何,第二你应该如何如何。现在团队足够稳定。我们再做一些有意思的调整,看是否可以激活每个人的头脑风暴,让我们的效率更高,让每个人可以学到的更多/得到的更多。

我们的调整主要会集中在结对上。除了结对编程、结对设计,增加结对测试、结对发布。

BTW:

1. It’s really an amazing dinner. Learning so much from Janet Gregory(@janetgregoryca). Thanks to Jack Hou(@侯伯薇), Jack Li and all the others: Lijia Sun, Yao, SQA girl from NEU.

2. 前天(2011.09.28)还去看了一下敏捷的behavior testing tools Cucumber。ruby编写。

3. freemind

打赏

《晚餐:敏捷测试以及其它问题》有一个想法

  1. > copy-cat learning方式的学习方法
    想象起来应该很有效果。如果只是培育代码机器。

    >Google大神的beta策略
    这个也许是可有可无的。需求时常变化,体验时时更新。此为常理。保持更新速度就好,我想大概不必为概念所累。

    祝你更成功。

发表评论

电子邮件地址不会被公开。 必填项已用*标注