【敏捷】7.showcase,开发中必须引起重视的小环节

有人说,测试者来自火星,开发者来自金星。这是因为软件测试员和软件开发者就好比一对冤家,里面的缘由说不清也道不明。开发代表着创造,而测试则代表着摧毁,因为测试的目的就是以各种方式不断地从开发出的产品中发现大大小小的Bug,长此以往,开发者认为测试者是在故意找茬,两者的矛盾慢慢就会产生。


    敏捷之前项目中也有开发和测试,就如上文所说矛盾不少,比如测试测出一个bug,提单给开发,开发看了觉得这不是一个bug,实际业务过程中根本不会有这样的操作方法。还有测试提了一个问题单,开发在下面回复已解决,测试回归问题单的时候发现这个问题还存在,就质问开发这个问题没有解决还存在,开发肯定会说这个问题我已经解决了,是不是你的程序版本不对,重新构建一次,测试重新获取最新程序还是如此,开发因为任务重,同一个问题老是提过来肯定就会觉得烦,这样来几次就有可能吵起来。反正到最后开发觉得测试能力不行就只会找茬,真正的问题没有测出来,尽纠结一些无关重要的问题。而测试觉得开发的功能质量不行,不支持他们的工作。

以前并没有独立的产品经理来写需求,一般都是开发人员兼写需求,然后给测试人员测,当出现需求方面的理解不一致的问题,肯定都是开发人员更有理,就算测试人员找到几个不合理的需求,开发人员通常也不会虚心接受,反而觉得是在找自己的茬。所以在团队中独立出来产品经理负责所有需求是很有必要的,这样产品经理、开发、测试三者之间形成三足鼎立是比较好的局面。

一般来说测试人员都不会自己从SVN下载代码编译生成程序,然后进行测试。而是开发人员把编译好的程序和升级的数据库脚本拷贝到服务器的公共文件夹,然后测试人员再从服务器拷贝下来,数据库脚本在测试库上执行,经常会出现开发人员漏拷程序文件和数据库脚本,这样测试的结果肯定失败,然后开发找了半天原因发现只是漏了某个程序文件,然后就再循环一次。如此方式双方协作的效率很低,浪费了大量时间。

还有就是开发在完成功能后,并没有仔细进行自验证,只要代码编译通过了,一些明显错误没有修正就丢给测试去进行测试,那测试随便点两下系统就走不通了,只好打回给开发,一个需求测试用例跑完得反反复复好几次。

所以开发与测试之间要想好好协作,得双方需求理解一致、运行程序一致、运行环境一致、数据库一致,还要解决测试人员获取测试版本的方便性。

为了保障开发和测试对需求理解一致,我们在敏捷过程中通过计划会、测试用例评审和开发ShowCase这几个关键活动保障。计划会中产品经理讲解需求,开发和测试都会参加,如果需求理解不一致的地方就马上沟通由产品经理把关。到测试用例评审的时候,需求细化成一个个测试用例,这样让开发和测试进一步深化理解需求达成一致。到开发完成功能给测试Showcase,测试再一次核对开发实现功能与需求是否一致,明显不一致的地方当场指出来,等开发人员修正后才提交给测试进行测试,这样就基本能保证测试一次性就能跑完这个需求的所有测试用例。

运行程序、运行环境、数据库保持一致,这个靠手工的方式是很难不出错的,最好是通过一些工具来保障。我们团队是使用Jenkins来做持续构建,开发人员完成功能开发,然后提交代码到SVN,Jenkins检测到代码库变动,自动拉取最新代码进行编译构建、发布程序,测试数据库也自动还原成与开发数据库一致。

我们团队ShowCase的具体过程是这样的,开发完成功能提交代码后就通知测试进行ShowCase,这样时候持续构建已经生成了最新的环境,然后开发在测试环境上向测试人员进行功能展示,开发会按照需求把自己开发的功能都详细演示一遍,如果演示顺利通过测试人员则回到座位进行用例执行,如果演示没通过开发人员则继续修改代码完善直到演示通过为止。为什么开发一定要在测试环境上进行ShowCase,因为如果开发人员用自己的代码进行演示的话,还是有可能会出现代码效果与自动构建的程序不一致,所以为了避免这种情况,开发最好是在测试环境上进行演示。同样测试执行用例后产生的BUG,测试会提问题单,问题单要有详细的操作步骤与界面截图,然后开发人员解决BUG后要对此BUG进行根因分析,是代码逻辑错误还是需求理解问题,方便以后对BUG进行分析。BUG解决完后打回给测试的时候,开发也要进行ShowCase。

总之,现在觉得团队中开发和测试之间的关系还比较好,协作也很流畅,现在看来确实还是方法不对,虽然知道问题的原因但苦于找不到对症下药的办法,如果你的团队中也有类似情况可尝试一下ShowCase这个方法也好。

敏捷开发系列文章目录

时间: 2024-10-11 00:20:00

【敏捷】7.showcase,开发中必须引起重视的小环节的相关文章

敏捷开发中的10大错误认识

敏捷开发中的10大错误认识 原文:http://www.computerweekly.com/opinion/The-top-10-myths-about-agile-development 作者:Peter Measey 译者:张某人ER  http://blog.csdn.net/xinxing__8185/article/ 摘要:对于快速发展的敏捷软件开发领域,本文将对其最常见的错误认识进行分析. 在如今全球市场的背景下,如何可以灵活变通,对于一个企业来讲,已然变得至关重要,因此,IT系统

让敏捷工具在敏捷开发中发挥高效作用

敏捷软件开发绝不再是一个新名词了,但理解还是时时有偏差.敏捷宣言中的第一条“个体和互动高于流程和工具”,有人就误读为“有了沟通,一切都迎刃而解” ,因此花费大量精力整顿团队合作,却轻视了工具(技术).其实宣言中的意思只是想强调个人和沟通更重要而已. 实际上,既然是软件开发,在所难免得面临工具的选择,而且很多优秀软件实践离开强有力的工具支持都玩不转.在如今的软件开发世界中,工具(这里谈的是软件工具)层出不穷,数不胜数,那么到底该怎么去选择适合的工具呢? 本文将根据我十几年的企业级软件开发经验给出一

张左峰的歪理邪说 之 对于瀑布式开发和敏捷开发在网游开发中的应用

本周小孩送回姥爷姥姥家,终于有时间更新一下自己的微博了,三年没更新了,我真TMD懒惰!我错了....这次努力更新一些东西 有些人问我,为啥不去一些大点的微博站写这些内容.我觉得没有必要啊,反正早晚都会被搜索引擎爬到,哪里都一样. 本文纯理论,是一个思想指导,你完全照搬,你就输了....尽可能写的雅俗共赏一些,一起研究学习进步! 正文开始.....(哪那么多废话...果然人老了) 首先,我们要明确两个概念 瀑布式开发:瀑布式,顾名思义,自上而下,连绵不绝,稳步推进.瀑布式开发,是一个我们最常规的开

传统的项目经理在敏捷开发中怎么弄?

非常好的一篇文章,为了自己学习和方便大家,翻译了一下~~ Who handles conventional project manager duties in agile development? 在敏捷开发中谁来分担传统项目经理的责任? Traditional project managers usually take on a great deal of responsibility. They are responsible for managing scope, cost, qualit

在敏捷开发中成就训练有素

<从优秀到卓越>这本书中有一章专门提到了训练有素的文化,給我留下很深的印象:"每个人都想成为最好的,但大多数组织缺乏纪律,不了解自己,不清楚自己的最大优势是什么,凭借什么把潜力变成现实.他们缺乏严格的训练有素的文化规范自己."一个优秀的企业,一个优秀的团队的特质就是训练有素,一只训练有素的军队能打赢所有硬仗,一个训练有素的团队能创造出过硬的产品. 对于敏捷开发模式,我更愿意把它的贡献看作打造一支训练有素的团队,一个高效执行的团队.一个训练有素的团队,一个高效执行的团队有四个

09.精益敏捷项目管理——敏捷软件开发中QA角色

00.当从鳄鱼嘴里侥幸逃脱时,你很难机器你的初衷其实只是想排出沼泽中的积水. 01.精益--敏捷软件开发中质量保证(Quality Assurance,QA)的角色展开,涵盖了许多关键问题 *测试人员的作用是防止缺陷,而不是发现缺陷 *开始做开发周期计划时如何发挥验收测试的作用,以做到在最大限度上减少浪费 *在早起不容易去做测试时做些什么 02.质量保证和质量控制 a.质量康芝是确保产品或服务被设计和生产出来,满足或超越客户需求的做法 b.质量保证是指由计划的.系统的生产过程,为产品符合预期目的

python开发中常用的框架

以下是15个最受欢迎的Python开源框架.这些框架包括事件I/O,OLAP,Web开发,高性能网络通信,测试,爬虫等. Django: Python Web应用开发框架 Django 应该是最出名的Python框架,GAE甚至Erlang都有框架受它影响.Django是走大而全的方向,它最出名的是其全自动化的管理后台:只需要使用起ORM,做简单的对象定义,它就能自动生成数据库结构.以及全功能的管理后台. Diesel:基于Greenlet的事件I/O框架 Diesel提供一个整洁的API来编写

iOS开发中常用的几种设计模式

下面是iOS开发中比较常用的几种设计模式.详情如下所示: (一)代理模式 应用场景:当一个类的某些功能需要由别的类来实现,但是又不确定具体会是哪个类实现.优势:解耦合敏捷原则:开放-封闭原则实例:tableview的 数据源delegate,通过和protocol的配合,完成委托诉求.列表row个数delegate自定义的delegate (二)观察者模式应用场景:一般为model层对,controller和view进行的通知方式,不关心谁去接收,只负责发布信息.优势:解耦合敏捷原则:接口隔离原

软件开发中的自测及C代码示例

在软件开发中,程序自测是一个永远都绕不开的话题.很多开发人员以写出有难度的代码为荣,但却不重视对自己编写的代码进行测试,这导致了最终到达客户手中的产品质量不高,bug频发,损害了公司的形象.对于一个开发人员来说,我们应该将开发和自测置于同等重要的地位,我们花在自测上的时间要不比开发少.能否对自己编写的代码进行充分的自测也是检验一个开发人员水平高低的标准之一. 自测方法 根据所编写的程序的特点,自测方法大致有如下几种: 第一种,利用模拟工具进行自测.这种方法适用于需要其他模块(尚不具备)发过来的消