一个测试老鸟的工作总结(2)——研发流程之我见

从一个执行层面的测试做到测试主管这个级别,当你手下管理多个项目和测试人员时,流程成为你必须要考虑的事,一般公司也很少有自己独立的SQA部门进行过程管控,如果是弱矩阵式的组织架构的模式下,基本QA/QC作为一个质量部门存在于公司内,而过程管控流程制定一般也分摊到项目管理者或质量部门中。那我们今天就来讨论一下软件研发流程这个话题,对于大多数普通的人员来看,流程是否完善规范,也是看一家公司的软件研发是否正规的主要标准。对于国内的软件企业,我们一般常见的几种开发模型有:

  1. 边做边改模型:没有规格说明,没有相关的设计,得到客户需求直接进行编码形成版本,随着客户的需要一次一次不断的修改;也就是我们早期所说的作坊式软件开发模型
  2. 瀑布模型:相信也是现在传统软件研发使用最广泛的开发模型,软件生命周期被计划、需求、设计、编码、测试、维护六个阶段进行划分,自上而下以固定次序衔接着进行一轮迭代。
  3. 快速原型模型:在需求阶段建立一个快速模型让客户或客户代表以此原型进行需求评论,细化需求,等原型满足用户需求后再进行软件的开发,常见的是那种客户前端和研发后端相分离的组织里,产品运营产品经理,UI设计及客户体验或QA验收作为一个客户代表团队,前端后端QC测试作为一个实现团队分部合作的项目中比较常见这种开发模型也算是弥补了瀑布模型的需求开发风险不明确的风险缺点
  4. 增量模型:又叫演化模型,在此模型中软件各阶段并不直接交付一个可运行的完整产品,而是交付满足客户需求一的个子集的可运行的产品,整个产品被分解成若干个构件,研发人员逐个构件进行交付,迭代的完成整个软件产品,我们常说的敏捷开发就主要以这种开发模型发展改良为主
  5. RUP:这个模型是由rational公司提出的一套开发过程模型,是一个面向对象软件工程的通用业务流程,主要适合大型的商业软件项目,是一整套系统的方法论,对应的它有一整套工具集和规范标准进行辅助,因为其复杂度和适应性,国内很少有企业进行项目实践
  6. IPD模型、螺旋模型、智能模型等等:因适用性的问题在这里就不一一说明了,网上相关的介绍文章有很多

介绍了那么多通用工作流程,主要并不是想去比较哪个流程孰优孰劣,而是觉得每个流程都有其可取之处,只有适合之说而没有好坏之分。就拿我们普遍认为小作坊式的边做边改模式,你不可否认其工作的便利性和灵活性,初创公司在没有用户及资源基础或非矩阵式组织内人员不多的情况下,这种工作方式是最适合不过的了。

我们通常开始关注并优化工作流程基本都是这样的开始的,当公司规模逐步变大,人员组织越来越多越来越复杂时,原来那种口头交互边说边做的方式可能越来越不能满足工作需要,怎样优化一种新的协作方式选取一种适合公司的工作流程,成为了解决组织变化的重要手段。而最具认可和知名度的如CMMI那些适合大型项目的过程模型来套用,一方面有很多公司的实践可以借鉴而对于接项目或对外合作又比较有利。而对那些成熟的软件过程模型体系不深入了解的话,往往只能按先例公司照猫画虎,过程改进一旦教条,文档化形式化仪式化的过程一旦形成,本来对于大组织的灵活性缺失的特点会越发明显。当过程或产品已经按流程适应和变化后,一个恶性循环就形成了。人的惰性会加剧这种情况的变化,只要勉强能应付,那么很多人都会选择拒绝改变的,不管是产品的重构还是研发过程的重构甚至下沿到组织结构的重构,当代价和风险呈现在你面前时,相信很多人都会退却的。当公司终于无法容忍这种内部消耗时,组织的变化在所难免,扁平化的强矩阵型组织化整为零,于是敏捷过程管理的理念如xp、scrum被广泛引入,而对于普遍缺乏专业project master情况下,而团队人员个体素质又参差不齐,加上管理人员或产品上急功近利的强调“敏捷”“灵活”而产生的需求变更的低成本错觉;等等等等,最终大家可能发现转了一圈,我们又回到了小作坊式的工作流程上,回到了原地。我们在讨论和比较各种流程的优缺点,在讨论什么样的组织结构更适合项目开发,如果我们反过来看的话有没有想过,其实我们把因果关系搞错了

我们错把工作流程或组织结构的选取作为了优化工作的手段,所以我们去借鉴去寻找去套用去实践那些我们觉得适合我们的工作流程。但我们有没有想过,这些其实是结果,而不是过程,我们错把因果颠倒了这才是我们没有找到适合自己的工作流程的最主要原因。在我看来所有的工作流程所应具有的属性是被动的、妥协的,是无可奈何的产物。当我们不假思索的协作方式出现障碍了,我们被动的形成了各类的工作流程来补全我们的合作方式。流程正确的形成顺序应该是,当一家公司组织越来越大,协作沟通成本越来越高,我们被迫着改变我们的工作方式,这种改变有成功的,也有失败的,但反复成功的工作经验墨守成规,于是流程形成了,这个时候我们把那些适合行文定规,工作流程的确立是所有这些动作的最后一步。如果我们把工作流程的优化和制定当作优化组织的过程和工具,借鉴别人的最佳实践,水土不服的现象经常可以看到,因为了解你自己的人永远只有你自己。所以我们可以看到一个结论,优秀的组织形成了优秀的工作流程;而不是优秀的工作流程造就了优秀的组织。人事人事,人的因素永远多于你对事的依赖。找到一个优秀的一劳永逸的工作流程来解决你人的问题永远是不靠谱的想法

就拿我们验收阶段测试(系统测试)的内部统一后来流程演化来说吧,你可以看到一个完善的工作流程是怎么在日常工作中一点点形成的:原来公司因为有集成测试,相对系统测试还算简单,因为出现几次线上事故,所以对验收阶段的测试要求越来越高,而产品运营的介入和演示要求,使我们这个阶段的测试流程化需求越来越高。不完美的敏捷开发加入又让我们的系统测试越来越凌乱,于是,我们有了冒烟测试打回的机制,为了满足项目经理的实时测试覆盖情况的需求,我们加入了冒烟测试报告阶段测试报告,为了提高报告效率,测试报告自动化生成工具产生了。为了提高系统测试介入时间和效率(注:验收测试我们不做自动化)我们对提交的代码按需求进行了模块的划分。为了保证开发和测试的版本控制同时为了统计和定义项目过程改进中的regulation bug和reopen bug;我们在这个测试阶段定义了dev版本和QA版本两种版本内容;最后一步步我们为了方便新员工熟悉这些一点点演变而来的工作流程,我们对其文档化最后的流程就变成了这样:

上述流程成文基本是我们做了几个月自然形成的,其中实践中作为多次修改,上面只是附了最简单的流程图,而详细的规定项目成员已了然于胸,流程只是给新员工讲解和提醒之用。所以还是那句话,没有最好的流程,只有最适合自己的流程;项目中的研发流程最佳实践永远优于借鉴和套用

时间: 2024-10-07 03:29:53

一个测试老鸟的工作总结(2)——研发流程之我见的相关文章

一个测试老鸟的工作总结(3)——质量部门成立之现形记全录(上)

这两年在测试管理上的工作经验提升对我来说还是有很大裨益的,想着以故事的方式把自己的经历杜撰一把,当中的心得和感受可能从描述和理解上来说更地气. 在原来公司做了半年不到的测试主管,一次领导找我谈话,问我对公司现在的测试现状和产品质量的看法:当时因为测试团队刚组建,所以就提了一此工作执行中的困难和细节问题,同时也指出现在主要的问题是各职能部门对于项目权责划分不明确,看似项目中可管理的人员有很多,确没有负责的主体人员:加上因为研发流程的缺失,使工作中这种都能过问,却没人主管的情况更显突出:并对规范和执

一位测试老鸟的工作经验分享

最近,部门刚毕业入职的小MM跟大家提议,让大家把自己的软件测试工作经验分享一下,我整理了一下,可能不全. 测试工作经验分享 一.测试阶段划分 1. 单个模块功能测试时间相对较长,但每一个项目都应该有专门的集成测试阶段,并且应该不止进行一轮. 每一轮集成测试,应该都有自己的目的,比如第一轮集成测试,是根据集成测试要点验证整体功能情况:第二轮集成测试是回归测试:第三轮集成测试是交叉测试. 每个项目应进行几轮集成测试,根据项目实际情况而定,而决定的因素多与工期.项目问题多少而定. 2. 每个项目都应该

一个测试老鸟对职业技术交流群的几点看法

首先: 先介绍下自己,看文章得知道作者是干嘛的 IDO老徐,互联网从业者,软件测试老鸟,08年开始从事软件测试职业:前后经历3家公司,从测试小菜到公司测试负责人,带领测试团队对公司整个产品体系负责: 专注测试职业探索.测试管理.项目管理.测试经验谈:分享自己的测试观点.测试经验:希望能让你的职业道路少一些弯路! 如今,越来越多的技术交流群 但是,大多数群基本都变质了 完全成了闲扯群   -->先查看老徐昨天前几天的一篇文章<浅析那些大型职业技术交流群是怎么被玩变质的?> 交流不出啥东东

2019年终总结----一个测试的成长年

从今年5月开始写下第一篇博客,到现在还是有几十篇了,写的大致是我不懂到懂的东西.我很高兴我能够坚持写,也希望能继续写下去. 2019年对我来说关键字应该是--收获 今天的我确实成长了不少,令我感到开心的是我不光测试能力得到了成长而是今年我算是一只脚进入了开发的大门. 今年2月我跳槽到了现在的公司,一个小型公司,入职之后就我一个测试属于研发组.入职之后负责三个项目的测试工作,由于都是上线了的产品,所以还是算比较稳定的没有多少BUG.这个工作完成之后我写了其中两个项目的自动化测试,主要还是用于做监控

一个Web 持续集成工作实践

一个web的持续基础实践: https://mp.weixin.qq.com/src=3&timestamp=1494325174&ver=1&signature=wFVC0E6YlKsNsCYnhs8XlMdRTmtwBU8qMW4YCsNoryvcIAGD8hPCnOCaXb5WisyGrmEOVUJVd1n2FRjV3ohyUWuTDUGMGhkDPXAlvd6t0RtNSivqrMRgof1KJcnZrAvzTYkjURSzDPjk8wR5vq8ASUOarm9mFlUad

[ddt02篇]十年测试老鸟帮您解析:ddt结合txt,excel,csv,mysql实现自动化测试数据驱动

一.前言: 阅读此文之前请先阅读: [ddt01篇]十年测试老鸟帮您解析:ddt数据驱动入门基础应用:https://www.cnblogs.com/csmashang/p/12679448.html ? 二.ddt数据驱动框架结合txt文件实现数据驱动 test_demo.py代码如下: import unittest from ddt import ddt, data, unpack #读取txt文件中的内容,strip()方法去掉首位的指定字符. def read_txt(): list

利用反射模拟一个spring的内部工作原理

这个简单的案例是实行了登录和注册的功能,没有链接数据库. 在bean中id 是唯一的,id和name的区别在于id不能用特殊字符而name可以用特殊字符,比如:/-\.... 1 package com.obtk.reflect; 2 3 public class Logon { 4 /** 5 * 帐号密码长度大于六位字符就成功,否则失败! 6 * */ 7 public String select(String name, String pass) { 8 if (name.length()

一个软件测试员的工作与学习(三)

续上一篇 http://www.cnblogs.com/fnng/archive/2013/04/13/3017598.html 在开始讲述这一年多的经历的过程之间,我又回顾了之前的经历,以便把比较好的把故事的衔接,需要说明的是,我并没什么高大上的经历来吹牛皮,只是做为一个普普通通的软件测试员,来记录自己的经历而已. 关于学历                                      应该是在入职新公司前报考的自考,学历一直是我的硬伤,所以,就想通过自考的方式来弥补,对于搞技术的

一个测试案例的分析

案例: 某软件公司在开发一个城镇居民保险系统时,在单元测试.集成测试阶段,为了追赶进度,开发人员与测试人员都没有介入测试工作. 系统测试阶段,测试小组借助缺陷管理工具和开发人员交互进行测试与缺陷修复工作.期间,发现"扭转文档无法归档"的严重错误,开发人员在修改时,认为难度太大,决定暂停修改,得到测试人员认可.在产品发布前,该问题在开发环境下得到解决. 回归测试结束后,开发人员把开发环境下的产品打包,发送给客户. 分析:在案例中,有几处显然不合理的地方: 1.测试介入太晚 2.回归测试做