军队可以教测试员什么？ 测试方法的两个极端是什么？ 如何解释付款后的技术债务是红色的？ 前面的问题有什么共同点？
一般的事情是，尽管它们各有不同，但它们都接近一个人。
吉姆·霍尔姆斯（Jim Holmes）拥有数十年的IT经验，该经验始于80年代的美国空军-毫不奇怪，他准备讲很多话。 “测试文化”的概念对他很重要，我们问了他一些问题，这些问题可能相差很大，但最终与测试文化有某种联系。
-介绍性问题：请介绍一下您自己。-我叫Jim Holmes，是我自己的公司Guidepost Systems的独立顾问和所有者。 我专注于软件交付质量，并且从事编程工作大约已有20年，在那之前我已经服役了很长时间。 大约15年前，我在几个不太成功的项目上工作时就对质量非常感兴趣。 总的来说，我做了很多测试自动化，单元测试，集成测试，尤其是功能测试，UI测试。 特别是，我在一家公司编写了出色的Telerik Test Studio工具。 在过去的5至8年中，我不仅开始处理纯粹的技术问题，而且开始处理整个供应的质量-也就是说，供应团队与业务之间的关系如何。 但是同时，我仍然调试WebDriver脚本很长时间，并解决了由于错误的异步操作而导致的周期性故障等问题。 我住在俄勒冈州的阿什兰市-提醒您，而不是波特兰（在美国，您说“俄勒冈”时，通常每个人都认为“波特兰”）。
-对于测试人员来说，传记中最不寻常的部分可能是兵役。 你到底在做什么？-我曾在美国空军服役，因为我一直受到飞机的启发，而我父亲是飞行员。 当我只有4岁时，他带我去了第一次飞行。 在空军，我很幸运，我曾在E-3小组服役-这是一架超大型飞机，顶部有巨大的磁盘，负责雷达和某些通信系统的运行。 十一年来，我一直在管理和调试这个大型电子系统。 在没有航班的时候，我管理了中队的计算机。 大约在那时，在工作场所创建网络成为可能。 另外，由于我是军人，所以我得到了教育，因此我去了一所夜校学习软件。
关于您的问题，服兵役的经历不仅对于测试人员来说是不寻常的，而且在许多其他领域也很不同。 我可以说，至少我在那里教过纪律。
-是的，对于军队来说，首先想到的是纪律。 因此，许多测试人员和开发人员都会遇到问题。 您认为他们可以向军方学习吗？-这是一个非常有趣的问题。 事实是，我所学的学科与伞兵有所不同，也就是说，没有持续不断的哭泣和惩罚。 我受教给我一种纪律严明的测试方法，通常来说是解决问题的方法。 工作场所的纪律也很重要-了解什么是等级制度； 为了学习如何在其中工作，人们必须能够与上级沟通。 这种纪律对我很有帮助。
25年前，我离开了军队-是的，我是一个老人-由于那里的工作重点，在民政部门的工作与我以前的经历形成了非常有趣的对比。 在军队中，我曾乘坐飞机，这架飞机应该监视大范围内的敌人并确保自己的安全。 任何错误都将威胁我们士兵的生命。 我不想夸大其词，但确实如此。 因此，当IT部门的某个人开始恐慌并要求立即解决任务时，由于我的纪律和我的经验，我总是可以向人们保证-我们不会威胁到某个人会死，而且我们不会输每分钟数十万美元（我曾经遇到过这种情况）。 我们常常会感到恐慌，并让企业或股东不必要地恐吓我们，并造成不合理的紧张关系，对任何人都没有好处。 也许军队教给我的最好的事情是具有以下能力：要求保持冷静，合理评估局势并事先计划我们的行动，而不要因人为制造的恐慌而无所顾忌地执行任务。
-也就是说，您需要花时间思考策略。-是的，而且在IT领域，这个问题已经存在很长时间了：持续要求立即交付项目。 主要的事情是要迅速做，而确切地做的是次要的。 通常，如果正确进行对话，就可以控制这种压力。 对此，重要的是能够说，如果我们花更多的时间并理性地解决问题，我们将创造更多的价值。
-让我们继续您当前的活动。 在工作中，您熟悉他们如何以不同的方式在不同公司中进行测试。 显然，这种方法可能取决于例如公司的规模。 但是可能存在许多不太明显的差异-您能谈谈它们吗？-这是一个很好的问题。 除了独立工作外，我还与俄亥俄州哥伦布市的Pillar Technology合作。 我认识该公司的人已有很长时间了。 现在大约有250人在这里工作，几乎所有人都遵循极限编程（XP）的原则：他们有很多单元测试，并且开发工作也经过深思熟虑。 三年前当我被录用时，我是唯一的测试员，他们创造了非常高质量的产品。 他们完全从XP的位置，从测试驱动的开发的位置开始进行测试。 这是一个很棒的方法，他们已经成功地应用了它，而我和其他一些员工设法改变了软件交付的某些方面。
您可以将这种经验与过去三年来我咨询过的另一家公司进行比较。 这是一家工业公司，在《财富》杂志的前十名中，它在全球拥有约20万名员工。 他们有一个非常大的IT部门来满足公司的内部需求。 那里有很多好人，但是他们的考验停留在1980年代或1990年代的实践上。 该公司大量生产完全相同的产品，许多公司习惯于在生产例如球轴承的过程中很可能估计出预期的缺陷数量。 但是问题是他们将这种想法转移到了IT部门。
我与四名通常非常聪明的员工进行了交谈，这些员工参与了从多个项目中收集缺陷报告并试图预测未来可能出现的缺陷数量。 我告诉他们，这在行业中是相当合理的做法，但是他们将如何区分为移动应用程序计算的指标和Web服务的指标？ 他们回答说没有区别。 因此，我很幸运在不同的测试方法和文化范围内看到了完全相反的观点。
此外，我曾与一些无法摆脱启动阶段的公司合作，这些公司一直在不停回头的情况下工作，而不是试图解决整个问题。 然后，经过数年，在复杂的项目中，这个阶段出现的问题开始被清晰地感知到，我必须说服人们这种方法是错误的，现在我必须停下来思考一下自己的行动。 总的来说，我的回答有些笼统，希望我还没有完全弄清你的问题。
-在您的咨询实践中，有时候在完成与公司的合作后，他们告诉您“没有什么比这更好的了”？-我告诉你一个秘密，那就是人与人之间很难相处，我们是很难相处的生物。 这就是为什么我有那么多白发的原因之一（第二个是我的女儿）。 改变一个人很困难；改变一个组织中的人更加困难。 是的，我经常遇到这种情况。
关于一些顾问，我们甚至说他“精疲力尽”。 这是由于以下事实：我们正在做出很大的努力来改变组织中形成的文化，并且我们不得不在个人层面上处理很多问题-人们害怕改变，他们不断地使自己相信这是必要的，并寻找适合他们的道路。 无论我有多强壮，我都不能随便说：做某某事。 需要达成共识。 为了完成某项工作，这项工作需要进行多年，而当您似乎已解决问题并去咨询另一个组织时，您将在这里遇到与上一个地方完全相同的问题。 再一次，您要花费大量的时间和精力，然后事实证明，在第一家公司中，一切都已经恢复到以前的状态。
人们是如此的安排，我们很难相处，我们经常回到过去的习惯。 尽管如此，还是有一些真正成功的例子。 有些组织设法巩固您所取得的成果。 总的来说，我会说一个平衡。 我继续从事这项工作，因为这些成功案例非常令人满意。
-在您的博客中，您描述了您的专业原则，并在其中谈论了开放，始终学习新事物，多听而不是说话，适应和对人友善的需求。 我想知道IT是否真的有助于对人的良好态度？-是的，有帮助。 我说过我曾在军队中服从严格的纪律，但我们必须了解纪律和结构性绝对不会干扰与他人的良好关系和同理心。 你知道苏格兰厨师戈登·拉姆齐吗？ 他主持了《地狱厨房》节目。 我之所以提及他，是因为昂贵餐厅的厨师常常对员工表现得令人作呕-他们大声疾呼和侮辱。 我讨厌这种对人的态度。 对我而言，彼此之间的良好态度很重要。 如果您想实现任何改变，那么您需要了解人们为什么会拒绝它们，也就是说，您需要同理心。 它会让您使人自己想要改变。 这种方法比大喊大叫并要求人们服从而不问问题要有效得多。 每个人都有自己的思想，自己的灵魂和经验。 我不想深入研究哲学，但我相信，从长远来看，良好的态度和同情心将使您取得丰硕的成果。 所以是的，他们有帮助。
-您进行研讨会，并且在其中一个研讨会上教不懂编程的编程人员。 我有两个问题。 首先，哪些问题最常导致人们无法进行自我编程？ 其次-您认为在接下来的一年中，自动测试将胜于手动测试吗？-根据我的经验，人们通常不是因为技术困难而是因为恐惧而打扰。 我可以从我在《财富》 10年公司的经验中举一个例子。 我与一组进行手动测试的测试人员一起工作，我们需要使用WebDriver进行自动化。 其中，大多数甚至都无法打开Eclipse开始编写代码。 他们害怕编写用于自动化的脚本，因为根据他们的理解，这与编写可伸缩的Web服务或具有多线程的数据库并无多大区别，也就是说，开发人员已经学习了多年。 这种恐惧使他们无法做简单的事情。
我目前正在基于一个讲习班为测试部开发一门课程，在该讲习班中，我解释说您不需要多年的实践即可简单地打开Java文件，C＃或Ruby脚本，阅读并理解一般结构或编写在WebDriver上进行简单测试。 而且，即使您不完全了解代码中发生的所有事情，也可以对其进行总体评估，因为例如，您知道一种方法不应占据三个屏幕，if语句不应包含四个嵌套的嵌套-这将很困难。要测试，您不能给变量一个字母的名称，依此类推。 我认为，在最初阶段，主要的困难是克服对您将不得不解决极其复杂的任务的担忧。 我一直很想知道我的客户有多快摆脱这种恐惧-您只需要给这个人一个简单的单元测试，并请他编写安排，行动和主张即可。 我认为这个人为因素非常重要。
我们使用的大多数技术并不复杂，很少涉及无人驾驶汽车。 我曾经在印度为一个客户举办过一次研讨会，当时有一位没有任何编程经验的经理。 这位经理起初非常生气，其原因恰恰是我刚才谈到的恐惧，而这种恐惧被叠加在不愿显得愚蠢的态度上。 但是，在第一堂课结束时，他投入了太多的笔试，以至于我不得不在课程结束后一个小时将他赶出听众-他坐下来，将自己埋在监视器中，与研讨会的另一位参与者配对，并为工资算法编写了简单的测试板。 这里的要点根本不是我的教学技能，它只是说明这种恐惧或缺乏恐惧的重要性。 在这里，我们谈论的是人性固有的事物。
您的第二个问题与从手动测试到自动测试的过渡有关。 我在这里有一些经验，我在一家从事测试自动化的公司工作了三年。 我认为应该以不同的方式提出问题，而不是为测试自动化而努力，而是为测试人员的发展及其获得许多技术技能而努力，其中之一应该是自动化测试。 我希望看到这样的测试人员，他们具有用户故事，规范和要求，可以就相当专业的内容与开发人员自由地进行对话，并共同寻找将在代码中体现的解决方案。 这与测试人员教授编程的方法有所不同，只是能够编写WebDriver脚本。 当然，这项技能也很重要，但我认为这并不是最重要的。 我认为，超级任务是与开发人员进行对话并确保他在编写代码时牢记测试过程的能力。 甚至TDD也已经是一个重要的成果-我相信所有组织都应该能够那样写。
最重要的是，正确交付的测试远远不能简化为单元测试或集成测试。 人们通常对测试典型的代码执行路径感到满意-所有测试都通过了，复选框无处不在，实现了100％的代码覆盖率。 但是，这不能保证代码的质量吗？ 当然，尽管这些也是必要的程序。 因此，根据我的理解，测试人员不仅应该在WebDriver中编写一些功能测试或测试，还应该考虑如何与开发人员和业务分析师建立更紧密的合作关系。 您可以，例如，尝试
暴民编程 。 总的来说，我认为自动化是一种工具，而不是目标。
-作为Heisenbug的组织者，“与开发人员紧密合作”这个词与我们非常接近-甚至会议的口号是“关于测试，但不仅限于测试人员”。 关于这种合作，我想提出以下问题：作为具有丰富测试经验的人，您想告诉我们的读者和程序员什么？“那我们不都是邪恶的！” 测试人员通过自己的行为而声名狼藉。 他们会在会议上以最少的细节发现问题，经常交流错误报告，而不是言语。 开发人员早上来上班，会看到50个错误报告，其中介绍了语法错误和页面未对齐。 我曾担任过两个职位，并且我知道程序员对此有何反应。 这是传统测试的一部分，而我本人也曾经有过这种行为。 但是更习惯于现代方法的测试人员知道，与他交谈比用bug报告轰炸程序员更容易和更好。
我认为，对于开发人员而言，重要的是要了解一个好的测试人员可能非常有价值，而且如果您事先与他交谈，可以节省很多时间和精力。 这就是约束理论所说的。 假设我是一名开发人员，并且看到测试仪检测到某些问题。 如果不是直接在TFS或其他地方写这篇文章，而是去找他亲自交谈，那么这段对话将帮助我减少编写的代码中的缺陷数量。 此外，在个人交流中，大多数测试人员通常都不会感到恐惧。
通常，如果您摆脱了关于测试人员的常见刻板印象，那么，作为开发人员，您可以提高代码的质量-不幸的是，这些刻板印象通常具有基础，我们也需要为此而努力。因此，我真的很喜欢在您的会议上您试图召集具有不同专业知识的人。这很重要，因为很长一段时间以来，所有主要的专业会议和社区组织的大型会议都严格限制了自己的范围-仅限测试人员或开发人员。如果我们开始互相交谈，那将是一次很棒的会议。, , : Heisenbug , Fortune 10. , ? 6-7 Heisenbug , .
— . «The leadership journey» . , : , , — . ?-我认为这是IT部门的普遍态度：您是否参与数据库管理，编程，测试，项目管理都没关系。您的工作做得很好，很舒适，经验丰富，在这个角色中具有影响力。与此相比，承担更多责任和与他人合作的恐惧听起来不那么自在，并导致拒绝。因此，在我的书的开头，我建议了一些方法来找出您是否真的需要所有这些，以及成为一名领导者意味着什么。可以执行某些领导功能而无需上移层次结构。团队中比其他人拥有更多经验和技能的人将非正式地扮演团队领导者的角色。因此，不一定要成为经理：也许您只是认为自己需要在团队中发挥很大的影响力。尽管在某些组织中，人们已经获得了一定的经验，这却是理所当然的，一个人开始担任领导职务。他被任命为技术经理，除编写代码外，他现在还负责团队的资格认证。在更高级别上，他通常停止编写代码。因此，一般来说，领导可以采取许多不同的形式。我们领域的特殊性在于我们害怕担任领导职务，因为我们害怕因为停止编写代码或测试而失去技术技能。另外，如果测试人员不参与开发，那么他将很害怕领导程序员。所有这些问题都是自然而然的，克服这些问题是我们行业领导地位不可或缺的一部分。-还有一个比较开发人员和测试人员的问题。在开发人员中，有关远程工作的讨论很活跃：有些人认为应该默认实践很长时间，而另一些人则认为不能用Skype代替实时通讯。您是远程工作人员-您对测试中的远程用户有何看法？-自女儿出生以来已过去的18年中，我在13或14岁时从事过远程工作。因此，我对这个问题确实有意见。我认为，远程工作是一个重要的工具，它使您可以扩大可能与之合作的人们的圈子。例如，与住在另一个州或另一个大陆的人一起。因此，我是远程工作的支持者，在某些情况下它非常有用。同时，必须认识到，在远程工作时，通信和生产率会出现重大问题。纯粹从技术角度来看，一个完全或大部分在远距离工作的团队应具有良好的基础架构。这样的团队的每个成员都应该遵循DevOps原则。几天之内我们都无法联系服务器管理员获取调试日志。另外，您需要认真对待通讯工具的组织。而且，如果您认为Skype和某些Messenger足以满足您的需求，那么Skype for Business不会使用它并使用Google Hangouts的免费版本，那么您将遇到问题。远程工作需要良好的基础架构。此外，您还需要更多的责任感和纪律。是的您甚至可以穿着睡衣工作，但是您应该工作，而且连续几天都不能在Xbox上玩-承认是可耻的，但这是我个人的经验。此外，走廊上的对话和现场交流是所有工作不可或缺的一部分-人们是如此安排。我必须承认，这里的远程工作有很大的缺陷。让您的视频群聊在Slack中进行，并进行实时视频聊天-并非如此。这个问题是可以解决的，但这需要时间和纪律，对于每个新的团队成员来说，这个问题都需要再次解决。正如我所说，在过去的20年中，我的工作距离是办公室的两倍，这是一个很好的工具。但是有必要对这种工作的优缺点有一个清晰的认识。此外，组织需要每年至少召集整个团队四次进行实时交流，以建立那些无法通过Internet建立的连接。每个人都需要坐在一个房间里，工作，争论，玩乐。所有这些对于创建一个协调良好的团队都非常重要。如果您认为远程工作只是降低成本的一种方式，您将感到失望。我再次得到了一个相当长的答案，但是该怎么办，您问了一些有趣的问题。— «Technical debt: payment plan». « » , « » , . , , , , ?-这是一个非常重要的问题。我认为任何长时间从事IT工作的人都必须遇到技术债务问题。在这里，我要感谢Trish Khoo，在Twitter上可以将其视为猪鱼。她是一位出色的测试员，我认识她很多年了。实际上，她写了“技术债务：付款计划”一文。当我阅读这篇文章时，我也想写这篇文章，因为五年来，我在各种会议上发表了演讲，并在会议上大体表达了类似的想法。因此，技术债务问题一直存在于我们的行业中，我们所有人都必须考虑如何避免技术债务，以及在技术债务出现时如何应对。我认为，您提出的将其视为金融债务的建议具有非常重要的意义。如果进行适当的研究，您会发现该技术债务确实导致财务成本。由于技术债务，您的项目需要X的时间，更多的人在Y上工作，而且所有人都需要支付一定的薪水。也就是说，尽管这些成本可能不那么容易评估，但它们是可以衡量的。或者假设由于技术债务问题，您必须在一个半月内修复30个错误。这再次导致项目价格（以美元计）上涨。而且，我们不仅在谈论以美元计的成本，还在谈论机会成本：这几个月半以来，您还可以做其他事情。许多年前，我在一家公司工作，每10天开发新功能需要3天的时间来解决质量和技术债务问题。对于这三天中的每一天，都有一天进行了更正。有些问题已多次重开。都花钱了。我离开了这个组织，所以在我在那里工作的时间里，我无法改变那里盛行的文化，并迫使他们承认这种情况是不可接受的。最后一根稻草是我向导演解释的失败的尝试，即我在那里工作的三年中，由于技术债务问题得到纠正，我们损失了一年。我无法向他传达我的想法；他将对话转移到另一个话题。我相信从事IT工作的人人们必须学会更好地解释技术债务的重要性及其带来的成本。我们不能只是坐在我们的角落，工作而不与任何人交流。我们需要学习说一种企业会理解的语言。并且企业了解美元和损失时间的语言。企业开始考虑销售或许可更新下降的时间，这是由于质量下降而造成的，而质量下降又是由技术债务引起的。技术债务的原因是过大的压力，试图节省重要的事情以及企业不了解其决策意义的事实。尽管当我们没有适当的技能时，我们的错误也会发生，但是当我们没有遵循公认的建议时，以及当我们不知道如何与企业进行对话时，也会发生这种情况。我认为，学会根据金融债务来制定技术债务是我们所有人都需要努力的非常重要的技能。我再说一遍，你问了一个很好的问题。— , , , . , , , .-这个问题有两个方面。商业上尚不清楚为什么要进行重构以及为什么要编写自动化测试。他们只看到人们花在编写测试上的时间是编写代码的两倍，这对他们来说似乎很奇怪。这是一个教育问题，因此有必要说明发展是一个已经建立了数十年的过程。有统计数据和研究表明，由于延迟和更正，试图在测试上省钱直接导致成本（美元）。商家对此不了解。就我们而言，我们还没有学会如何正确地与业务沟通，也没有学会说服。另外，我们经常缺乏毅力来解释一些事情没有被讨论，它们不能被忽略或推迟。历史上已经发展了安全和生产性的惯例，如果您（经理）跟随他们，最终您会感到高兴的，因为这会产生很多成本。这是一个艰难的对话，我们IT人员不知道如何进行对话。-因此，经理或团队负责人具有开发经验总是很好的-然后他们了解这些知识。如果管理人员具有技术专长，则易于创建一个好的项目。-在上面我谈到的《财富》 10强公司中，我们确实遇到了这样的问题。下层和中层管理者不理解为什么测试如此重要。我们设法重新启动了项目，并就何时考虑项目准备就绪的问题达成了共识，也就是说，我们已经实现了让管理人员参与对话的目标。我们确定，当有文档时，当支持人员对新功能有充分的了解，产品（即所有者）已经检查了要求的满足时，就可以认为用户故事已准备就绪。此外，我们获得了管理层的同意，可以实施他不了解的特定技术措施。我们同意，代码应符合静态分析的标准参数（例如，使用Sonar Cube进行分析），也就是说，代码不应太复杂，方法中不应包含太多行。经理们意识到，为了保持健康的代码基础，应遵循有关代码外观的行业标准。另外，在我们对完成的项目的定义中，有“必要的测试”一词，也就是说，我们没有指出需要执行的一定数量的测试，也没有指出需要实现的自动测试的一定代码覆盖率。因此，与每个模块相关的项目团队负责人，开发人员和测试人员可以确定哪个测试就足够了。每当对话期间发生这种情况时，很长一段时间，管理人员都无法理解这又符合行业公认的惯例。-这是我们问题的结尾。非常感谢您提供详细的答案。-谢谢，我喜欢你的问题。我认为这很明显：您设法提出很多与我个人非常接近的话题。