下一代测试人：T人 or I人！
文摘
2024-09-21 09:35
四川
软件在当今社会变得极其重要。尽管有许多质量倡议，IT行业仍然远远不能承诺零缺陷的软件。近年来，大多数世界各地的软件开发方式发生了巨大变化。除了软件开发的快速和动态变化外，创新、新技术的增长以及IT在大多数行业的扩展也在加剧。采取了敏捷和/DevOps的工作方式已经有很大的转变。敏捷的优点包括更好地管理变更优先级、提高项目状态的可见性、增加团队生产力和更好的交付可预测性。然而，许多组织都在努力应对敏捷和扩展敏捷，并且很明显，向敏捷的转变并不自动也保证提高软件质量。尽管在敏捷组织中与传统组织相比有所不同，但测试仍然是软件开发的一个重要部分。这不仅是由于软件在当今社会的重要性，而且还因为IT项目面临的许多（技术）挑战，例如，日益增加的复杂性、新技术、各种设备和操作系统以及安全漏洞。这对软件测试人员意味着什么，以及对测试人员所期望的知识和技能栈意味着什么？本章将详细探讨测试人员为在快速变化的IT世界中增加价值和生存所需的知识和技能栈。测试人员将面临两个选择：1. 测试的未来
在探讨测试人员所需的知识和技能栈的答案和解决方案之前，让我们先简要地看一下我们当前所处的位置以及测试职业的未来前景。大多数人认为敏捷是全球通用的工作方式。然而，也有一些国家实际采用敏捷的人数或组织仍是少数。也许这些国家只是“落后”了，几年后他们也会采用敏捷，但也有可能是敏捷并不总是完全适合每种文化。在国际测试会议上有一些主题演讲声称测试人员很快就会消失。根据他们的说法，在不久的将来，将不再有专职测试人员。有趣的是，来自调查报告（例如《世界质量报告》）的数据却显示了完全相反的情况。此外，像 ISTQB 和 TMMi 这样的测试认证方案仍在强劲增长和被采用。这些相互矛盾的言论、信息和事实令人惊讶。哪些是真实的呢？软件测试职业的未来又是什么呢？在大多数西方社会，敏捷似乎很合适。一般来说，有很多人倾向于善于沟通、思想开明、乐于团队合作且不太注重形式。请注意，并非世界上所有地区和文化都是如此。即使在欧洲内部也存在巨大差异，有时甚至在邻国之间也是如此。多年来，敏捷已经显示出许多优势，但在传统环境中交付高质量的产品也并非不可能。有了所有这些相反和不同的趋势，很难准确预测测试职业的未来。然而，可以肯定地说，就目前软件质量交付的实践状态及其重要性而言，作为一门学科和一种职业的测试需求将继续存在。展望今天和明天的测试，测试人员有两个主要选择的明确趋势：• 成为所谓的 T 型人才（测试人员），通过改变态度并拓宽知识和技能。在不久的将来，知识和技能对许多测试人员来说将是一个挑战。仅仅了解测试并拥有 ISTQB 证书已经不够了。测试人员通常不再在他们安全的独立测试团队环境中工作。他们将与业务代表和开发人员更紧密地合作，在需要时互相帮助，并作为一个团队努力构建高质量的产品。除了强大的软技能外，还期望测试人员具备业务领域、需求工程、脚本编写等方面的知识。成为一个“测试多面手”，一个既能测试，又能组织测试并在测试中支持他人的人，一个能做的不仅仅是测试的测试人员。• 成为测试专家。随着产品变得越来越复杂，并在开放的环境中集成，许多所谓的非功能性测试问题变得极具挑战性。同时，用户不想在质量上妥协。为了能够仍然测试非功能性特征，如安全性、互操作性、性能和可靠性，或者其他复杂方面，例如系统的系统，将需要高度专业化的测试人员。与现在相比，这些专家将更是全职的测试专业人员，仅在一个特定（非功能性）测试领域拥有深入的知识和技能。T 型人才的概念在敏捷中很受欢迎，它指的是敏捷团队（例如 Scrum 团队）中需要具备跨技能的开发人员、业务分析师和测试人员。实际上，很多人谈论成为 T 型测试人员，但只有少数人真正是。让我们尝试定义成为真正的 T 型测试人员所需的知识和技能栈，但在我们这样做之前，让我们更详细地了解 T 型人才的概念实际上意味着什么和代表什么。2. T 型
T 型技能或 T 型人才的概念是一个最初在招聘中使用的隐喻，用于描述劳动力中人员的能力。T 中的竖条代表在单个领域中相关技能和专业知识的深度，而横条是与其他领域的专家跨学科协作的能力，以及在自己专业领域之外的领域应用知识的能力（见图 1）。更详细地说，横条由两件事组成。第一，同理心。这很重要，因为它允许人们从另一个角度看待问题——站在别人的立场上。第二，他们倾向于对其他人的学科充满热情，以至于他们敢于实践这些学科。T 型人才在他们的技能方面既有深度又有广度。为了更好地理解 T 型人才是什么，也许先理解其相反的概念，即所谓的 I 型人才是什么会更容易。I 型人才是一个功能专家——他们的功能专业知识由I 型中的竖线代表了功能专家的专业知识。成为 I 型人才（功能专家）本身并没有错。然而，让我们想象一些功能专家试图共同开发一个新的移动应用程序。一个应用程序开发人员、一个搜索引擎优化专家、一个分析专家、一个内容开发人员和一个艺术总监召开启动会议，以确定新移动应用程序的策略。搜索引擎优化专家坚持认为应该围绕关键词地图构建应用程序，以确保网站结构反映对关键词的强调。应用程序开发人员坚持认为移动应用程序应尽可能易于编码。分析专家表示，新设计必须基于应用程序分析所显示的当前应用程序的使用情况。内容开发人员坚持认为关键在于开发有趣、引人入胜且易于导航的内容。最后，艺术总监坚持认为应用程序的构图和品牌美感是首要目标。这些 I 型人才中哪一个是正确的呢？我们如何管理所有这些不同的意见并做出决策呢？无论 I 型功能专家在各自的职能方面多么出色，他们所缺乏的不仅是对同事专业领域的欣赏，还缺乏在各自功能领域的交叉点上实际找到解决方案的培训。现在让我们将 I 型人才与 T 型人才进行比较。T 型人才通常具有多职能意识、善于协作，并寻求更多地了解他们的职能如何影响他人和最终产品。T 型人才更加灵活，更能够轻松跟上新趋势，但当然在每个相邻学科中的专业程度不如在他们的主要技能中那么高。与 I 型人才相反，T 型专家倾向于把握总体情况，而不是沉浸在细节中，除非确实有必要。除了 I 型和 T 型概念之外，最近还出现了一些描述性的变体，其中最常见的是（见图 2）：• π 型——关键技能的两条“腿”与一般知识的“横线”相连。虽然超越 T 型的概念，如 π 型甚至 M 型对于某些学科来说肯定是一个有趣的概念，但对于测试人员来说可能不是正确的方向。正如我们多年来所了解到的，一定程度的独立性通常使测试人员在发现缺陷方面更加有效，因为作者和测试人员的认知偏差（关键距离）不同。作为 π 型甚至 M 型测试人员拥有多个专业领域，通常会使保持独立视角变得更加困难。在这些情况下，作为专家，你会参与到你作为测试人员同时应该评估的任务中。在敏捷环境中，当测试人员嵌入团队中时，保持独立性已经常常更加困难。同时，作为一个拥有（并执行）测试之外的另一个专业领域的 π 型人才，可能会使所需的独立水平几乎完全消失。T 型人才及其所在的团队能够取得比仅由 I 型人才组成的团队好得多的结果。但是 T 型人才的发展是一项严肃的、长期的任务，而且常常被大大低估。它需要有正确态度和自我决定的人开始，然后需要努力继续为他们提供所需的培训和资源，以及那种允许 T 型人才和团队发挥最佳水平的安全协作环境。为了推动软件测试职业的发展，最有价值的知识和技能是什么呢？如前所述，发展测试职业的一种方法是通过在一个特定的非功能性领域或细分领域深入钻研来实现专业化。这类专家在理论上被视为 I 型人才，这意味着他们的技能被认为非常狭窄但极其深入。然而，在快节奏的世界中，这种策略有明显的风险，例如如果专业领域过时、不受欢迎，或者如我们稍后将看到的，当一个专业领域转变为所有人都熟悉的领域时。虽然在过去几十年里对 I 型测试人员有需求，但现在 T 型人才的机会越来越多，因为那些在一个学科有深厚技能并且还具备跨学科的一般知识的人将更容易在不断变化的环境中工作。在敏捷世界中，T 型测试人员是团队成员，其关键专业知识是测试，但也可以在其他活动中提供支持，例如编程或业务分析（需求工程）领域的活动。因此，对于 T 型人才，我们应该寻找能够潜在提升测试人员形象的技能。对于专业的软件测试人员来说，好的选择可能是：• 其他开发专业领域：业务分析、编程、技术写作等。• 软技能：对个人效率、领导力以及与他人的协作有积极影响。讨论 T 型测试人员的技能组合时，我们也应该意识到技能组合中“横向”和“纵向”方面的比例。根据环境的不同，对每个技能类别的需求也会有所不同。那些在某个领域拥有非常深入和狭窄专业知识的人可能会技能过剩，因为雇主通常不会为他们不需要的技能付费。那些拥有更广泛技能的人在某些时候可能会感到在自己的关键学科中缺乏专业知识，如果需要，他们将需要在短期内赶上。以下将详细阐述为 T 型测试人员确定的四个知识和技能选项，并举例说明。2.1 深化：测试知识和技能
当今的测试人员需要有一个装满各种测试方法和技术的工具箱。在团队中工作时，根据具体情况和职责，应从工具箱中选择最合适的方法和技术。试图为测试人员定义工具箱，也就是所需的测试知识和技能，可以将 ISTQB 产品组合用作参考模型。尽管在一些测试社区中对 ISTQB 有很多批评，但从内容角度来看，毫无疑问，在测试的许多领域都有很多有趣的知识和材料，并且在各种教学大纲中都有记录。如今的 ISTQB 远不止基本的 ISTQB 基础级教学大纲。如果我们以 ISTQB 产品组合为起点（有关产品组合的最新版本，请访问 www.istqb.org），就会有很多有趣的主题和教学大纲可供参考。试图定义所需的测试知识和技能时，奇怪的是 ISTQB 并不认为敏捷测试是核心知识和技能栈的一部分。在产品组合中，它被定义为一个单独的分支。同样有趣的是，测试自动化和移动应用测试在测试中被视为专业领域。如今，这些几乎是对测试人员的标准要求。ISTQB 最初将这些定义为专业领域这一事实或许表明市场变化之快。今天被定义为专业领域的内容很可能在明天成为对知识和技能的常见要求。图 3 绝不是要完整呈现一个调查结果。它旨在从高层次上展示当今以及肯定在未来对测试人员在测试知识和技能方面的期望。参加了 ISTQB 基础课程（并通过了考试），然后就声称自己是为未来做好准备的专业测试人员，这几乎就像一个笑话。为期三天的 ISTQB 基础课程基于一个有充分依据的教学大纲，但它只教授测试的基础知识和原则，无法完成实际工作。人们还需要接受敏捷测试方面的培训，我认为这对任何测试人员来说都是核心内容，而不是可选的。真正重要的是参加更高级的实践课程或研讨会，在其中你将学习如何在各种情境中实际应用测试实践。这些高级课程应该包括测试自动化和移动应用测试等领域，并且当然应该从敏捷的角度进行教学。遵循 T 型概念并在测试方面拥有深厚的知识，我们不期望测试人员在测试经理、测试分析师或技术测试分析师等后续领域中进行选择。我们期望测试人员涵盖所有这三个领域并成为真正的专业人士。例如，专门的测试经理或测试负责人越来越少。如今，许多测试人员都嵌入在敏捷团队中，因此他们执行测试任务，但也指导和支持进行基于功能用户故事测试的业务分析师和进行自动化单元测试的开发人员。在敏捷团队中担任测试人员还意味着你参与了原本属于测试经理专属领域的任务，例如产品风险会议、评估、回顾、报告等。请注意，还有许多其他获取相同测试知识和技能的方法；ISTQB 只是一个选择，在此用作示例。在测试会议上经常有很棒的教程，讨论有趣的主题和领域。市场上也有许多非常实用的课程，例如关于测试自动化的课程。当然，也有替代正式培训的方法，例如指导、在职学习等。未来很可能会有专业的测试人员，但更重要的是，测试作为一项活动将仍然极其重要和具有挑战性。不仅测试人员执行测试活动，其他团队成员，例如开发人员和业务分析师，也将执行测试活动，尤其是作为敏捷转型的结果。遵循 T 型概念，测试人员应在测试方面拥有深厚的知识和技能，但对于其他团队成员，期望他们将测试知识和技能作为其横向技能条的一部分来获取（见图 4）。我们不能只是指示其他人参与测试，他们需要在测试方面接受培训和指导，以便能够执行这项任务。记住格伦福德·迈尔斯在他的《软件测试的艺术》一书中所说的话：“测试是一项极其复杂且在智力上具有挑战性的任务”。2.2 拓宽：IT 知识和技能
在跨职能团队中与开发人员和业务分析师紧密合作意味着测试人员至少需要理解和欣赏其他团队成员正在做的事情，并且最好能够在他们的任务中提供支持。对于 T 型测试人员，通常期望他们能够在单元测试方面支持软件开发人员，并在定义用户故事的验收标准时支持业务分析师。需要了解正在使用的生命周期模型以及开发发生的技术环境。测试人员的 IT 知识和技能应涵盖广泛且多样的知识技能范围，以下列出并描述了一些基本示例。需求工程/业务分析
测试人员当然是主要的利益相关者之一。测试计划、产品风险分析、测试用例都基于需求。测试人员参与需求评审，并需要了解要求的合理质量水平是多少。在敏捷团队中，测试人员经常支持需求（用户故事）及其验收标准的识别和规范。编程
并不是说测试人员需要像开发人员一样工作，但了解应用程序的内部结构很重要，这样可以轻松理解其功能和风险区域，并相应地创建测试。编程知识有助于识别代码中可能的错误，并在静态分析和单元测试方面与开发人员密切合作，可能使用测试驱动开发。建议至少学习两种编程语言，例如 Python、Java 或 C++。当然，拥有编程技能也极大地支持执行测试自动化任务的能力。随着应用程序的复杂性和集成度不断增加，仅依靠手动测试无法完成工作。Web 和移动技术
如今，大多数测试人员还必须熟悉 Web 和移动技术，以便他们能够理解应用程序、其构建和可扩展性，并为其测试应用合适的行动方案。测试人员密切关注 Web 和移动技术的进步非常重要，因为这可以指导他们理解编码架构和技术挑战，以提供有效的测试解决方案。软件开发生命周期
测试人员需要学习和理解软件生命周期，因为这将帮助他们理解开发任务并相应地规划测试周期。对软件生命周期有深入的了解也有助于预测开发过程中的挑战，从而可以提前采取正确的措施。随着敏捷和 DevOps 方法的流行，测试人员当然也需要学习和理解这些，尤其是这对测试执行方式的影响。学习项目管理技能将支持测试人员成为更好的测试经理。项目管理技能还使测试人员对其工作向相关利益相关者负责并作出回应，并承担特定测试活动的责任和管理。这样，项目管理技能有助于提供高质量的结果，改进整个测试过程。配置管理
配置管理的目的是建立和维护组件或系统、测试件及其相互关系的完整性。对于测试人员来说，这是确保质量的重要过程，因此对配置管理有一定的了解是至关重要的。此外，测试件也需要通过这个过程进行管理。所有的测试件项目都应该有唯一的标识、版本控制，并跟踪其变化，相互关联，并与需求版本相关联，以便保持可追溯性。2.3 拓宽：领域知识
在这种情况下，领域知识被定义为关于目标系统运行环境的知识。对于测试人员来说，理解领域很重要，以便能够与业务利益相关者（产品所有者）进行沟通，并且在执行测试活动时做出正确的决策。记住，详尽的测试是不可能的，测试人员一直在进行权衡决策，并且最好是正确的决策！哪些功能最重要需要测试，哪些配置最常出现等等？因此，对于测试人员来说，拥有领域知识以及其他技能对行业来说是一个很大的优势。在成为 T 型测试人员的背景下，在测试之外也有好处。具有领域知识的测试人员可能可以部分减轻业务分析师的负担，或者通过带来必要的领域视角来协助其他团队成员。接下来讨论测试人员从拥有领域知识中受益的一些例子。除非你了解领域，否则你无法识别和分析产品风险，并编写和执行测试用例以有效地模拟最终用户。这不仅仅是在特定活动中使用，而是在所有测试活动中都需要。理解影响
当出现问题时，了解系统功能目的的测试人员将能够更好地分析问题的影响。例如，当在在线披萨订单应用程序的支付过程中发现缺陷时，具有领域知识的测试人员将清楚地了解成功交易所需的受影响的流程步骤。这将帮助测试人员在缺陷修复后进行更好的确认和回归测试。更重要的缺陷
具有领域知识的测试人员非常受欢迎，因为他们能够超越仅仅发现缺陷来理解应用程序，例如在探索性测试中。他们通常会发现更重要的缺陷。确定缺陷优先级
由于测试人员了解领域，测试人员将清楚地知道如何最好地确定未修复缺陷集的优先级。更有效的评审
具有领域知识的测试人员在项目或迭代开始时可以更高效。对业务流程和业务规则的功能流有良好的了解将有助于更好地理解需求，因此能够更有效地进行评审。在一个以 IT 为主导的世界中，具有领域知识的测试人员的价值是不可思议的，因为它无疑是测试人员的关键成功因素。在测试任何应用程序时，能够从最终用户的角度思考很重要，因为他们是将使用该产品的人。领域知识通常必须从最终用户（作为领域专家）那里学习，并且可能包括用户档案、工作流、业务流程、业务政策和配置等。在不详细讨论如何获取业务和领域知识的情况下，不仅仅是参加培训，还可以考虑当学徒、观察用户/客户实际使用应用程序、访问在线论坛并成为社区的一部分。注意，在敏捷社区中似乎有一种倾向于更喜欢技术测试人员，但正如我们在这一段中所了解到的，拥有具有领域知识甚至领域背景的测试人员有很大的需求和好处，例如曾经是最终用户现在成为测试人员！当然，在这种情况下永远没有正确答案，但在为团队分配测试人员并为 T 型测试人员定义所需的知识和技能栈时，这是需要考虑和平衡的事情。2.4 拓宽：软技能
任何软件测试人员还应该具备所谓的软技能（也称为人际交往技能）。软技能很重要，因为它们用于处理工作。测试人员对软件可能在哪里以及如何失败以及如何发现缺陷有一种本能和理解。测试人员还应该具备以一种对项目至关重要的方式进行影响和沟通的软技能。测试需要一个充满软技能的工具箱，包括沟通、时间管理、分析技能、学习热情和批判性思维，以及相对标准的人际交往技能，如阅读、报告和演示技能。其中一些技能可以让测试人员更好地发现缺陷，但大多数技能与更好地传达通常很困难的信息有关。拥有这些软技能就像是成为敏捷团队中思想开放的 T 型测试人员的正确态度的先决条件，例如对其他学科有同理心、知识共享和成为团队成员。作为 T 型测试人员和团队的一部分，测试人员拥有的软技能也可以用于在其他团队成员的任务中提供支持。以下简要描述了测试人员为了在其领域中表现出色而应该具备的一些重要软技能。沟通
由于测试人员必须与许多不同的团队成员打交道，因此与他们建立适当的沟通渠道非常重要。无论是报告缺陷、对模糊需求进行解释或澄清，测试人员都必须与相应的业务分析师、开发人员，有时还有最终用户进行沟通。当你有良好的沟通技巧时，在与不同的团队成员交谈时可以消除歧义和误解。此外，大多数由于沟通差距而出现的问题都可以得到解决。例如，当你发现一个关键缺陷时，以礼貌的方式解释它非常重要，这样开发人员不会觉得你在指责他是根本原因。时间管理
时间管理是测试人员最重要的技能，即使在敏捷中，迭代的最后几天通常也充满了“紧张”的最后一分钟测试。当你知道如何正确使用时间并根据截止日期对任务进行优先级排序时，你将更容易在截止日期前完成任务并遇到更少的工作压力。分析和注重细节
这是可以帮助你发现更多和最重要缺陷的技能之一。当你理解并能够分析需求时，不仅可以发现和修复需求中的差距，而且还可以了解产品的整个功能、流程和预期结果。有时可能会错过细节，这些细节后来会导致一个更难返工的重大问题。为了减轻这种情况，拥有“注重细节的态度”也非常重要。学习热情
如果你有学习热情，并且愿意承担舒适区之外的活动来帮助团队交付一个好的产品，那么作为测试人员你将有一个光明的未来。对于软件测试人员来说，了解最新的工具和技术并不断学习是至关重要的。当你了解最新的工具和技术时，你会做出更好的决策。批判性思维
批判性思维是专门寻找问题和错误的一种思维方式。它是通过仔细分析某物以确定其有效性或准确性的推理能力。批判性思维是成为一个积极的学习者，而不是被动地接受信息。在测试的背景下，这可能是最重要的思维类型。作为测试人员，我们应该始终质疑想法和假设，而不是仅仅接受其表面价值。知识共享
测试人员应该有一种通过分享知识来帮助和指导敏捷团队成员的态度。这不仅可以避免差距和混乱，让他们能够协助并自己进行更好的测试，还可以激励其他团队成员分享他们的专业知识和知识。团队成员
作为敏捷团队的一部分，你总是需要团队的努力来实现某些目标。测试人员激励团队进行更好的测试和达到良好的产品质量水平。为了实现高质量的软件，软件测试人员成为一个好的团队成员是很重要的。3. I型
正如在介绍段落中已经提到的，成为 T 型测试人员的职业道路有一个替代方案：成为测试专家。专家被定义为主要专注于特定主题或活动的人；在特定且受限领域中高度熟练的人。按照“形状”人才的概念，测试专家是 I 型人才（见图 5）。在一个测试领域具有深厚（垂直）专业知识，而在其他测试领域以及测试之外的领域知识和技能较少的测试人员。他们在那个测试领域的专业知识比 T 型测试人员在同一测试领域的专业知识要深得多。随着产品变得越来越复杂，并在几乎开放的环境中集成，许多所谓的非功能性测试问题变得极具挑战性。你不能只是顺便做这些，这需要很多专业知识和技能、培训和奉献精神。对一些测试人员来说，这可能不是他们擅长的，或者甚至在技术上太难掌握。因此，为了仍然能够测试 IT 行业的非功能性特征，如安全性、互操作性、性能和可靠性，或者其他复杂方面，如系统之系统，将需要高度专业化的测试人员。这些专家通常是仅在一个特定（非功能性）测试领域拥有深入知识和技能的全职测试专业人员。从客户的角度来看，当客户来找我们解决问题时，客户有时可能会带着一个只需要一个专家来解决的问题上门。这不需要基于团队的解决方案。在这些类型的问题或疑问中，I 型专家显然有很大的附加值。那么典型的测试专家领域是什么呢？再次，让我们以 ISTQB 产品组合作为参考框架，确定一些被认为是我们可以从拥有测试专家中受益的测试主题。ISTQB 明确地指出了非功能性方面的方向（见图 6），例如安全测试专家、可用性测试专家或性能测试专家。在上述定义的背景下，这些是有价值的测试专家。ISTQB 还提到了汽车软件测试人员、博彩行业测试人员和基于模型的测试人员等。就个人而言，我不确定这些是包含并需要足够专业知识和技能以能够作为 I 型测试人员增加价值并生存下来的测试专家领域。可能这些领域更特定于某个领域，并且属于该领域 T 型测试人员的知识和技能栈。最后，有趣的是 ISTQB 也将测试自动化和移动应用测试视为测试中的专业领域。如今，这些几乎是对测试人员的标准要求。ISTQB 最初将这些定义为专业领域这一事实或许表明市场变化之快。今天被定义为专业领域的内容很可能在明天成为对知识和技能的常见要求。这也指出了成为 I 型测试专家的危险。如今，对安全测试专家有巨大的需求，对性能测试专家的需求可能稍低。然而，这可能会迅速改变，或者专业领域逐渐转变为 T 型测试人员所需的通用知识和技能领域。可用性测试可能处于这种转变的某个阶段。总之，测试专家是需要的并且有很大的附加值。这肯定是成为 T 型测试人员的一种替代方案。小心选择哪种专业领域，并密切关注当今和不久的将来市场上正在发生的事情。有时，当当前的测试专业领域过时了，可以跳到一个新的测试专业领域。同时，拥有一些通常属于 T 型测试人员的知识和技能作为后备方案也没有坏处。当工作不太独立并且是团队的一部分时，后者也将是有益的。这也将再次有助于欣赏他人正在做的事情，并从不同的角度看待事物。4. 结论
就 IT 行业目前的实践状态而言，我们离实现零缺陷还很远（如果将来有可能的话）。软件测试现在是并且将继续是软件开发中不可或缺的一部分。讨论了（不久的将来）测试专业人员所需的知识和技能。详细介绍并解释了 T 型测试人员。实际上，很多人谈论成为 T 型测试人员，但我相信实际上我们离那还很远。也简要介绍了对 I 型测试人员的需求。基本上有两个选择：• 拓宽你的知识和技能，成为真正的测试专业人员（T 型）。• 在特定的测试领域深化你的知识和技能，成为测试专家（I 型）。对于推动职业发展的测试人员来说，确定个人的成长和发展方向非常重要。不要忘记 T 型概念，根据自己的优势和热情做出选择，并考虑你的工作环境（生命周期、领域）、行业趋势以及当前（和未来）就业市场的需求。此外，定期审查你的职业规划将帮助你保持领先地位，并从你所做的工作中获得最大价值。往期系列文章
阿里微服务质量保障系列：异步通信模式以及测试分析
阿里微服务质量保障系列：微服务知多少
阿里微服务质量保障系列：研发流程知多少
阿里微服务质量保障系列：研发环境知多少
阿里微服务质量保障系列：阿里变更三板斧
阿里微服务质量保障系列：故障演练
阿里微服务质量保障系列：研发模式&发布策略
阿里微服务质量保障系列：性能监控
阿里微服务质量保障系列：性能监控最佳实践
阿里微服务质量保障系列：基于全链路的测试分析实践
阿里微服务质量保障系列: 服务虚拟化技术
