延伸测试边界，银行测试团队转型建议
本文首发于「BY林子」，转载请参考版权声明。 ps：圆明园万花阵（图片来自网络） 银行的传统测试团队很容易陷入一种困境，就像困在迷宫中的游人，走得筋疲力尽却陷在死胡同里，迷路出不来。 本文就此话题进行简单的分析，并给出我对银行测试团队的建议。 01 银行软件及其质量保障的特点1.1 质量要求高，质量保障难度大银行软件的质量要求很高。一方面，银行软件绝大部分都跟钱有关，但凡出现一个非常小的计算错误，都可能带来巨额损失，对bug的容忍度非常低，这就要求对软件功能的验证做得细致而认真。同时，银行软件要满足监管要求，合规性得有保障；此外，对于安全性、可靠性等多项非功能需求都有很高的要求。 银行软件业务规则复杂，且随着时间推移，不断有新的业务规则加入进来。要确保软件实现的业务规则的正确性，需要有足够的测试进行保障。 1.2 独立的测试部门是软件质量保障的主力传统的银行基本都有独立的测试部门来承担软件质量保障的工作，测试人员的构成呈现以下两个特点： 资深的专业测试人员测试技能水平较高。高质量要求自然成就了一批高技能水平的测试专家，同时也是高质量的拥护者，有着很高的话语权。这是银行测试部...
跑步时，我在想些什么？
两天昏睡，两天疯狂赶材料，四天没出过门。今天是周末，不能辜负外面明媚的阳光，整装出发。 上午10点，户外依然是零下10度，没有了第一次挑战的忐忑，取而代之的是轻松和自信。 滴水成冰的户外，一个不太严实的口罩是保护嘴和鼻子的最有效装备。习惯了四步一吸、四步一呼的呼吸节奏，基本感觉不到口罩的存在。鼻子吸进来的冷气与嘴里润喉糖的薄荷一起沁入心脾，令人神清气爽，越跑越精神。嘴巴呼出的气体，遇到口罩内壁迅速凝成水珠，滴落到脸上，沿着鼻子两侧流下。有的流到嘴边，被呼出的气体再次带出；有的直接流到下巴，被口罩再次兜住，还有部分逃逸的最终也被魔术围脖收着。 耳朵承担的最多，一个眼镜，一个口罩，还有一个骨传导运动耳机。不忍心再施加一个耳罩，抓绒跑步外套的帽子就成了它的保护神。迎面袭来的寒气，绝大部分望而却步，也有顽强的气体分子随着帽子内侧钻进，跟身体产生的热气迎面相遇，成为身体散热的帮手。 寂静空旷的大马路上，除了耳机里传来的跑步音乐，几乎听不到其他声音。大脑下意识地提醒时刻保持核心部位的收紧，同时指挥手臂带动双腿，踏着180的节拍有节奏地往前迈进。此时此刻，我什么都不想，而是陶醉于感知每一步给身...
挑战零下10度跑步
早上8点，天气预报显示气温为-8°C，体感温度为-10°C，无风，太阳高照。 换装，上装一件速干内衣+抓绒速干衣+薄款超轻羽绒服，下装一条速干抓绒裤+一条薄的速干裤，戴上帽子、手套和口罩。 屋里热身，出门。 踏出楼门那一刻，一股寒气直奔双脚袭来，跑鞋透气效果太好！腿部也感觉到一丝凉意，但并不觉得很冷。 我的跑步路线需要先过马路到对面，正好赶上红灯。为了不让自己冷下来，先在马路一侧跑起来，等绿灯了再过去。 跑起来之后，身体很快开始发热，下装比较合适，上装穿的有点多，感觉挺热，可能是羽绒服的保暖效果太好。幸好里边穿的都是速干衣，问题不大。 但是，难的是呼吸问题…戴上口罩全是哈气变成的水珠糊在脸上，不戴口罩又会冻得流鼻涕…好像没有特别好的办法？ 朋友说：“这样的天气跑步是需要勇气的。” 我之前也这么认为，不过自从参加展晖老师的跑步训练之后，掌握了科学的跑步方法，对跑步运动的信心增加不少，出发前并没有担心和犹豫。 跑完五公里，大汗淋漓，在这寒冷的冬天体会到了难得的舒爽。 有了今天这第一次的挑战成功，我对跑过这个冬天充满了期待。 推荐阅读： 规律跑步，让生活更有掌控感
回归测试与温伯格双胞胎定律
本文首发于「BY林子」，转载请参考版权声明。 “每次都要把所有的回归一遍，但很少发现问题，是不是可以不做了？” “写这么多自动化测试，费时费力，但几乎没发现啥问题，这些测试的价值何在？” 你是不是也有上面的疑问？或者被这样质疑过？ 关于这个，我想到一条定律。 温伯格双胞胎定律杰拉尔德·温伯格在他的著作《咨询的奥秘》中讲述了一个有意思的故事，大意是这样的： 公交车是按年龄收费的，成人35美分，五岁以下儿童免票。 一位母亲带着8个孩子上车，交了车费35美分。司机对此质疑道：“你不会想让我相信这8个孩子都不到六岁吧？” 那位母亲说：“当然啦！这俩四岁，那俩姑娘三岁，两个刚走路的两岁，我手里的两个家伙一岁。” 司机目瞪口呆，充满歉意地说：“哎呀，真抱歉！您一直都在生双胞胎吗？” “天啊！当然不是，多数时候我们什么也不生！” 啊哈！这对夫妇就是在做他们平常该做的事情，大部分时间并不在生孩子，更别说生双胞胎了。温伯格因此悟出双胞胎定律： 大部分时间，在世界上的大多数地方，不管人们有多努力，都不会发生什么大事。 这条定律指出：大部分努力都是徒劳的。 那么，不努力行不行呢？该定律...
规律跑步，让生活更有掌控感
本文首发于「BY林子」，转载请参考版权声明。 “我报了一个跑步训练营，学跑步。” “什么？跑步还用学？” 跟朋友们提到这个，都是类似的惊讶反应……没错，我曾经也认为跑步应该是最简单的运动，迈开腿跑起来就是了。直到四个月前我加入跑步训练营，彻底改变了我对跑步的认知…… 01 我与跑步我在学生时代最不喜欢的应该就是体育了，因为我是体育渣……我的800米成绩初中时候还能达到85分以上，到大学及格都很勉强；50米和100米短跑更是我的噩梦…… 工作几年之后，想找一种运动来锻炼身体，发现没有什么擅长的，就想到了跑步，我以为跑步是最简单最方便的。而且，我还的确挺喜欢跑步这种户外独处的运动，顺便可以在跑步的时候听听书、欣赏路边美景或者思考一下人生什么的。 断断续续跑了很多年，不仅没什么锻炼效果，也难以坚持，基本就是三天打鱼两天晒网。 几年前参加百人百天跑团，在奥森跑了我人生第一个10公里之后，就再也不敢尝试跑那么远了，确切地说是距离越跑越短，到最后都没法坚持跑完3公里全程。而且，每次就算努力跑完，也总是感觉身体各种不适，并没有起到锻炼的效果……后来才知道那一次是全凭意志力跑下来的，根本...
一颗石榴给QA带来的启示
本文首发于「BY林子」，转载请参考版权声明。 “小淘，吃石榴吧。” “吃石榴太麻烦了，不想吃。” “这是软籽石榴，籽儿可以吃的，很好吃的哈。”说完，我大口嚼着石榴直接咽下。 “不用吐籽吗？那我试一下。”小淘拿起几颗石榴粒放嘴里嚼了一下，还是把籽儿吐出来了。“不行，这籽儿我没法咽下。” 的确，在没有软籽石榴的时候，我也这样吃石榴，也觉得石榴吃起来太麻烦，而不愿意吃。而小淘由于对硬籽石榴中的籽儿难以忘怀，吃软籽石榴也还是会关注籽儿的存在…… 这一情景让我恍然大悟，这不就跟咱们很多传统测试人员对软件测试的理解很类似嘛！ 我们先看吃石榴的场景 没有软籽石榴之前，石榴籽不能吃，那个时候觉得石榴籽儿太多吃得太麻烦，根本体会不到石榴的美味，也顾不上它的营养了。 有软籽石榴之后，石榴籽就可以吃了。但如果在吃石榴的过程中还是总关注石榴籽，你会发现尽管它们是可以吃的，也会觉得很别扭，咽不下去，这样根本没法好好吃石榴，没法吸收石榴的营养。 如果把关注点放在石榴的美味和营养上，大口大口嚼着吃，你就感觉不到籽儿的存在，这样既能享受石榴的美味，也能吸收石榴的营养。 再看软件测试 在传统测试里，QA（测...
软件测试中的『草莓酱定律』
本文首发于「BY林子」，转载请参考版权声明。 在《软件测试中的『树莓酱定律』》一文中借用杰拉尔德·温伯格的『树莓酱定律』解释软件测试中的一些典型场景。其实，温伯格还有一个对应的『草莓酱定律』： “只要有果肉块，就不会抹得太薄。” 把一点树莓酱抹到几片面包上，你会发现它越抹越薄。可要是你换成草莓酱再来试试，你会发现不管怎么抹，果肉块还在那里！草莓酱里面的果肉块是草莓。在你传达的“伟大信息”中，果肉块就是你自己！只要你的沟通渠道还实实在在地用到你的身体——说话、写作、拥抱，你的信息就不会被无限冲淡。 本文聊聊上一篇文章提到的软件测试中的现象，如果用『草莓酱定律』解释会是怎样的。 01 测试全流程介入：离不开全面的测试策略测试全流程介入不会导致测试工作的增加，用树莓酱定律解释是因为测试工作分摊到全流程的各个环节了。但是这里有一个重要的前提，需要将测试工作真正地分摊，确保每个环节做的测试工作都是有效的，并且对整个团队和整个流程都是可见的，也就是没有“果肉块”，这样才能有机组合起来实现软件整体的质量保障。 如果存在“果肉块”，测试工作量是有可能增加的。“果肉块”是什么呢？比如下面的情...
软件测试中的『树莓酱定律』
本文首发于「BY林子」，转载请参考版权声明。 温伯格经典著作《咨询的奥秘》中提到『树莓酱定律』： （将一定量的树莓酱抹在面包片上）铺得越广，摊得越薄。 意思是不管多伟大的信息，传播的越广，信息量就会越淡，即信息在传播的过程中不会增加，信息的总量是一定的。 这是一个看似非常简单的定律。本文不聊信息传播的问题，而是想借用该定律来聊聊软件质量与测试中可以用树莓酱定律解释的常见场景。 01 测试全流程介入：测试本来就忙，这就更忙不过来了？提倡全生命周期的测试活动的开展，其中就要求测试人员在全生命周期各个环节有更多的介入，这对于传统独立测试阶段忙得不可开交的测试人员来说，是难以接受和理解的一件事情，觉得那样会更忙不过来。 其实不然。 根据树莓酱定律，在测试工作量一定的情况下，全生命周期开展测试，是将测试工作分散到各个阶段，每个阶段的工作量会有所减轻。而且我们知道越早开展的测试工作，能够做到更快速地反馈，其有效性越高，价值越大。 因此，测试全流程介入，不会增加测试的工作量，只是将测试工作的开展时间进行重新安排。 另外值得提醒的是，全生命周期的测试不仅是测试人员全流程介入，也需要团队不同...
测试部门的职责定位
本文首发于「BY林子」，转载请参考版权声明。 测试部门的存在是传统企业普遍存在的一种组织架构形式，在数字化转型的浪潮下，有不少企业在往业技融合方向转变，但测试部门完全融合到业技融合团队还是任重而道远。在这种新形势下，测试部门该如何跟业务、开发更有效的协作，是需要系统性思考的问题。 本文围绕这一问题展开，尝试对测试部门的职责进行定义，内容不仅适用于传统企业中独立的测试部门或者测试团队，也适用于敏捷团队里的QA（测试角色）。 01 组织架构为了更好地聊职责定位，有必要先捋一下测试部门的组织架构。测试相关的组织架构常见的有以下几种情况： 测试是一个独立的部门，跟开发中心或者开发部是平级的关系：这种组织架构下，测试跟开发是非常独立的，两者之间通常会有比较厚重的部门墙，沟通和协作会比较吃力。 测试和开发同属于某个开发中心，但是测试自己是一个独立的团队，对应的还有多个开发团队：这种组织架构跟前一种是非常类似的，测试和开发还是比较独立，有着团队墙，同样沟通和协作的难度较大。 根据不同的产品线，测试和开发融合在一起成为开发团队：这种开发和测试间的沟通和协作会相对顺畅，比较利于质量实践的开展。...
关于敏捷测试象限的“秘密”
本文首发于「BY林子」，转载请参考版权声明。 敏捷测试象限有了近20年的历史，但还是有很多在做敏捷项目的朋友也没听说过，或者听过但完全不知道是怎么回事。另外，知道敏捷测试象限的业内同仁对它的评价也是褒贬不一。 最近听到几个稍感意外的说法，于是，想跟跟大家一起聊聊这个有名却又颇受争议的敏捷测试象限。 01 敏捷测试象限的演进史深入了解一件事物，我们有必要了解它的历史演变过程。下文尽量按照时间先后顺序来分享敏捷测试象限几个主流版本的演进，如有不准确的，烦请指出，先行感谢。 1. 原型：敏捷测试矩阵（2003年）Brian Marick于2003年最早提出“敏捷测试矩阵”的概念，分四个象限，左右分别为支持编程和评价产品，上下分别为面向业务和面向技术。如下图所示： 这是一个专门针对敏捷测试的矩阵，Brian指出左侧的测试主要是为了支持编程所做的准备工作和确保一些问题的澄清，而右侧的测试是关于验证和发现bug相关，左右两侧的“测试”含义不同。 这个矩阵就是我们通常提到的敏捷测试象限的原型。 2. Lisa和Janet的敏捷测试象限第一版（2008年）Lisa Crispin和Janet...
