阅《从QC到总经理》
一、 一见钟情2011年的春节假期有点长，从1月28日到2月14，共18天，本打算趁此机会系统归纳总结下软件测试的理论知识，然后好好学习下QC软件，但从北京回到郑州，因好久没去市图书馆了，急不可待的就飞奔而去，很不凑巧，那天自然科学室休息（计算机、软件类等书籍借阅室），看到文学室开门，抱着不能白跑一趟的心态走向文学室，一栏一栏的浏览过去，在倒数第二排的书架上发现《从QC到总经理》，当时心里一惊，随取下书架，略过头两页，先看版次、印次（个人习惯），发现竟是2010年8月第一版并且是第一次印刷，真是太惊奇了，因在市图书馆借阅计算机类书籍一般2005年以前的。真是爱不释手阿！阿门！！！ 二、 第一次拜读
翻开，第一页印有暗花略为硬朗的纸张写着
“不是所有事情一定要达到最完美时才可以做，坚定了自己的想法，那么后面所产生的一切问题都可以有法可循 ——晨暮”
字面意思很明朗，但内层含义不晓得，更不用说应用到实际工作中。
下面是序，先看下序的编写者，我的天！ 竟出自六西格玛品质网站长龙天之手。
序言中提到“《从QC到总经理》文章是六西格玛品质网的一幅帖子，因几个月点击量高达20万次，而整理成书”
挑灯夜读，奋战到0点，拜读完毕。合上书本，脑海中想到是作者从一个普通的QC一步一步奋斗到总经理的情景，在奋斗过程中勤于思考、敢拼、勤干、注重细节、做事果断迅速同时附有同情心等等，有很多的亮点、优点我是很欠缺，或者是很薄弱的，甚至是空白的。
坚定一个想法：在以后的工作中，要把作者这些亮点而我所欠缺的加以弥补并深入到工作中去，并逐步落实。 三、 第二次拜读
总感觉第一次读的狼吞虎咽，下料猛，有点被呛！
QC与软件测试统属质量方面，应该有相通的地方，于是开始第二次的征途。
在逐字读书中，发现这么几段话：
“小唐，我知道，可能你对于我在面试你是提出的3个问题一直有成见。你们厂牌上写的是高级技术员，不是维修工。作为一个高级技术员，你不是为了修理而去修理，而是通过仔修理的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天修了10块不良品，明天修了12块，后天修了15块，这不是成绩，是失败！公司发给你这个，两个月来你只用了一次，你自己想想是为什么。公司发给你的东西绝不是用来看的，每一个物品都有规定的用途。搞好生产产品的控制并不是一个部门或某个部门的事情。。。。。。” ——摘抄书中
想起我们的本质工作：软件测试何止不是一样，把上面那段话拿到软件测试行业翻译如下：
“。。。。。。你们厂牌上写的是软件测试工程师，不是找缺陷。作为一个工程师，你不是为了找缺陷而去找缺陷，而是通过找缺陷的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天找了10个BUG，明天找了12个BUG，后天找了15个BUG，这不是成绩，是失败！。。。。。。” 三、 第二次拜读
总感觉第一次读的狼吞虎咽，下料猛，有点被呛！
QC与软件测试统属质量方面，应该有相通的地方，于是开始第二次的征途。
在逐字读书中，发现这么几段话：
“小唐，我知道，可能你对于我在面试你是提出的3个问题一直有成见。你们厂牌上写的是高级技术员，不是维修工。作为一个高级技术员，你不是为了修理而去修理，而是通过仔修理的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天修了10块不良品，明天修了12块，后天修了15块，这不是成绩，是失败！公司发给你这个，两个月来你只用了一次，你自己想想是为什么。公司发给你的东西绝不是用来看的，每一个物品都有规定的用途。搞好生产产品的控制并不是一个部门或某个部门的事情。。。。。。” ——摘抄书中
想起我们的本质工作：软件测试何止不是一样，把上面那段话拿到软件测试行业翻译如下：
“。。。。。。你们厂牌上写的是软件测试工程师，不是找缺陷。作为一个工程师，你不是为了找缺陷而去找缺陷，而是通过找缺陷的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天找了10个BUG，明天找了12个BUG，后天找了15个BUG，这不是成绩，是失败！。。。。。。” 三、第二次拜读
总感觉第一次读的狼吞虎咽，下料猛，有点被呛！
QC与软件测试统属质量方面，应该有相通的地方，于是开始第二次的征途。
在逐字读书中，发现这么几段话： “小唐，我知道，可能你对于我在面试你是提出的3个问题一直有成见。你们厂牌上写的是高级技术员，不是维修工。作为一个高级技术员，你不是为了修理而去修理，而是通过仔修理的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天修了10块不良品，明天修了12块，后天修了15块，这不是成绩，是失败！公司发给你这个，两个月来你只用了一次，你自己想想是为什么。公司发给你的东西绝不是用来看的，每一个物品都有规定的用途。搞好生产产品的控制并不是一个部门或某个部门的事情。。。。。。” ——摘抄书中 想起我们的本质工作：软件测试何止不是一样，把上面那段话拿到软件测试行业翻译如下：
“。。。。。。你们厂牌上写的是软件测试工程师，不是找缺陷。作为一个工程师，你不是为了找缺陷而去找缺陷，而是通过找缺陷的过程中找到问题产生的根源，去分析和控制。在我们眼里，你今天找了10个BUG，明天找了12个BUG，后天找了15个BUG，这不是成绩，是失败！。。。。。。” 晕，刚才发几次没显示，还以为没成功！
后后来，才发现有那么很很小的几个字“内容要经过审核，才能发表”。
狂晕啊！ “我们开始学习ISO9002的标准条款。我喜欢听陈生讲案例，根据现象判定违反的条例。如何开不符合项，如何作整改，如何跟进改善的效果等等。那时才真正感觉到在品质管理这个领域，我的弱点在那里，很多事情都应有所依据，而不是想当然。写文件是非常严谨的工作，那时体会最深的一句话就是：“如何做的如何写，如何写的如何做” ——摘抄书中 其实软件测试也是一样一样的：
“根据现象判定违反的条例”——软件有违反公司、行业、国家标准的一般断定为BUG。
“如何开不符合项，如何作整改，如何跟进改善的效果”——相对于软件测试如何写缺陷报告单、开发人员如何修改、如何做回归测试。。。
“很多事情都应有所依据，而不是想当然”——软件测试员，开BUG依据是违反显示需求、隐式需求还是行业、国家标准等，也就是要有所依据，不是想当然。
“写文件是非常严谨的工作，那时体会最深的一句话就是：“如何做的如何写，如何写的如何做”——软件测试员免不了要写很多东东，如测试需求、测试计划、测试方案、测试用例、预测试项以及各种测试报告，其中缺陷测试报告应深刻体会这句“如何做的如何写，如何写的如何做” “一个审核员对一个不符合项的判定，一定要取得对方的沟通和确认后才能开出，而不是想当然、主观的判定，内审员的工作是协助企业进行体系的不断完善，而不是专门挑刺的，沟通是作为内审员的第一要素” ——摘抄书中
对于软件测试工程师也是一样地要求自己：“一个软件测试工程师对一个BUG的判定，一定要取得开发人员的沟通和确认后才能开出，而不是想当然、主观的判定，软件测试员的工作是协助企业、开发部进行软件质量体系的不断完善，而不是专门挑刺的，沟通是作为测试人员的第一要素” 回复 11# binghua
问题是你们怎么保证开发人员对一个BUG的判定就一定是正确的。 回复 7# binghua
这里你忽略了软件BUG的多样性和软件测试的机会成本。你花时间去找一个同问题的根源，有可能这段时间可以找到其他更严重的问题。发现问题之后，把找问题根源的任务交给对代码更熟悉的开发人员在一般情况下会更合理更经济一些。 呵呵，书名是蛮有诱惑的 努力
页:
[1]
