今天这篇文章,不聊纯技术,分享一些不一样的干货:技术背后的内驱力!
人之所以强大,在于(不安于现状的)人会不断的去学习,提升自己、突破自己。而保持多阅读是一种经久不衰且有效提升自我的学习途径!
如果把学习成长过程比喻成武功秘籍:
下面以软件测试&质量保障&质量建设几方面,给大家分享 20 条内功心法(行业金句),心法(金句)表面虽看似简单,但真正要做到并不容易,希望给大家在做质量改进工作时,多一些思考和启发!(也可以挑选一些作为你们公司或团队的文化建设标语)
软件测试:
任何软件的测试,都是可以基于“输入-输出-行为”
模型(又叫 IBO 模型)来做测试分析和设计。
当我们谈到 “软件测试” 时,是指软件测试的相关工作,如单元测试、集成测试、系统测试等,但不局限于动态测试,也可以包括静态测试——需求评审、设计评审、代码评审和借助工具进行代码静态分析。
测试是一个把质量意识输出到整个团队的人,是一个流程推动者,是一个需求挖掘者,是一个质量把关者,一方面我们确实通过自己的经验和技术手段去挖掘更多的 Bug,另外一方面,通过传播质量意识尽可能的去从产品上游去避免 Bug。
程序的测试可以证明程序有错,但永远无法证明程序无错。
一段程序,对于测试人员,bug 永远是存在的,没有发现只是测试手段的不足。
测试做得再好,也只能是 *减少 bug *的概率。
QA 和测试两者是有明显区别的,QA 强调有好的研发过程产生好的产品,侧重过程定义、过程评审和过程改进,工作重心是预防缺陷,而测试属于质量控制,强调对软件阶段性产品和最终产品的质量检验,工作重心是发现缺陷。虽然测试是 QA 的重要手段之一,但不等同于 QA。
研发偷偷上代码或者研发修改后给出的影响面不足导致出现线上问题的情况是非常比较常见的,尤其在小公司里面,常见的不得了;这个原因归根到底是,测试知道的或者能预防的太少了;
解释一下测试开发和开发工程师的区别,软件测试开发工程师(software engineer in test,后文简称 SET)本质上也是一个开发角色,只是工作重心在可测试性和通用测试基础框架上。SET 更加关注于质量提升和测试覆盖率的增加。他们这样做的目的是为质量服务,而 SWE 则更关注在客户使用功能开发的实现上。
很多人以需求规格为标准开展测试,所有的评判标准依据是 “是否与需求文档一致” 不一致就认为是 Bug,这是很危险的做法,这只会拉低测试的高度,使其受限于需求规格的高度。
质量保障:
质量保障和测试的职责已从单纯的缺陷发现转变为客户满意度和业务成果的推动者了,这是个根本性的转变。
产品质量不仅仅是主管质量的部门和管理者的事情,而是所有员工的责任和义务。
产品质量或者工作中遇到问题不用慌,了解原因,制定方案,也许不能落地,但思考了,结果就是属于你的了;
测试或 QA 的职责是保证产品的质量,而 bug 过多则证明了产品质量差而不是产品质量好,bug 多了证明团队当前是有问题的,证明 QA 在一定程度上没有做到位,证明当前的产品是有风险的。
质量建设:
质量建设强调全员参与,全员参与有两个层面的问题要解决:一是意愿,二是能力。
很多团队在做质量建设时,一直都觉得资源不够,其实真不需要,富有富的打法,穷有穷的打法,关键要预判最大的难点,然后集中力量去攻克,集中力量打歼灭战,不要想那么多,初期就把核心点做好就行。
打造狼性团队,除了制度保证、考核到位以外,领导者的个人特质也是非常关键的。
好的质量的产品,不一定是完美的产品,不一定是没有缺陷的产品,而是为我们各种重要的用户提供相应价值的,并满足了他们对产品一定期望的产品。
看山是山,同一件事情在不同人眼中、甚至在不同阶段,都有不同的样子。一台电脑,可以用来吃鸡,可以用来看电影,也可以用来建模,还可以写论文,学渣与学霸都用一样的课本。
上面这些 “内功心法”,不同人看到,可理解的程度也会不一样,是时候测试一下你是学霸 or 学渣?可以在留言区分享你对哪一条金句观点最为认同,或者分享一下对金句背后的理解。