随着产品和服务的部署越来越快, quality assurance (QA) has to adapt to the evolving environment, sometimes achieving the same level of coverage in a shorter period of time. 我们如何避免犯……的错误 数量重于质量? How do we cover more, increase efficiency, 和 still be effective in our work?
我们都知道创建测试用例需要很长时间. 我们必须运用不同的技术, 测试类型, 记录前提条件, 步骤, 预期结果. 另外，我们必须创建一个测试计划.
质量保证专家 经常发现自己没有时间了, especially when they try to accomplish all the phases in the QA process. The biggest headache is the test planning 和 design phase, revolving around test case creation 和 test documentation. 可能需要几个小时, 有时甚至需要几天的努力才能完成所有的工作, ,通常, they choose to skip certain deliverables 和 summarize instead, leaving out important information that can lead to a test being forgotten. That also results in losing the benefit of knowledge sharing.
我是传统测试用例和测试计划的忠实粉丝. 它们不仅帮助识别大量的测试用例，而且还很好地记录了产品. You can use them in training, 和 any person on the 团队 underst和s them. You do not have to overly rely on experience for somebody to begin 测试. Test plans have further information such as detailing the 范围, 测试项目, 您正在测试的功能, 那些你不是的人. There is also a risk analysis that goes into the test plan. 这些只是一些好处，然而，在许多情况下，它花费的总时间太长了.
测试计划的目的是项目涉众之间沟通和达成协议的一种方式. 它有助于详细说明目标, 所需资源, 以及任何测试产品的方法或策略. 该计划有助于确保每件事都被考虑到，并使利益相关者对质量保证过程的战略投资充满信心. There is no concrete rule that this plan must be 10 pages long. 我们可以重新定义它以适应快节奏的团队.
另一种方法是简化传统的测试用例和测试计划，以减少所需的时间投资，但交付相同的结果, 如果不是更多的话, coverage 和 documentation that makes sense to all stakeholders. This involves a single source of truth, a user flow with a twist. 通过构建和维护用户流, you will have the bulk of your test case design already done for you. 这可以应用于任何产品或团队，并且在细节和结构上都是通用的.
使用流程方法将帮助您实现更快的测试文档周转时间. This is not only for manual QA but for automation as well. The flow can also contribute to some sections of the test plan.
不要再拖延了，让我们直接进入 构建用户流 对于一个简单的信息网站.
我们首先需要一个免费的思维导图工具. 我个人使用 XMind. 请随意下载任何您喜欢的工具-我们将只使用基本功能，例如绘制流程图, 为一些主题添加“注释”, 不同条件上色, 使用标签.
我们的第一步是了解产品. 通常，您将参考模型图像或线框图. 如果这些都不可用, a quick catch-up call with a developer will yield exactly what screens to expect. 在我们进行的过程中，请随意跟随和练习. 该流不仅限于用户界面，还可以用于映射api到api的调用, 数据库关系图, 依赖结构, 和更多的. 同样的原则也适用.
我们通过只使用三个参与者来限制流. 你会有一个 条件, 哪个是具有特定角色的用户, 已清除的缓存, 或者用户第一次登录. 其次，我们有 州/页, which is an actual GUI component, like a homepage or a sign-in window. 接下来是 行动, which is a physical user interaction that causes the state to change. 让我们看看这是怎么做的.
这是我们的主页，也就是国家. 我们有两个可能的操作:注册和登录.
然后，我们有Sign In窗口，另一个状态. 这里的操作是Back和登录. 注意，我们没有将输入字段归类为操作. 非常欢迎你来做这件事. 根据我的经验, I have found that when working on complex systems that run a few tenths deep, 维护起来有点困难, 但是对于简单的应用程序, 这是一个非常合适的工作.
最后，当用户成功登录时，我们将进入仪表板. Here, we have three actions—we can 创建、编辑或删除消息.
现在我们有了足够的信息来开始用户流. 让我们总结一下我们所拥有的. 我们记下产品的状态. 从我们所看到的来看，有四页:
We write down our actions on each page/state that can be “interacted” with:
我们从 产品名称, 哪些可以改变以适应你的环境, but this fits most 团队s 和 their products 和 also provides a good starting point. 下面，我们会注意到旁边有一个问号 注册.
很多次, 在敏捷中，你会遇到一个还不在范围内的组件，或者还没有计划在未来发布. 注意它的存在，但在我们得到更多信息之前，把它作为一个未知数.
我们在XMind中将上面的代码绘制为:
You will notice that I am simply color-coding what is a state 和 what is an action. 我还在主页上添加了一行取消 行动，以准确地表示该流程. 当用户选择“登录”时，我们还看到两个条件.” Although both go to the dashboard, we still want to test both possible conditions.
XMind的好处是，如果我们在一个大的, 复杂的应用程序, 我们可以创建图表的不同层次, so if you want to break up the flow into multiple flows but keep them linked, that is very easy to do with linking the topics to separate sheets. 您可以选择插入一个超链接, 从向导弹出, 你可以选择一个动作所指向的“状态”. This means if you select “登录” on XMind 和 it hyperlinks to “指示板,，您的鼠标光标将跳转到“仪表盘”,即使是在另一张纸上. 很酷.
我们的流程缺少的是标签. We give the product a label of 0, as that is the root of the flow. 然后, 每个州(蓝色), 我们添加了一个s#标签, 对于每个动作(绿色), 我们添加一个a#标签, 最后, 每种情况(青色), 我们添加了一个c#标签. 每个标签不能重复. 我们最终得到以下结果:
To track which number you last used—because as the product grows, 试图找到最高的数字可能是一个挑战—我将其存储在流的Root主题中, 像下图:
现在我们来到了创建测试用例的部分. 我们将重点关注预期结果, 在测试用例中，哪些可能是最重要的信息，哪些可能是特性验收标准的一部分. 我会为每个部分或测试添加一个标题，然后在下面列出预期的结果. I will do this for only a subset to keep this article concise:
然后，登录窗口:
然后，签名行动:
它确实正在成形. 注意添加的边界和安全性测试. You may title this 然而 you like, whichever is easiest for you to tag. 我有时用测试类型标记标题, 如安全- JS注入-电子邮件字段, 然后在下面列出预期的结果.
In most 团队s, we find changing requirements a hassle to maintain. 没有更多的. 假设我们刚刚了解到，所有首次使用的用户都必须看到t和c窗口，并且在进入仪表板之前必须接受，这没问题. We can add the state 和 actions relatively easily, 像下图:
现在我们看到了添加新状态的影响. 注意，一开始编号可能很奇怪, 但只要我们记得, 这些数字只是为了唯一地标识每个参与者——很像数据库中的主键. Do not forget to update your “Last Used” notes to keep track of the numbers you use.
After all this progress, we now get to the easier part: test case creation. 让我强调一些要点. 我们给每个演员都贴上了标签, 每个测试都有题目, 我们对每个测试都有预期的结果, 作为我们流程的一部分嵌入条件. This sounds like the recipe for a test case, don’t you agree?
All we do now is copy-paste what is on our flow into any test case management tool, 汇流网站或Excel文件，你想. 我还在用值得信赖的Excel. I keep a record of all my 测试用例 in one file called “Baseline” - very original. 一旦我完成了复制粘贴，我结束了下面:
您可以根据需要随意添加测试类型、测试状态和测试配置的列. The conditions may be better placed before the “Sign In” action, 然而, 做这件事没有对错之分, it’s down to personal preference 和 how you organize yourself.
有几件事需要强调. 一个是我合并了共享相同信息的单元格——不需要重复复制粘贴, 它浪费时间，而且更难维护. 另一项是步骤. 您将注意到，其中两个测试的步骤包含状态和操作编号. This can be used when you have the flow as part of the SDLC in your 团队. 然后，所有涉众通过提供信息、模型、增加风险等方式对流程做出贡献. 这意味着通过说明流号, 团队中的每个人都知道该怎么做, 如果有新的团队成员, 这就像“沿着小路走”一样简单, 参考笔记.”
这也有助于自动化. 您可以为每个步骤或操作提供唯一的引用. By creating an automation pack that is structured like your flow, 您将发现您可以构建的自动化框架具有高度健壮性的潜力, 模块化, 并且在整个应用程序中兼容. 它将在更大的范围内利用分页对象, 这将减少维护时间，并允许您将测试功能替换为新的功能.
The flow can be the single source of truth for all product documentation, 包括技术规格, 功能规格, 测试用例, 状态转换, 数据流, 等.
那么测试计划呢?你一定在想. 这很简单. 测试计划包含如下部分:
介绍和范围将是 JIRA 故事或其他工具中的任何任务或故事. 测试项只是当前部署在环境上的软件版本或提交号, which you can link to the JIRA ticket or on your test run either on 融合 或者测试管理工具.
要测试的特性 和 不需要测试的功能 实际上是你的测试用例吗. The 测试用例 chosen to be executed for this JIRA story are “要测试的特性,，任何未列出的都是“不需要测试的功能”.” Quite simply, list the States 和 行动s you will be 测试 on the story ticket.
假设, 风险, 甚至可以将环境需求编译成文档或添加到JIRA的评论中, sometimes even placed on 融合 和 linked to the story.
A WBS is an estimate you assign to the story in terms of story points or hours, 取决于你的项目. Entry 和 退出标准 will already be part of the story.
如果您想要接近“传统”的测试计划, 你可以让开发者或其他利益相关者对故事做出“是”或“否”的评论，看看他们是否同意QA计划. 这在技术上充当您的数字签名. 所有这些都可以很容易地包含在你的QA过程中，并帮助你简化QA文档.
使用上述方法和测试计划的用户流程将帮助我们减少重复工作，并帮助QA在不牺牲质量的情况下实现更快的周转时间.
这种方法在指导我保持组织，覆盖每一个基础，和 构建整个团队都能理解的文档. 在敏捷, 这真的会派上用场, 和 the best part of it is we are still abiding by one of the Agile approaches: “简化文档.”
我真心希望这些信息对你有所帮助. 这完全取决于作为读者的你. 这并不是一套需要遵循的具体规则, these are only guidelines to give you ideas to grow 和 improve your efficiency. 没有一种技术适合每个项目, 团队, 或产品, 但它可能为另一个创新想法铺平道路.
旅程将更多地处理用户与产品交互的可能方式, whereas a user flow describes the actual routes a user can take. 总而言之，用户旅程就是引导用户到达目的地的导游. 用户流是实际的工具，e.g.， UI组件的结构.
用户流程图是详细描述用户在应用程序中可以采取的路线的流程图, from each screen they will see to each button or function they can interact with. 用户流旨在显示程序中的不同用户路径，以及他们将如何使用产品实现其目标.
它在过去被称为“用户界面流”和“任务流”图.
QA helps a company meet its clients’ dem和s 和 expectations. QA将积极报告产品质量, 什么可以提高或降低涉众对产品的信心水平，直到他们乐于将产品发布到生产中. QA can save costs 和 fix issues early in the development phases.
德班，夸祖鲁-纳塔尔，南非
2020年3月10日成为会员
世界级的文章，每周发一次.
世界级的文章，每周发一次.
