QA的5个SMART目标
QA测试人员可以通过明智的目标赢得尊重，并在同行中获得影响力。拥有你所开发的软件的所有权，尊敬优秀的产品经理，并实现以下五个目标。
SMART原则（S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound）是为了利于员工更加明确高效地工作，更是为了管理者将来对员工实施绩效考核提供了考核目标和考核标准，使考核更加科学化、规范化，更能保证考核的公正、公开与公平。
熟练的QA表现出永不枯竭的好奇心，推动他们的工作。软件测试是少数几个让人们拿薪水的职业之一，他们发现某些东西应该如何工作，然后立即尝试破坏它——并在他们这样做的时候得到赞扬。
要想在这个有点古怪的职业中取得成功，测试人员必须认真地设定目标。培养理解事物如何运作的热情;对于QA分析师来说，从职业生涯的一开始，这就是一个SMART。
每一个QA分析师都应该花些时间来学习更多的东西是如何以及为什么工作的，特别是那些与计算机和软件无关的事情。有没有想过收银机是如何记录当天的销售情况的?电话是如何通过一个称为交换机的接线板矩阵连接的?这些都是测试人员需要思考和研究的重大问题。有了这样的背景知识，我们就了解计算机和指导它们的软件如何在跟踪销售情况的基础上得到改进，以及如何在没有人为干预的情况下建立通信电路就会很清晰。
好奇心是一回事，但职业道路上的进步是另一回事。那么，QA分析师有哪些具体的，可测量的，可实现的，切合实际的（或相关的），有时限的（SMART）目标？测试人员可以突出实现以下五个目标。
1.了解业务流程映射 这个SMART目标说起来容易做起来难，但是值得付出努力。
对于初学者，与测试负责人或QA详细的沟通了解业务流程，以度过难关。当测试人员与帮助工作流程从输入到输出的业务用户共度时光，双方都可以从经验中学习。了解高级管理层做出良好业务决策所需的数据，并了解何时可以安全地将工作从一个团队成员转移到另一个团队成员。
不要只是观察。询问许多问题，关于什么构成单个工作单元以及业务用户希望如何改善它们。
使用Visio或Lucidchart之类的流程图工具来创建图表，以突出显示在哪里制定关键业务决策。详细说明这些决策，这些术语将对以后的开发或测试团队有所帮助，例如，使手动任务自动化或改进现有算法。
这项工作类似于业务分析师可能做的事情，但是对于qa来说，这也是一个SMART的目标。测试人员的目标是在组织中如何完成工作方面成为尽可能多的业务专家。当需要创建测试方案时，他们将能够确定软件关键路径中的内容与边缘情况。
在软件的终端用户辛苦工作一天的时候，不可能跟踪他们，但是要学习可能存在的任何标准操作程序。如果没有关于这些过程的文档存在，那么考虑到QA受众，起草一些文档。问为什么要以某种方式做某事，而不是怎么做的。
很难衡量个人目标。这一切都是关于获得流程在业务方面如何工作的全面知识。理解这个更大的图景将产生更好的测试场景，而不是简单地改进测试执行步骤。度量此目标的一种方法是查看测试人员是否可以在紧急情况下代替业务方面的人员，或者在代码部署验证期间代替业务方面的人员。但是试图回顾或验证这种度量可能会导致收益递减。
2.了解编程逻辑的基础 不要再去学习多门编程语言，只需专注一门即可。毕竟，QA分析师并不会编写业务代码。然而，编程逻辑很重要。所有编程语言都有几个共同的基本逻辑结构: if-then-else case structure do while do until 软件测试人员需要对这些编程语言的基本知识，才能获得持续的职业发展。成功地执行手动测试和自动化脚本是有帮助的，但是测试活动只能到此为止。更重要的是了解数据进入某个编程结构的条件，以及该数据退出时必须发生什么。
让我们从if-then-else逻辑开始。在此结构中，if表示条件是否存在。如果存在，则执行then函数。否则，执行else函数(或者什么都不做)。当条件为真或假时，if-then-else结构工作得很好。当一个条件落入一系列可能性中的一个槽时，case结构可能是合适的。
case结构对if-then-else进行了扩展，提供了在存在特定条件时执行的多个功能。例如，if-then-else结构可以检查一个数字是否在2-10之间，如果在2-10之间，则将该数字乘以5。如果数字不在这个范围内，它就会进入else条件，根本就不会相乘。大小写结构指定当一个数字属于多个范围中的一个时应该做什么。在本例中，当一个数在2-10之间时，它属于情形a，被乘5。如果这个数在11-20之间，它属于情形B，被乘以4。如果一个数大于或等于21，它属于情形C，被乘3。案例结构可能会变得复杂，并涉及到分支到代码的其他部分。
Dowhile和dountil基本上是循环。使用dowhile，只要条件仍然存在，就执行函数。dountil逻辑结构执行一个功能，直到条件不再存在。
虽然这本书本身有点过时，但Marilyn Bohl和Maria Rynn在1978年的《结构化设计工具:编程逻辑导论》帮助传达了所有编程语言中普遍存在的规则。以一种与语言无关的方式掌握编程逻辑有助于理解测试独立代码片段的入口和出口标准。该领域的知识将业务流程与最合适的编程结构结合起来。业务流程中的yes/no决策点通常映射到if-then-else结构，而需要回答三个或更多问题中的一个的决策点可能需要案例结构。
通过仔细考虑业务需求的代码来衡量这些概念的知识。 比以前更容易理解吗？ 为了实现此目标并实现流程改进，质量检查分析师可能会在测试驱动的开发（TDD）环境中与开发人员合作。 在TDD中，质量保证和开发团队合作对离散代码段进行单元测试。 编写代码并使代码无法通过初始测试，然后对其进行重构以使其通过。
3.复习一下QA的历史
设定目标时，不要重复过去的错误。了解之前出现的流程类型——失败的或成功的——以及这些测试流程如何为现有的流程奠定基础。
衡量对过去的理解的方法是看它是否有助于实现更好的敏捷性能。虽然传统的软件开发生命周期(SDLC)和瀑布式方法最终导致产品和文档膨胀，但是关于意图和方法的经验在今天仍然有用。从过去借鉴原则和概念，并将它们塑造成可用的流程。
请参阅Frank P. Ginac的《面向客户的软件质量保证》一书，该书最初出版于1998年。这个闪电般的解读描绘了软件工程学会的能力成熟度模型(CMM)是如何以及为什么在20世纪90年代后期在许多组织中流行起来的。认识到一些CMM概念仍然是相关的，这可能会让人大开眼界。
适用于质量检查分析师的OKR示例 为QA分析师提供的OKR示例
虽然为QA分析师的职业发展确定明智的目标是有帮助的，但不要忽视目标和关键结果(OKRs)。OKRs是一种协作方式，用来定义个人或项目目标，设定有意义的目标，并跟踪关键结果以实现其结果。
首先，QA分析师确定一个测试目标，然后定义逻辑关键结果，使他们能够满足这个目标。就像SMART goals一样，跟踪你的okr来看看最好的结果。
下面是一些针对QA工程师的OKR例子。
目标:为新产品的发布增加测试覆盖率。
关键结果1:与开发人员一起自动化75%的测试用例。
关键结果2:将代码覆盖率提高到90%。
关键结果3:使用设备场同时在多个终端用户设备上进行测试。
目的:推进QA阶段之外的测试。
关键结果1:为早期重构实现测试驱动开发。
关键结果2:增强自动化回归测试。
关键结果3:在生产环境中进行测试，在用户看到错误之前，在真实的条件下捕获它们。
编者注:此侧栏由站点编辑David Carty编写，并得到贡献者Jim Brown的批准。
4.成为解决冲突的大师
对于QA分析师来说，这个聪明的目标是另一个不容易衡量的目标，但它对于职业成功仍然很重要。
QA分析师的工作最终是发现公司产品的问题——理想情况下，在用户发现问题之前。因此，测试者往往是坏消息的传播者。有时候，当测试人员在代码投入生产之前捕获一个bug时，开发人员会松一口气。但是在测试人员和开发人员之间也有争论，后者坚持认为他们的代码没有问题。开发人员可能会争辩说有一个坏的或不完整的需求，或者测试没有正确地完成。
获得调解冲突的能力。这是一种有助于消除团队成员之间因缺陷的根本原因而产生的问题的技能，特别是当修正和重新测试所需要的项目时间会导致额外的压力时。设定个人目标，调解一定数量的冲突。
解决冲突是一门需要自信的艺术。冲突会引发焦虑，也会滋生仇恨。完全转移或避免冲突是一个值得实现的目标。
5.提升项目管理技能
QA分析师实际上是在项目中运行小型项目。测试计划、资源分配、测试执行时间估计、缺陷补救的调度时间以及重新测试的时间安排——这些都是对软件项目的总体QA做出贡献的小的、独立的项目。所有这些工作都需要一些项目管理技能。
项目经理会在整个项目计划中为测试周期或sprint预留时间，但是这个人并不总是能够了解QA分析师所做的细节。一些CMM从业者需要QA分析师在整个测试计划中填写测试任务和时间线，从而减轻项目经理的一些负担。
为了保持今天的一致性和相关性，看看受控环境中的项目(PRINCE)模型，它已经演变成PRINCE2敏捷。PRINCE2敏捷策略特别关注于如何将项目管理和敏捷产品交付作为规程结合起来，这使得它与QA分析师非常相关。
衡量和实现这一明智目标的一种方法是获得诸如PRINCE2、认证Scrum Master或项目管理专业人员等标准的认证。
通过满足这些有效的目标，QA分析师可以沿着他们的职业道路前进到一个位置，在那里他们仍然可以应用他们的测试技能并保持敏锐的直觉思维。
