随着发布时间的临近,团队肩膀上的压力越来越大。因为专注于下一次迭代,开发人员开始忘记周末是休息时间。管理人员的压力可能会更重。唯一阻碍我们前进的事情是测试……测试的进展不够快。
成都创新互联服务项目包括保山网站建设、保山网站制作、保山网页制作以及保山网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,保山网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到保山省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!
在开发周期的最后阶段,很容易看到事情明显放缓,至少从某个角度来看。
三件主要的事情
平均每天,测试人员花费大量的时间在三个不同的活动上——test,bug和setup,即TBS。
T,Testing time——是我们要做的事情,也是很多混乱被引入的的地方。当我们谈论我们正在工作的内容时,大多数测试人员用“我正在测试新的报告功能”或“我正在构 建来自于最后冲刺用于批量加载功能的自动操作”来报告状态。这些声明是准确,肯定的,但他们也可以隐藏了所有你不得不做的其他工作。如果我们想获得更具体 的内容,那么我们可以减少测试时间,缩短到只花费在评估软件上的时间。当我在看文档和谈论产品有关的新变化时,是为了帮助设计测试,这就是测试时间。当我 工作在软件上时,我的探索和测试,也是测试时间。
B,Bug——当我们发现bug时,我们会从主要工作(需要测试的内容)切换到一些由于问题造成的意外情况上。 如果问题不存在,那么我们就不需要花费时间去重现,去探索知道问题是局部的还是更大问题的一个症状,也不需要为了修复去文档记录和支持。发现一个bug破 坏了测试流:停止工作,停止测试速度,如果你用那种方式考虑事情的话。当我在测试时,发现了一些有趣的东西,一般我做的第一件事就是,尝试重建这种情况。 这里就是我做的瞬间放缓的地方,因为我需要追溯我的步骤。有时,bug简单,那么我可以马上重建它,而当bug狡猾的时候,那我就需要时间来搞清楚。在研 究bug后,还要报告此事。无论你是很幸运有一个演示就足够了,还是必须在一个跟踪系统中做一个全面的报告,都是需要时间的。Bug阻碍了测试活动前进的 脚步,并且我们通常不知道它们会在什么时候突然出现。
S,Setup——不像工作于bug时创建测试的start-stop经历,设置活动在一开始就限制了工作流, 就像高速上的匝道一样。设置是我在执行测试前不得不做的一切事情。在最简单的情况下,我用工具,例如Excel来创建数据,要么使用脚本要么自己加载到软 件中。这种设置非常快,只需要几分钟。在图表的另一端则需要几小时或几天的设置活动。在有一个案例中,我和一个开发人员工作了一两天才创建了数据,然后打 包到SQL脚本中,在我们可以做任何有意义的测试之前,得到填充了数据的系统。
在你第一次测试一个新的东西时,很难绕过设置成本。如果你打算将来重新测试,那么有时测试管理工具可以,通过运行安装脚本或为工作在那个领域的下一个人存储特殊信息,帮助降低成本。
我们通常不会去关注时间都花在了哪里,并且几乎从来没有均匀分配时间。Test Bug Setup更像是一个三边的跷跷板。当我花了大量时间在设置数据上时,那么可能可用到测试上的时间就会变少,而用来报告发现的问题的时间就更少了。如何正 确地安排这些时间是需要平衡的。
如果你想知道为什么测试要花这么长时间,那么就看一看你的员工工作的所有未测试的其他活动。那项工作可能对项目而言是至关重要的,是为了添加信息,促进测试,但你可能会惊讶地发现它只是嵌入在表面之下。
译文链接:http://www.codeceo.com/article/why-your-project-take-so-long.html
英文原文:Why Is Your Project Taking So Long?
分享文章:为什么你的项目要花这么长时间?
本文地址:http://www.gawzjz.com/qtweb2/news42/17942.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联