软件测试二十载

T-Systems-初入职场

我在2000年3月开始从事IT工作，加入了debis Systemhaus（ICT服务公司），不久之后被德国电信收购并组建T-Systems公司。我当时主要从事报表、数仓和电子计费项目。2003年6月底，当我参与的第一个Java项目完成时，便主动接受了公司测试职位的面试，并成为公司两个大型测试项目成员之一。2003年7月1日是我正式成为测试的第一天。那一天我就意识到开发、测试与人的关系非常密切，而测试人员承受着某些特殊的压力。当时项目组有50-60名测试成员，我们在那一天进行了一个缓解冲突的研讨会；当时的团队氛围非常紧张和充满敌意。因此，我新岗位第一天就见证了团队是如何处理愤怒和失望的。这件事也标志着我测试职业生涯正式开始，而至今已经有20年了。

我加入的第一个项目是当时著名的"Toll Collect"项目（欧洲重卡过路自动收费系统项目），即在德国的高速公路网络上引入基于里程的卡车收费系统。该项目已经启动了大约1.5年，并计划于2003年9月1日投入使用，因此压力巨大（刚到新岗位2个月就要面临项目上线的压力）。而时间来到2003年7月末，项目组决定对项目进行延期，原因是项目测试出一系列问题，质量堪忧。几周后，我才意识到测试对项目的成功有多么重要。当我加入项目时，Toll Collect系统负载只有13小时。记住这个数字：13小时。

不出所料，该项目的发布时间被推迟到了2005年1月1日。因此我有时间来熟悉这个项目的子系统，也是这段时间，让我明白系统思维的重要性，系统思维是一种综合性的思考方式和方法，用于理解和解决复杂问题。它强调将问题看作一个整体，并关注问题中各个组成部分之间的相互作用和关系。系统思维不仅关注问题的表面现象，更关注问题的根本原因和潜在影响。

Good Systems Thinking helped me to quickly understand

系统性思考帮助我快速理解系统

良好的系统思维帮助我快速理解了整个Toll Collect系统，该系统由大约15-20个复杂的子系统组成。在2004年夏末项目启动期间，我除了担任子团队负责人（带领3名测试人员和负责2个子系统）的角色外，我还负责负载测试的角色。那个秋天，我们进行了三次负载测试，每次持续两周。尤其是第三次测试，我将永远记得，并且无论别人是否想听，我都会向他们讲述。

前两次测试是为了展示系统能够在标准和备用场景下承受预期负载，而第三次测试是为了展示系统的弹性。一个审计员和一个超级管理员坐在一个房间里，不时告诉他们破坏系统、数据库、网络连接等等。测试的目标是看一个问题会在多快的时间内出现，故障是否在监控中可见，系统是否能够正确故障转移，在另一个节点上继续运行，运维人员是否知道该怎么做，堆积工作会被多快处理等等。（2011年Netflix以混沌工程的名义流行起来的东西，而Toll Collect项目早在7年前就作为标准测试场景了。）最终系统连续负载运行14 x 23小时（受模拟器限制）没一点问题，而在13-14个月之前，让系统运行13小时都做不到。

在接下来的三年里，直到2007年底，我成为了两个测试团队的负责人，了解了其他几个子系统的所有架构，甚至学习了SAP系统的基础知识。虽然“Toll Collect”项目在2003年底和整个2004年成为全国的笑柄，但在2005年成功上线后，该项目一直平稳运行。每年会进行两次重大发布，经过了充分的测试、验证，并顺利发布生产环境，至今没有出现任何问题。

与此同时，我获得了ISEB基础证书和ISTQB测试经理证书，但对于我多年来每天所做的工作，我并没有学到更多东西。整个项目严格遵循ISTQB方法，所以我别无选择，只能从事这种工作。ISTQB规定非常严格，如果没有编写测试用例，甚至不允许对系统存在的问题提缺陷。而探索性测试则被看作不受欢迎的，实际上探索性测试几乎是我一整年所做的工作。（至于为什么，是因为我个人则讨厌编写测试用例。）

ISTQB（International Software Testing Qualifications Board）是一个国际软件测试资格认证机构。它致力于推广和发展软件测试领域的最佳实践和标准，并提供相关的认证考试。

通过ISTQB认证，软件测试人员可以证明自己具备专业的软件测试知识和技能，提升自身的职业竞争力。同时，ISTQB认证也为企业提供了一种衡量和选择软件测试人员的标准，帮助企业建立高效的软件测试团队。

2006年，我负责“测试”一个新的系统。虽然我不喜欢这个新系统，但是还是硬着头皮做了。此外，我曾负责的系统则交接给了其他团队。项目开发过程中，负责新团队的同事对复杂数据库设计一无所知，也不采纳我的建议，最终开发出来一个垃圾玩意。记得第一次发布，我就提出了85个缺陷，并阻止它按计划发布到生产环境。我的缺陷数占比70多名测试人员在同一时间对15-20个子系统提出的所有缺陷中的三分之一以上。两次发布后，该系统就成为了历史。虽然我无法阻止它浪费大量的时间和金钱，甚至无法阻止它发布到生产环境。但我仍然可以自豪地说，它从未在生产环境中被使用过。这是我第一次感受到系统架构的重要性。

As a tester it’s often not your turn to bathe in the light of success.

一个成功的项目背后，测试人员往往被认为是最微不足道的。

在2007年，我已经不再负责那个系统了，但当时发生了一个生产故障。于是项目负责人找到我，给了我生产数据库的密码，并告诉我花一个或两个小时进行分析和定位问题。两个小时后，我告诉他们发生了什么，为什么会发生。而开发团队则花了两周时间分析这个问题，最终得出一个似乎正确的解决方案。然而，只有我和项目负责人知道我在故障发生后两个小时就已经摸清了问题。因此通过这件事让我感受到一个成功的项目背后，测试人员往往被认为是最微不足道的。

走向管理

在2008年，我在职业生涯中取得了晋升，被提名为T-Systems国际道路收费项目的首席测试经理。与我在德国系统的一些前同事一起，我们试图帮助开发一个更轻量级的系统，并将其销售给一些欧洲邻国，这些国家试图为他们的道路收费计划引入类似的系统。那是段美好的时光。我们尝试了一些轻量级的方法，与一个外部开发团队一起进行2周的迭代开发。而传统的ISTQB方法已经远远无法跟上这个项目节奏，多年来长周期瀑布开发方法的使我们的项目进展缓慢，因此我们也开始试图进行自我调整。

在2009年，德国项目出现了一些人员问题，我被调回Toll Collect项目担任发布测试经理。这项工作需要准备持续3-4个月的发布，协调和报告大约4-5个月的发布测试，然后再花1-2个月的时间整理项目。然后放慢一些速度，对下一个发布提供一些支持，并逐渐开始为之后的发布重新开始整个流程。通常我们是一个由四个人组成的团队，总是两两配对，一个负责主导，一个负责支持和backup。

Release Test Manager负责管理和协调软件发布过程中的测试活动，职责包括：

1. 规划和制定测试策略：根据项目需求和目标，制定测试计划和策略，确定测试范围、测试目标和测试资源。

2. 测试团队管理：负责组建和管理测试团队，分配测试任务，监督团队成员的工作进展，并提供必要的培训和指导。

3. 测试执行和监督：确保测试活动按照计划进行，监督测试进度和测试质量，及时解决测试过程中的问题和风险。

4. 缺陷管理：跟踪和管理测试过程中发现的缺陷，与开发团队合作解决问题，并确保缺陷的及时修复和验证。

5. 测试报告和沟通：生成测试报告，向项目团队和利益相关者沟通测试结果和风险，提供决策支持和建议。

在担任测试经理的四年里，我非常讨厌耗时的测试方法。我按照自己的工作方式做了很多事情。而好与不好，我仍然不知道。但我知道自己受到内部和外部客户以及同事们的尊重，当他们想要完成一些事情时，他们就会来找我。

我在项目中的最后一年，也就是2012年，有一个外部客户给我打电话，因为他们想了解关于2003-2006年间曾经是负责过的系统里一个非常具体的问题。在整个项目中，我对系统的了解程度可以排到第二，仅次于那个从2007年到2012年重新设计该系统的人。

九年半的测试经历终于结束了，是时候迈向新的阶段了。2012年9月，我们的一个团队领导分享了EuroStar会议的一份简报，介绍了一系列关于测试主题的网络研讨会。

在这九年多的时间里，我获得了2004年的ISEB基础认证、2005年的iSTQB测试经理认证、2005年的ITIL v2基础认证，2006年参加了一次关于基于风险的测试管理的研讨会，并在2008年参加了另一个高级iSTQB课程的培训。2012年，我参加了一次非常棒的项目管理研讨会，学到了很多基础知识。也许看起来有点晚了，但迟到总比不到好。不管怎样，我之前并不知道有关测试社区、测试会议、网络研讨会、书籍、博客文章、Twitter等等的存在。

在参加了第一次网络研讨会之后，我意识到在这九年里我似乎没有做一件事情。这9年里我没有提出很多问题，也没有努力去理解基础知识，而是试图靠假装懂来每天工作。在所有这些经验丰富的测试人员、开发人员、项目经理和团队领导之间，我把提问视为无知的表现。很长一段时间里，我是团队中最年轻的人之一，但也是为数不多没有大学学位的人之一（有一段时间，我们团队70个人中的13个人拥有博士学位）。九年来，我接受了那些已经不在项目中的人制定的流程，接受了术语，并尝试学习如何在正确的上下文中使用它们，而不是真正理解它们的含义。

我知道很多东西，但学习它们花费了我很长时间，也很少提出质疑，因为我认为那些比我聪明的人引入这些东西肯定有很好的理由。

那一周，我开始觉醒作为一个测试人员。九年来，我在职业生涯中取得了进步、升职，但仅仅只是按时完成任务而已。我有常识，是一个善于系统思考的人，这在各个方面都对我有帮助。我能够继续做之前的人所做的事情，填写那些永远一样的Excel表格，编写和调整那些永远一样的报价，制作那些永远一样的PowerPoint幻灯片。多亏了我的系统思维能力，我能够轻松处理复杂的情况，并快速适应古老的流程。

在这九年里，我没有做任何创新性的事情，对我来说也没有理由去做。我试图做我认为对项目最有利的事情，一切都是非常依赖于上下文的。

Urban Science – 成为QA Leader

Urban Science（城市科学）是一家全球性的咨询公司，专注于提供数据分析和解决方案来优化城市和汽车行业的运营效率。

2013年，我最终离开了T-Systems，在一家名为Urban Science的中型美国公司开始了一份工作。该公司活跃在汽车行业的经销商网络领域，几年前收购了慕尼黑的一家小公司。由于协调和管理来自美国的测试人员太过繁琐，他们正在寻找一个当地人来担任慕尼黑办事处的“质量保证主管”。

我的职业生涯进入了一个奇怪的篇章，我既不想错过，也希望能够跳过。当我在面试后要求见团队时，他们找了一些借口推辞。我也没有花太多时间去思考为什么。而在签订合同两个月后，当来自美国的老板来到慕尼黑并要求我见他时，对于为什么他们需要我这件事情上变得更加明显了。是因为他们不想自己处理慕尼黑办事处的一个测试人员。原来我只是一个工具人。。

我职业生涯中最悲伤的时刻之一是当我无法与那个同事达成共识、找到一种专业的处理方式、帮助他成为一名更好的测试人员并在团队中更受认可的时候。我除了领导经验的缺乏，还缺乏心理学方面的知识，导致无法妥善处理这种情况，所以我的美国老板和人力资源部门的同事选择了捷径，在我试图改善情况的过程中让他离开，这件事至今仍然是我职业生涯中最大的失败之一。

而积极的一面是，在那里的时候，我阅读了大量的博客文章、杂志和几本书，并开始积极参与Twitter上的测试社区，也赶上了过去10年错过的一切。

我甚至开始学着创新，使用思维导图来记录被测试系统并指导探索性测试。

我了解到探索性测试是一种方法论，它可以被结构化并且非常有用。而实际上这正是我长期以来一直在做的。我甚至在Microsoft Team Foundation Server中创建了工作项类型来记录和更有效地使用它。我在引入新产品时非常成功地应用了基于会话的测试管理。

2015年，我开始设计我的第一个测试框架，最终开始自动化一些从未被设计为可自动化测试的东西。我自己提出了创新的想法，阅读了很多资料，在网络上与人们进行了讨论，并采用了许多行业标准。

在尝试尽可能学习一切、尝试新的测试方法、度过漫长的工作周的同时，我还不得不与公司中根深蒂固的观点进行斗争，即在生产中发现的缺陷是QA的过错，而不是测试得不够好。

在晋升一名团队成员时，我不得不与一些奇怪的流程作斗争，再次多亏了美国的同事，最后导致他们失望离开。这真是可惜，因为他们真的很优秀。

我进行了大约40-50次手工测试和测试自动化工程师职位的面试，还是无法找到好的测试人员。我发现自己不擅长面试，而且公司也没有吸引到太多的测试人才，至少看起来是这样。而且我只获得了一个入门级职位的预算。

最后，我找到了一个手动测试的候选人，但我从未能够将他引导到正确的方向上。我的另一个团队成员，在我的团队工作了3年，虽然拥有计算机科学学位，但无法理解IT基础知识，而我们测试的产品对他们来说常常过于复杂。我尝试了“以身作则”，但事后看来是个错误。我在那里的时候，除了两个人之外，我不得不与10个不同的测试人员合作，其中一个甚至没有被分配到和我相同的产品，所有人都缺乏基础知识。即便对方有一些基础，我至少能够帮助两个人提升他们的技能。

当你领导的团队远远落后于你，对你望其项背时，仅仅通过手把手指导是不起作用的。

在我工作的3年8个月里，我最大的成功是在一周内培养了一名实习生。她是一位同事的女儿，非常聪明。在介绍了软件测试的基本知识和我们的产品后的半天时间，她在接下来的4天里表现出色。她的测试能力轻松超过了其他两名与我一起负责产品的同事。

不管怎样，我意识到在这个工作中，我不适合担任任何领导职位。早早地失去了一位同事，无法培训初级员工，无法申请更多（资深）员工的预算，无法使一位同事提前晋升，以及其他不当行为，这些都是我失败的原因。此外，我在三年内三次更换了汇报线，没有人想要我和我的团队，但也不能怪别人。

被老板过度管理是我工作中的一个低谷。我经常有大约100个任务积压，每天要在一两十个任务之间切换。我从来没有能够完成超过70%的任务，能够达到这个进度已经算是幸运了。大多数任务在我开始之前就被取消了。我的团队经验不足，无法帮助我完成任何事情，这让我很失望。每个星期一早上的一对一会议上，我不得不解释为什么我在任何一个选定的任务上都没有取得进展，真是有“趣的”时光。

不过，我真的很喜欢负责的产品。我很快就理解了这些产品，再次感谢系统思维，我理解了数十个配置变量之间经常干扰的复杂性。我理解了12个不同客户的14个设置在同一产品的10个不同版本上的情况。系统中脏数据的复杂性有些棘手，但对我来说还是可以处理的。

然而，我花了太长时间才理解产品的基本性质，而不是产品的工作原理，以及如何以更高效的方式重新组织测试集。但由于产品的设计非常以客户为导向，在整个公司中几乎没有基本的设计和架构能帮助理解。开发人员被组织在团队的模块孤立中，都在处理一个庞大的单体应用，然后将其丢给QA部门，看看它是否真正有效。

其中我最印象深刻的事是修复一个bug，开发人员来找我，告诉我他们修复了它，但他们不知道如何进入这个界面，所以他们无法自己测试验证。

此外，我们不断努力推动引入单元测试，这样我们测试就不会一直受到基本的阻塞问题的困扰。而在我离开之前，开发甚至都没有编写任何单元测试。我们仍然处于“试着看看应用程序是否能启动，然后交给QA”的水平上，并不是说这个规则一直被遵循。

与业务架构师密切合作，不时扮演其中之一的角色，帮助我形成了一种思维模式。我影响并设计解决方案，负责部分架构和设计决策，积极参与产品开发，真的很享受这个过程。

然而，在我忙于这些工作的同时，与愤怒的客户通话和开会，我忽略了照顾自己，最终在一个美好的十二月晚上住进了医院。从那一年开始，我将每年的评估（包括绩效评估和员工满意度调查）与那次事件进行比较，这可能透露了是谁给出了反馈，但我想他们也知道，因为只有我写了很长的文字。

在那家公司，失败和成功总是很接近。我有很多喜欢的同事，也有一些我无法忍受的同事。我在一家国际公司工作，一整年都在说英语，这让我非常喜欢，我努力想要成功。我从Sally Goble在Pipeline Conf上的一次演讲中了解到这种方法，她谈到通过解散QA部门来消除开发人员的安全网，这对我来说是完美的解决方案，我向老板和老板的上司提出了这种方法。虽然我的老板可能害怕，可能是因为他多年来一直培养了对QA的指责文化，但老板的上司喜欢这种方法。我的建议是将我调到业务分析部门，因为我大部分时间都在那里，将其他两个剩下的QA调到开发团队作为嵌入式测试人员，但最终老板没有接受。因为我认为这是改善公司对质量和责任的理解的唯一途径，所以我做了选择-辞职。
后来我发现，我的方法奏效了，开发人员现在更多地拥有了质量和责任。我的一位美国前同事那里得知这家公司似乎在没有测试人员的情况下反而做得相当不错。
在那段时间，我职业生涯中发生了另一件重要的事情。我参加了我的第一个测试会议，在现实生活中遇到了我在Twitter上认识的人，进行了我的第一个会议演讲和第一个研讨会。我开始写博客，并对测试社区投入了很多精力。
我有一个理论，即在2016年，我可以去世界上任何一个地方参加测试人员的聚会，至少认识一个测试同行。

QualityMinds -与众不同的测试咨询工作

QualityMinds是一家软件测试咨询公司，专注于提供高质量的咨询服务，以帮助客户实现业务目标并取得成功。

在2016年9月，我职业生涯的一个新篇章开始了。我加入了QualityMinds，这是一家年轻而活跃的咨询公司，当时主要从事软件测试领域的工作。QualityMinds给了我一个机会，可以从事咨询工作，而无需整周都在外出差。除了两次研讨会，我在将近五年的时间里几乎没有出差，只是去参加测试会议。我喜欢我的家人和家庭。整周都在外出差，工作时间长，住在酒店里，希望周五能早点结束，这对我来说不适合。

在QualityMinds的这段时间里，对我的职业生涯来说发生了几件重要的事情。

● 在我的第一个客户那里，我经历了第一个真正的敏捷项目，到目前为止可能也是唯一一个。我不是指每天都有站立会议和两周的迭代周期，而是指不断实验和改进，并真正意识到这一点。

我是那个项目上第一个有经验的测试人员，再也没有见过一个团队像他们一样践行“每个人都可以测试”的理念。

● 在我的第二个任务中，我大部分时间都感觉自己基本上是无用的，但我学到了一些东西。遵循一些基本规则，持续合规是可能的。一个合适的BDD框架需要很多规范和工作，但可以很有趣，也可以节省很多时间。我还学到了即使作为一名高级测试人员，每天也可以花几个小时做一些简单而基础的任务，比如分析夜间测试、稳定测试、平衡测试套件、保持开发容器更新、维护报告等。这些对你来说可能并不重要，但对整个团队来说都很重要。当我在这个任务结束后离开时，不久后我就得知我在项目中留下了一个空缺，因为我似乎完成了许多对项目基本稳定性很重要的任务，这些任务需要超过几个人来接手，而我并没有意识到它们的重要性。

● 在我的第三个任务中，我从第一周开始就感觉像在家里一样。我的意思是，这个项目的面试过程是我和项目的两位高级人员在一个房间里。面试开始时，他们说：“所以，我们在这里是为了向你推销这个项目，让你决定加入我们。”我必须补充一点，这个项目是在第二个项目的姐妹公司中进行的，人们彼此认识已经很久了，所以肯定有人对我有好评。

入职非常顺利。我很快就理解了所有业务流程，技术栈也很熟悉，自动化测试集也处于良好状态。我很快就能参与讨论，有时甚至能影响产品决策（这对于一个外部测试人员来说是很少见的）。我主要学会了维护、稳定和开发自动化框架，并将其提升到一个新的水平。我还能够教一些身边的测试人员一些技巧。我以一种能够修复错误、实现小任务并以任何我能帮助的方式来加速可交付质量的实现的方式来了解代码库。

18个月后，我必须进行一次强制性休假，当我回到项目时，被分配到一个小而敏捷的团队，负责实现具有生产稳定性的演示能力。我的任务现在默认还包括开发任务，这对我来说是一种荣幸。

● 在我最后一年，我还有一个内部任务，帮助新同事从零开始开发一个项目。基于我过去使用的三个框架的经验，我从零开始实践了一种新型的测试框架，

在这近5年的时间里，并不都是一帆风顺的。由于可能主要是自己施加的压力，我加入后不久就停止了学习，完全停止了。我在工作中学到了很多，但在外面却没有学到一点东西。

我们每周至少在客户那里工作40个小时，每周都有几个小时用于团队任务，因为我们非常自组织，而且偶尔还会花一些时间为整个公司做事情。

在我开始在QualityMinds工作的第一天，当我坐火车去新工作地点时，接到了Kris Corbus的电话；Rosie同意我们可以在德国组织第一届TestBash。这是一个很大的机会，我和QualityMinds的CEO交谈后，我同意了。因为Michael愉快地答应给我所有需要的支持。而且我确实得到了，整个公司都给予了我支持。

13个月后，我和Kris，在Vera、Marcel和Daniel的帮助下，欢迎了大约200名测试人员参加了第一届TestBash德国站。从TestBash的角度来看，这是一个成功。

个人而言，事后我不得不意识到，在星期六的开放空间日，我开始出现了疲劳过度的迹象。当时我没有意识到这一点，也没有寻求专业的帮助，试图坚持下去，没有请一天病假，在客户现场继续100%的工作，结果导致了大约18-24个月的轻度到中度的疲劳过劳，伴随着抑郁、疲劳、倦怠和几乎没有精力做任何事情，除了最基本的功能。这种做法我强烈不推荐。有时候你必须接受一个事实，那就是身体不对劲的时候，你需要主动寻求帮助。

为了以积极的方式结束这一章节，我还在几个会议上获得了两个演讲机会。我重复了2016年的演讲，但版本较差，直到问答环节我才意识到这个演讲的潜力。而在2019年，我做了一个关于“测试机器学习算法101”的演讲，我对此仍然有些自豪。

我还作出了一个个人决定，停止在会议上演讲。我没有太多有趣的事情可讲，而其他人通常更擅长这个，最重要的是，会议的舞台上已经充斥着中年、白人、西欧、男性，没有必要再增加这一群体的人数，当我不申请演讲时，就增加了其他应该被听到并为舞台带来多样性的人的机会。

当我离开QualityMinds的那一天到来时，我收到了一个来自柏林的中型医疗技术公司的人的消息，他们正在寻找质量工程师，并且可以100%远程工作，我心动了！

Ada Health – 质量工程师应该做什么？

Ada Health是一个德国医疗健康管理平台，利用人工智能技术汇集数千种症状和病症，并将医生的专业知识进行结合，用户可输入自身病状，通过该平台进行检索，同时为用户提供个性化治疗方案。

大约两年前，我作为一名质量工程师加入了Ada，但我仍然不太清楚这个角色的含义，而且我对此并不在意。好在Ada的所有质量工程师都可以根据自己的特长来发挥作用。每个人都能够带来自己的优势。如果你对Ada的质量工程部门的其他成员有一个大致的了解，你就会知道他们都非常优秀。

在Ada，善良的人们让我在许多层面上提供帮助。我融入了一个很棒的团队，有着令人惊叹的同事。在团队内部，我能够为集成测试实施了一个端到端的测试框架，这个框架不仅仅适用于我的团队，还可以为其他团队提供帮助，因为在我加入之前没有适合的框架。

我能够支持流程优化，包括发布和合规方面的工作。我继承了一个糟糕的脚本集合，用于创建发布文档。与此同时，我们将这个工具推广到了Ada的几乎所有团队，并在每次发布过程中为这些团队节省了大量时间。

我在工作中有三分之二的时间并不是因为有人要求我这样做，而是因为我认为通过参与这些方面的工作，我可以帮助公司。在我职业生涯中经历了18年的好坏经验，我认为这些都是我可以帮助提供更好、更快、更轻松的产品的任务，加速可交付质量的实现。

半年多以前，由于必要的成本削减计划，我们失去了很多人，并且不得不重新组织。我们正在慢慢从这次削减中恢复过来，并重回正轨。我们与另一个团队合并，而那个团队在削减了质量工程师。所以现在我被嵌入到一个拥有四个不同模块的团队中，比其他团队都多。我还参与了其他几个项目。我们刚刚通过组织架构调整得到了一个新的工程经理，我期待能与他一起工作，因为我们失去了我曾经遇到过的最好的工程经理之一。我们的产品经理在一段时间前加入我们，现在终于完成了入职，并能够推动“我们旧有”的应用程序的相关事项。

在困难的时期，不仅仅是我尽力而为，整个团队在过去的8个月里都在努力填补空缺，保持团队运转。我为能成为这个团队的一部分感到非常自豪。在削减之前，我们是一个绝对的梦幻团队，而在削减之后，我们证明了这个团队是多么出色地合作。我希望我们能在新的结构中继续这个旅程，因为我们的团队目前正在发生更多变化。

一旦我意识到我不能在一夜之间改变整个公司，我就会欣然接受每一次朝着正确方向迈出的小步伐。从我的角度来看，有个人的挫折，也有很多停滞不前，但是偶尔也有一些小进展。还有很多工作要做。人们仍然愿意改变。但这必须是缓慢而谨慎的。所以我们就慢慢来吧。只要这家公司愿意接受我作为他们同行的一员，我将继续留下来，从公司的深层次推动整个地方缓慢而稳定地朝着正确的方向发展。当然，这个正确的方向是从我的角度来看的。

回首20年

我作为一个专业人士，通过20年的测试经验和3年的开发经验，找到了自己的专长领域——广义化。我对很多领域都有一定了解，可以在许多领域提供帮助和支持。我有快速学习新主题的基础，也有快速深入研究我已经了解一些的主题的能力。我在2016年的TestBash Brighton演讲中提到过这一点。我在识别邓宁-克鲁格效应方面有一半的能力，但当涉及到冒名顶替综合征时，我仍然不擅长。

这也非常令人沮丧。我拥有的每一项技能，即使是那些我可能擅长的技能，周围的人很可能比我更优秀。多年来，我一直在寻找一个可以专攻的主题，也许能成为某个领域的知名专家。除了几乎一直脾气暴躁之外，我没有找到任何东西。每当我试图深入研究一个主题时，我都会被其他同样有趣的事情分心。有那么多有趣的主题，我无法只专注于一两个。而且，几年前我就停止了学习，所以为什么还要费心呢？我花了将近20年的时间接受这个事实，即总有人比我更优秀。我拥有如此多不同的技能，要在其中一项上做到卓越是不可能的。所以现在我接受这个事实，并感激周围的专家以及能够发挥自己技能的机会。

正如我之前告诉你的那样，我在认识和理解事物方面通常比较慢。20年来，我一直忙于自己的事情，很少有时间停下来反思。放慢速度以加快进程是非常正确的，但我往往不遵循这个建议。我也往往不会早早寻求建议，我想自己完成任务。我不会磨刀，因为还有很多树要砍伐。

去年，一个聪明人问我为什么每周都要工作这么多小时。那是一个让我停下来思考的时刻。我想出的答案是复杂而令人沮丧的：

我这样做是为了弥补周围每个人都比我聪明的感觉。作为一个大学辍学生，虽然我认为自己是慕尼黑地区最好的三到五个职业培训学生之一，但在接下来的几年里，我大多与一些非常聪明的人为伍。自从加入测试社区后，这个数字更是倍增。在我目前的公司，几乎每个他们雇佣的人都是他们领域的专家。我通过更加努力和加班来弥补这种自卑感。有些人说这是不可能的，但我可以有效地集中精力工作10-11个小时大部分时间。

此外，我往往会吸引很多工作。我的任务清单总是被各种各样的主题填满。我看到很多需要优化的地方，虽然我刚才说过，我周围有很多聪明的人，但我宁愿自己完成工作，这样我就知道结果符合我对系统的理解和喜好。我不能委派任务，所以我最后手头上的任务更多。我刚刚在桌子上列了一个长期和中期的主要主题清单：有14个！

说到复杂性。正如我在这篇博文中早早写到的那样，事后我发现自己在系统思维方面有一定程度的天赋，似乎比一般人更好一些。我在这方面算不上出色，但可能比其他人要好些。在我从2012年到2017年的高强度学习阶段，我也接触到了Cynefin意义构建框架。我可能没有完全理解其中大部分内容，但基本思想非常迷人。我从中汲取了对我有用的东西。Cynefin将系统的部分划分为明显、复杂和混乱的领域。多年来我学到的是，我在理解复杂系统方面感到自在。与Cynefin建议的首先理解自己处于何种情境不同，我开始将一切都视为复杂的。也许是为了避免意外，避免自满的悬崖，或者因为20年的经验告诉我，系统很少是明显或简单的，而即使是复杂的情况，尤其是涉及人的情况下更是如此。也许这也是为什么我很难给出简单的解释的原因。我总是试图考虑到依赖和复杂性，避免人们认为事情很简单。因为事实往往并非如此。

当思考我所做的和我能做到最好的事情时，我会说是打下和改进基础。打下基础是一个极其复杂的话题，要做好并在各个领域协调一致是很困难的。

我目前负责的大部分任务和我感兴趣的任务有：

• 发现现有流程中的问题并找到缺失的流程

• 帮助建立应该存在的事物

• 为他人提供可以采用或构建的基础

• 完成必须完成的简单任务

• 处理基本任务，即日常工作，这些任务对很多人来说并不吸引人

• 自动化基础工作，这样更少的人就需要担心它，并可以将精力集中在其他事情上

我更喜欢做这些事情，是因为我见过不同的时代。我从一个完全成熟的ITIL项目中开始。你可能对ITIL有什么看法，但基本上任何想要成功和可维护的IT项目都将遵循在ITIL世界中描述的各种流程。处理这些流程的方式会因雇佣一群服务经理和试图在旁边管理之间而有很大的不同。但是没有这些基本流程是不可选的。即使是最小的项目也需要处理所有这些流程。

2019/2020年我在QualityMinds的时间里，接受了过去23年中最有用的培训，即iSAQB架构基础课程。这门课对我来说太惊人了。虽然我是这个班中唯一一个非开发者，也是唯一一个没有真正学到新东西的人。是的，这仍然是有史以来最有用的培训。大部分内容都是我在其他项目中已经看到和经历过的事情的确认。部分内容是我早已忘记的（这是我大脑中的另一种现象）。这门课最好的地方是它对一个良好的IT项目的支撑和基础构成的不同主题的浓缩。如果我能够保持更新并学习更多关于几个技术主题的知识，IT架构师可能非常适合我。

当我周围的很多人都追随潮流时，基础常常被忽视。没有良好的基础和支撑，新潮的东西不会持续很久。而且总有人必须做这份工作。那为什么不是我呢？当你在社交媒体上看到我为人们讨论基础事务并对新潮的东西持怀疑态度时，也许现在你能更好地理解其中的原因了。

在过去的20年里，我发现自己非常不擅长向他人解释软件测试的基础知识。我从来不擅长这方面，也没有学习或希望变得更好。对于软件测试，我只是基于系统思维、常识和我积累的知识来进行，分析潜在的风险。如果没有必要，我不会以结构化的方式进行测试。我并不认为自己是一个糟糕的测试人员，实际上，在过去的大部分时间里，我在工作方式上相当成功。但我不是一个好的软件测试人员或软件测试教师。我无法教给别人我如何进行测试，因为这是非常个人化和复杂的过程。

我的测试自动化能力可能略高于平均水平，擅长测试流程改进和项目管理，帮助团队改进质量流程。我更喜欢在过程的早期阶段测试想法并做出决策，改进应用程序的架构和设计。我在许多其他与软件测试或质量工程师相关的事情上表现得更好，尽管这些事情可能不会在角色描述中出现，而且周围的人通常也不会对此有期望。

加速实现可交付质量的成就。我在这篇博文中多次提到过这个口号。如果我没记错的话，这个口号是由Alan Page和Brent Jensen在AB Testing播客的第50集左右引入的。这些口号导致了大约在第70集左右引入的现代测试原则。这个播客在过去的7年里对我产生了最大的影响。Alan和Brent用言辞表达了我所做的事情，而我自己却没有意识到。这个播客经常挑战并以相当极端的立场表达观点。但我喜欢这一点，因为它总是挑战我的现状。对我来说，第一条指导原则一直是加速实现可交付质量的成就。这是我在过去20年来一直努力做到的。大部分时间我甚至没有意识到这就是我的动力所在。

Guiding motto no. 2是我朋友Stu Crocker大约两年前提出的口号：“提高质量就是消除不必要的阻力”。虽然过去8年里，质量这个词是我经常回顾的话题之一，但这个声明是我为数不多的顿悟时刻之一。感谢Stu在疫情期间与我进行的长时间交谈。

每次新项目都会出现同样的问题类别。每次都是一些基本的测试流程缺失或对测试应该如何进行的理解不足。需要稳定事物，使交付更快、更可靠。提高对质量实际含义的认识。并经常填补软件开发基础知识的空白，这是所有其他主题的基础。有时候感觉就像 《Groundhog Day》 一样。PS: 寓意每天经历重复的事情。

上周，测试部的人问我对自己的职业感到自豪的是什么？除了我之前提到的一些成就，我最自豪的是没有放弃测试工作。测试工作经常让人沮丧。你必须处理不工作的软件、系统或流程。你必须成为传递坏消息的人。你必须处理失望的人。你通常是最后一个考虑的对象，经常被遗忘，别人告诉你该做什么或如何做你的工作，你必须为自己在团队和公司中的地位而奋斗。测试工作通常被认为是每个人都能做的愚蠢工作，所以雇佣人员，培训他们几天，他们就可以用较低的薪水来做这份工作。或者稍微训练一下的人只需编写一套好的测试用例，然后就可以将测试外包给更便宜的劳动力。测试人员是替罪羊。测试人员在公司中不被视为其他团队的同行。

虽然这些观点并不适用于每个地方，但我经历过这些问题，我仍然听到其他测试人员最近遇到这些问题的故事。心理健康是测试社区中一个非常重要的话题，有很好的原因。

我为自己是一个测试人员感到自豪，虽然我很糟糕地进行自我营销，或者很难说服其他人采用更好的方法，但我喜欢我的工作，我喜欢它带来的多样性和可能性。是的，我讨厌一次又一次地经历同样艰难和繁琐的入职过程。但最终这通常是值得的。我不是像其他任何测试人员一样的测试人员，我认识的大多数测试人员也不是。我们在产品和项目的许多层面上为其增加价值，每个人都有点不同，有自己的风格，我为自己是这个疯狂群体中的一员感到自豪。

还有一件事我感到自豪。在过去的20年里，我在全球各地的测试社区中结识了几个好朋友。这些是我在其他情况下不会遇到的人。来自英国各地的一些了不起的人，特别是威尔士的南部和北部、英格兰的东部和中北部、俄亥俄州的哥伦布、乌得勒支、里加、慕尼黑、墨尔本、根特、班加罗尔、柏林、北卡罗来纳州的夏洛特以及北美其他地区、里斯本等等。我甚至可以称呼这个社区中最杰出的人之一为好朋友，他恰好住在我们附近的城镇。当然还有一些我忘记列出他们居住地的人。我对你们所有人都心怀感激，希望你们都知道你们是谁，以及你们有多受人赞赏。你们的友谊不会被视为理所当然。

够了抱怨，够了沮丧的自我评价，够了来自战线的无聊故事。是时候迈入未来的20年了。无论这段旅程将带领我去哪里，我敢打赌它将是为了改善基础，创造更好的解决方案并更快地交付产品。