测试工程师需要知道的30件事-软件测试圈

测试工程师需要知道的30件事

这是了解有关软件测试的更多信息的指南。当您开始您的旅程时，您将拥有可以完成的任务。软件测试人员总是在学习，但我们不能总是对其进行量化。我们了解我们正在测试的产品。我们学习并发展与开发人员、经理和测试人员的关系。这使我们擅长我们所做的事情。我们也是变色龙。我们根据我们所处的环境或我们必须测试的产品进行更改。我们必须继续自学测试每种产品所需的工具。

我已将任务拆分，以创建更易于消化的信息块。这绝不是一个完整的清单。它会让你开始你的旅程。完成每项任务并努力检查活动。

完成此处列出的活动后，还有进一步的探索要做。当您按照这些步骤操作时，反思您到目前为止所做的事情。也许您想在另一门研究课程中重做一项任务或冒险。任务甚至可以以不同的顺序完成。每个测试人员都是不同的，这对您的测试能力来说是一笔财富。

（任务 1）您对软件测试感兴趣吗？

让我们从自我反省开始。

成为测试人员的一个重要部分是您的心态并意识到这一点。

是什么让你看到这篇文章？
为什么软件测试对您有价值？
你认为软件测试是什么？我们将在下一个任务中更多地讨论这个问题，但最好考虑一下您目前认为它是什么。
花点时间思考以上问题以及您可能有的其他问题。在本指南结束时，目标是让大部分问题得到解答。你也会有更多的问题。问题促使寻找答案，从而导致学习。

我们每天都被科技所包围。您在日常生活中使用的东西可能会困扰您。也许工作中的一个软件包加载时间超过一分钟。手机上的应用程序在更新后立即冻结。或者当您被锁定在电子邮件之外并发现您无法恢复或重置密码时。通过在加载时查看任务管理器，您可能已经开始更多地考虑该软件包。

你能成为一个努力把软件做得更好的人吗？你能成为用户的拥护者吗？这生意？你的同事？

你知道到达那里需要什么吗？你知道你需要学习什么吗？想一想您在生活中遇到的所有好的和非常糟糕的软件。你是两者的变色龙。在好的情况下，您希望产品保持良好状态，因此您会不断学习以保持领先地位。在糟糕的情况下，您想了解更多，这样您就可以感觉到在软件发布之前您已经做了所有您能做的事情。学习是关键。无论情况如何，即使您没有意识到，您也会一直在学习。

这听起来令人生畏，不要让它让你失望。从第一个问题开始思考。读完本指南后，您将更有信心回答所有这些问题。

接下来做什么：

承诺打印你为什么在这里（便利贴或任何你喜欢的媒体）
你打算在这结束时去哪里？
您认为现在有哪些技能对测试有用？
您目前认为软件测试是什么？
将本指南计划到您的日程安排中。对你能取得的成就要现实一点。考虑一下您的日常工作和精力水平。

（任务二）什么是软件测试？

首先写下您认为软件测试是什么以及软件测试员会做什么。

软件测试有很多方面。它并不总是涉及使用产品。这不仅仅是寻找错误。测试可以从需求阶段开始。考虑产品应该做什么、可能存在风险以及用户/客户如何浏览产品都是测试的一部分。

我最近进行的一次讨论，关于假设客户是您的用户是否公平，让我对我们用来代表利益相关者的术语有了看法。对我来说，利益相关者涵盖了对软件产品感兴趣的每个人。最后，我们一致认为，为你的软件买单的人不一定是真正使用它的人。这是一个很好的例子，说明软件测试人员应该如何从不同的角度看待事物。以下是从与其他测试人员讨论他们认为测试是什么或不是什么时收集的示例。

什么是测试测试不是什么
验证软件是否满足用户的预期价值。调查产品以找到对我们的利益相关者有价值的任何信息。简单、快速、可预测。仅验证产品与描述相符。
减轻意外 - 尝试在软件发布给利益相关者之前发现问题。提高质量——这是一项整个团队的工作。证明该软件曾经工作过。
探索产品。软件开发中一项有价值的活动，但由于其不可预测和创造性的性质而经常被误解。每个人都很好理解或重视。一个固定的、缺乏想象力的、最好遵守严格规则的过程。
沟通 - 与利益相关者（客户、用户、开发人员等）一起工作以了解产品是否正在改进。项目要取得成功需要经历的阶段。
无穷。所有测试都是抽样。对于每一个非平凡的产品，都有数量难以想象的参数和大量可能的值。你怎么知道你在测试重要的？完成 - 我们可以决定停止标准，但可以检查的组合数量是无限的。
接下来做什么：

阅读这份软件测试员所做工作的清单。
尝试向您周围的人询问此任务的标题。询问与测试人员和非测试人员一起工作的人，询问 Slack 上的人，甚至询问您的家人。这与您最初的想法有很大不同吗？你得到的反应有何不同？
研究其他行业，如制药、电器等。他们的测试方法是什么？它与科技行业有何不同或相似之处？这些差异是否会改变您对如何进行测试的想法？

（任务 3）非测试人员的测试

当我开始进行软件测试时，我不知道什么是测试。我也不知道从哪里开始。我遇到的最有用的资源之一是Katrina Clokie 的非测试人员路径测试。使用卡特里娜飓风的途径，我能够理解测试及其提供的价值。我还能够进一步调查她的参考资料，以开始扩展我的知识和我应该寻求建议的人员名单。

这是一件不可能一蹴而就的事情！我建议每次阅读并参考本指南的任务 1。反思您在 Katrina 的博文中阅读的每个链接。你有什么想练习的吗？有没有什么是你不做的，如果有，为什么？这是否改变了您在任务 2 中写下的想法？

接下来做什么：

与您的团队分享链接。
每天阅读一篇来自 Testing for non-testers 的文章。
创建您自己的要学习和练习的事物列表。您很可能会不断更新它。

（任务 4）社交

这将是一个稍微容易上手的任务，但您需要付出努力才能坚持下去。从您喜欢或感到舒服的方式开始。我确实建议您尽可能完成以下所有步骤。

参加社交活动让我遇到了当地的测试人员，当我遇到棘手的问题时，他们愿意帮助我。通过这些社交聚会，我在一个陌生的城市交到了一些朋友。与理解你在说什么的朋友有同情心的倾听真是太好了。

接下来做什么：

转到 Meetup.com 并寻找本地软件测试聚会。
加入Slack 测试部。
加入 Twitter，开始寻找要关注的测试人员并参与一些对话。
加入The Club，这是一个软件测试和 QA 讨论论坛。
阅读 Andrew Morton 关于参加布里斯托尔 STC 聚会和加的夫 STC 聚会的博文。
开始查找测试会议，例如 TestBash、敏捷测试日、EuroStar、STPCon、全球测试务虚会、TestCon、STAREAST、Let's Test、Nordic Testing Days。我们将在任务 23 中详细介绍这些内容。它们是社交的重要组成部分。

（任务 5）组织起来

当向您抛出如此多的信息时，可能很难保持井井有条。我为此苦苦挣扎了很多，我仍然偶尔会这样做。在我开始使用时，另一个测试人员向我推荐了Tiny Habits 。我经常回到它并为自己设定新的小习惯来实现，特别是当我觉得事情出了问题时。这不会花费很多时间，但从长远来看会为您节省时间。

您可能还想考虑编写思维导图。有很多免费工具可以帮助您解决这个问题。我发现思维导图可以帮助我更轻松地简化随机思维过程。您是否曾经有过一百万个松散相关的想法在您的脑海中闪过，但您无法将它们按照合理的顺序进行处理？思维导图可以帮助解决这个问题，好的 ole 可靠的贴在墙上的方法也可以。

如果你更偏向于游戏玩家，或者以上内容对你没有吸引力，你也可以试试Habitica。这是一款免费应用程序，您可以在实现日常目标时赚取积分/金币。如果您错过每日目标，您也会失去健康。有点酷！

接下来做什么：

注册小习惯并坚持一周。
开始制作思维导图。
调查一下 Habitica 是否适合你。
创建个人看板流或Trello看板。从列标题“待办事项”、“进行中”和“完成”开始。为您想要实现的每件事添加一张卡片，并随着您的进步将它们移动到各列中。

（任务6）查看测试平台部

注册Ministry of Testing Platform并进行探索。我发现它对我的职业生涯来说是一个了不起的资源。我可以观看培训视频、访问测试人员博客，并且我会收到有关他们举办的即将举行的活动的通知。我从免费会员开始，今年终于升级为付费会员。

接下来做什么：

从免费的Ministry of Testing 会员资格开始。
在测试部平台上阅读这些web 测试 101篇文章。
从有史以来最受欢迎的 TestBash 谈话播放列表中观看这些软件测试谈话。
观看丹尼·丹顿 (Danny Dainton) 的这段 99 秒精彩视频，讲述他如何不再浪费时间。
进一步调查测试部平台上的内容。

（任务 7）什么是错误？

当我看到一个软件错误时，我就知道是软件中的一个错误，或者至少我喜欢这样认为。我认为解释什么是 bug 很容易。当我试图找到一个定义时，我发现很多定义都没有足够涵盖范围。James Bach 将 bug 定义为“任何威胁到产品价值的东西。让那些意见很重要的人感到厌烦的东西”。这是一个很好的高级定义。在Testing Computer Software上，您会发现“大多数错误会导致程序在程序员不希望或不期望的情况下改变其行为，或者导致程序在程序员期望的情况下不改变其行为”。

在大多数定义中，我发现它们只提到代码或开发人员。这些都没有错。回到 James Bach 的定义，看看这三个朋友的想法，我们也可能在规范中遇到错误。这会威胁到产品的价值，而且它不会成为代码的错误。

想想你使用的技术：

你在其中遇到过错误吗？
为什么你觉得他们是虫子？
您是否对此采取了任何措施（例如，通过应用商店报告应用程序中的错误）？
你能想出三种不同的东西来帮助你决定一个错误是否真的是一个错误吗？这些称为 Oracle，我们将在任务 13 中更详细地研究它们。

（任务八）推荐读物

这是您阅读清单的起点。你不会在一天内实现所有这些。我在这里列出的一些书籍将在本系列后面的相关章节中引用。这是为了让你知道这些书的存在，并努力从你社交时结交的朋友那里购买或借阅它们。

我问人们他们会推荐哪些书籍进行测试，我得到了以下信息（这绝不是一个完整的列表）：

探索它！伊丽莎白·亨德里克森 (Elizabeth Hendrickson) 所著，这是一本关于探索性测试的优秀书籍。
Chris Nodder设计的邪恶，我喜欢这本书！每次阅读我都会学到新东西。稍后我将对此进行更多介绍。
Lisa Crispin 和 Janet Gregory 合着的《敏捷测试》是其中一本人人都赞不绝口的书，你想知道为什么你花了这么长时间才读完它。
丹尼尔·卡尼曼 (Daniel Kahneman) 的《思考，快与慢》(Thinking, Fast and Slow)，我没有亲自读过。这已经被足够多的人推荐给我，我将在完成本文后立即开始使用它。
测试部平台还有一个免费和付费电子书列表，这些电子书会随着时间的推移而增加。既然您是会员，请检查一下。

下一个：

开始阅读上面提到的其中一本书。如果你不确定从哪里开始，我建议 Thinking, Fast and Slow。
查看CAST 2015 演讲者推荐的阅读清单。
在 Slack 频道之一或 Twitter 上询问有关阅读书籍的更多建议。
探索读书俱乐部。

（任务 9）写一个用户故事

用户故事就像您使用扁平包装家具获得的一组说明。通过编写用户故事，它将帮助您了解他们的目的。

它应该提供：

需要做什么的描述。
概述故事需要完成的验收标准。
任何超出故事范围的标准都被视为已完成。
注意开始故事所需的任何依赖项。
Mountain Goat Software 提供了敏捷用户案例示例，可让您了解在野外时会发生什么。EPIC 本质上是一个大型用户故事。它们被分解成更小的可消化或可交付的部分，称为用户故事。

以这个用户故事为例，整体 EPIC 将是“Flat Pack TV Stand”。用户故事是“左腿和顶架结构”的一小部分。依赖项是我们需要但不是我们会做的事情，例如，我们需要一把螺丝刀才能组装架子。验收标准是我们实际必须做的事情。

编写用户故事将帮助您更多地考虑为用户编写需求。它还将帮助您考虑测试这些用户故事所采用的方法。作为测试人员，在分析用户故事时，您将拥有一套独特的技能。您将能够突出显示遗漏的细节、误用案例、滥用案例以及它如何被误解。不是每个人都有机会为用户故事写作提供早期输入。这是一个很好的过程，你在编写一段代码之前就进行了测试！

你今天的任务：

使用上面的模板编写用于制作吐司、花生酱三明治甚至宜家家具的用户故事。
你怎么知道你是否错过了什么？
你做过任何假设吗？
考虑需要完成的顺序。是否有任何可选的输入？
是否有任何要求或先决条件（例如，假设用户有面包）？
尝试完全按照您的用户故事从头开始制作吐司或三明治。

（任务 10）测试角色

当你测试时，你不应该只为你测试。您需要考虑不耐烦的用户、不慌不忙的用户、有点测试能力并喜欢“破坏”事物的用户等等。Katrina Clokie 有一个很好的开始测试角色的指南。当您熟悉应用程序时，您可能会忘记这样的事情，您可能会在某种程度上进入自动驾驶仪。我发现尝试更多地了解用户角色有助于我避免这个陷阱。

在考虑角色可能不存在于项目中之前，可能还值得研究一下角色研究和文档是否已经存在。然后您可以使用它从测试的角度构建东西。

今天：

选择手机上的应用程序或计算机上的程序进行测试。
使用 Katrina 文章中的不同用户角色浏览它。
你从中学到了什么？
应用程序在每个角色下的表现如何？
思考并研究其他人如何处理角色。

（任务 11）测试用户故事

这链接到任务 9 和任务 10 的后续。记录测试的方法有很多，但我们不会在这里重点介绍这些方法。如果您从未编写过测试文档，则可以查看Tutorialspoint上的测试用例模板。

任务 9 和任务 11 有很多相似之处：在编写用户故事时，您也在测试它，不是吗？但是发生了变化的是，您现在拥有了一个实际的产品供您使用，这让世界变得不同。

您现在可以动手做一些事情，您可以抛开理论并将其付诸实践。这是你开始使用你的学习能力的地方。您学习新的有趣信息的速度和准确性将决定您作为测试人员的技能和价值。

测试故事时，请专注于您的心态。这是测试用户故事时最重要的部分。

测试这个故事时要问自己的问题：

这个故事对谁重要？
这个用户故事试图解决的一个问题是什么？
这怎么会被误解呢？
意外错误如何进入其中？
它绝对不应该表现出什么行为？
你什么时候完成？
您在什么时候想退出分析并开始测试？
这感觉合理吗？

（任务 12）启发式

Cem Kaner 和 James Bach将启发式描述为“解决问题或做出决定的一种容易出错的方法”。Karen Johnson说，启发式“指的是基于经验的解决问题、学习和发现的技术。在穷举搜索不切实际的情况下，启发式方法用于加快找到满意解决方案的过程。这种方法的例子包括使用经验法则、有根据的猜测、直觉判断或常识。”

James Bach 有一篇关于如何使用启发式设计测试策略的优秀文档。仔细阅读并思考一会儿。当你第一次阅读它时，它会吸收很多东西。如果您考虑如何在测试中应用和理解启发式方法，那么随着时间和经验的增加，理解这些概念会变得更加容易。

Michael Bolton 有一篇关于启发式方法的有趣博客文章可以帮助您了解何时停止测试。这在测试中很重要，因为我们可能会专注于测试一个功能，而可能会错过其他功能。

你能想到任何其他启发式吗？向某人解释并给它起个名字。测试球体并探索它！任务 8 中的内容可以帮助您解决这个问题。
你知道你以前使用过的任何启发式方法吗？使用以上文章作为指南。
研究并分享您可能发现的其他启发式方法。
选择任何启发式并开始与同行讨论。

（任务 13）神谕

根据Michael Bolton 的说法， “oracle 是一种原则或机制，我们可以通过它判断软件是否按照某人的标准工作；oracle 提供了正确的答案——根据某人”。Cem Kaner将其描述为“软件测试 oracle 是一种帮助您确定程序是否通过测试的工具”。

Michael Bolton 还谈到了所有预言都是启发式的，但并非所有启发式都是预言。这可能需要时间来理解，所以请花点时间。Katrina Clokie 关于启发式算法和预言机的文章可能会帮助您从日常角度思考这个问题。

接下来做什么：

阅读Michael Bolton 的《无地图测试》。它提供了有关使用 oracle 确定您是否“完成”测试的分步指南。
查看Lynn McKee 整理的测试助记符列表。另外，请阅读Michael Bolton 的FEW HICCUPS，它扩展了 HICCUPS 助记符。
你用过什么神谕？你能在你的测试工作中看到任何神谕吗？
当您手机上的应用程序更新时，它是否保持一致的行为？如果不是，你喜欢这种不一致吗？它是对以前行为的改进，还是您认为它是一个错误？

（任务 14）白盒和黑盒测试

白盒测试和黑盒测试是软件测试的两种方法。将它们视为测试类型的两把伞。

白盒或玻璃盒测试是一种测试方法，测试人员了解程序的内部工作原理。

测试人员根据对应用程序内部代码的了解编写策略来测试程序。他们了解功能在做什么以及什么输入将产生什么输出。这种类型的测试通常侧重于语句、代码行、代码分支等的覆盖率。白盒测试最常用于单元测试。

此类测试的最大风险之一是无法找到缺失的功能。如果代码行从未存在过，则不能用测试覆盖该行代码。测试人员需要了解编写程序所用的语言。通过这种类型的测试，考虑到您在产品中花费的时间，您自然也会对自己的思维模式产生偏见。结果，您可能会因为过于接近它而错过明显或不明显的问题。考虑登录您的电子邮件。这是你每天都在做的事情，而且你每天都遵循同样的模式。您最后一次注意到登录页面或流程发生变化是什么时候？你已经习惯了你期望看到的东西，以至于你可能不会注意到意料之外的事情。

黑盒测试是一种测试人员不知道程序内部运作的方法。测试基于需求和功能。与白盒测试相比，这种测试的优势之一是可以识别缺失的代码语句。这种方法不需要测试人员对编写程序所用的语言有任何了解。这种类型的测试的一个风险是测试提供的覆盖范围未知。

在 Alexandra Casapu 试图解决像这些黑盒拼图这样的谜题的研讨会上，我有很多乐趣和挫败感。这些是磨练黑盒测试人员技能的好方法。尝试其中的一些。你有没有想出其中的任何一个？如果你这样做了，你能第二次找出它们吗？你还记得你的方法吗？你第二次改变了你的方法吗？

接下来做什么：

尝试做一些黑盒拼图。
尝试测试您手机上的任何移动应用程序，您实际上是在进行黑盒测试。
转到可汗学院计算机编程部分，尝试他们的一些任务，看看您如何利用代码知识创建或识别问题。

（任务 15）可访问性测试

你认识色盲或使用屏幕阅读器的人吗？我认识一些色盲、视力受损、耳聋、阅读障碍或患有光敏性癫痫的人。因此，我一直在考虑这些用户以及我们应用程序的“标准”用户集。幸运的是，有一些工具可以测试应用程序的可访问性级别。一个有趣且简单的尝试技巧是在没有鼠标或触控板的情况下浏览您正在测试的应用程序。听起来很简单吧？试一试，看看您的想法。您可以将各种插件添加到您的浏览器中，以像色盲人士一样查看您的应用程序。

接下来做什么：

选择一个应用程序并尝试对其进行一些简单的可访问性测试。它的表现是否符合您的预期？您遇到过什么问题吗？
阅读软件测试人员的 Web 可访问性指南。
An Alphabet of Accessibility Issues是一篇很棒的文章，可以让您深入了解人们的各种需求。
如果您对移动应用程序测试感兴趣，您可能想阅读移动用户的辅助功能。
奖金任务，如果您想更多地探索可访问性，为什么不尝试30 天的可访问性测试？

（任务 16）播客

曾经想在工作、开车或乘火车时了解新事物吗？我总是想在工作中学到更多，但有很多事情要做。我不能总是坐下来观看演讲视频或阅读书籍或论文。播客让我有机会在工作或通勤时学习。

我在 TestBash 认识了Vernon Richards，并开始在 Twitter 上关注他。他分享了一个他参与的与测试相关的播客链接。我有一些空闲时间，所以我调查了一下。从那里我开始探索所有其他的测试播客。现在我试着每周至少听一首。

我喜欢听两套播客。Joe Colantonio Test Talks是第一个。去那里开始挑选要收听的播客。

在 Pub 中进行测试是我的另一个最爱。我听过的第一首歌是An Intro to Cynefin，从那以后我就一直在慢慢研究这个话题。两个地方的一些主题可能有点沉重。找到您最感兴趣的内容，然后从这些内容开始。

播客是一个很好的资源。尝试养成倾听他们的习惯。我相信你很快就会有自己喜欢的。

接下来做什么：

查看 Ministry of Testing Podcast Testing Feeds。
探索让我们谈谈测试的内容。
收听测试部播客系列之一的播客。

（任务 17）作为测试人员的用户体验 (UX)

用户体验几乎就是它所说的那样。它是用户体验您的应用程序的方式以及他们在使用该应用程序时的响应方式。唐·诺曼 (Don Norman) 将其描述为不止于此。测试人员的任务通常是了解用户体验，并通过向团队其他成员报告任何可能的问题来帮助确保用户拥有良好的体验。即使在产品上市之前，测试也有助于突出用户体验问题。一个例子是页面需要很长时间才能加载。用户不会等那么久，因为竞争对手的产品没有遇到同样的问题。我们应该调查延迟并尝试修复它。

Nielsen Norman Group 有一篇关于用户界面设计启发式的文章，可以帮助改善用户体验。

归根结底，是用户会就他们对产品的体验向您提供反馈。作为测试人员，您可以帮助确保他们的初始体验是良好的。

接下来做什么：

开始真正考虑用户体验。
你能回忆起你曾经有过的一次出色的积极用户体验吗？
你能解释一下为什么你觉得它是积极的吗？
对负面案例做同样的事情。

（任务 18）回归测试

软件开发的很大一部分是让事物协同工作并保持它们协同工作。即使花费了大量的时间和精力来利用这些实现，您也会发现表面上存在裂缝。

回归测试是一种技术，它试图找出软件中的问题，这些软件以前可以运行，但现在由于某些更改而损坏。

由于回归以及这给开发人员和管理人员带来的不确定性，引入了许多测试概念。由于回归问题，自动检查、重新运行测试用例、精心设计的冒烟测试……都已到位。

回归测试涉及重新测试以前有效的功能，以确保它们不会受到添加新功能或重构现有功能的影响。

接下来做什么：

想一想您最喜欢的应用程序之一的某个功能不再起作用的时候。这可能在游戏中，例如 Pokémon Go、Facebook、Netflix 应用程序或任何其他经常更新的产品。我们已经习惯了这些频繁的更新和错误修复。此外，明天可能会修复故障功能。有时，这适得其反，用户会厌倦并完全丢弃该产品。
考虑这些公司用来解决回归问题的策略，并将它们与您公司使用的策略进行比较。他们有很大的不同吗？这对你有意义吗？你能想出其他策略吗？
你有什么可以练习回归测试的东西吗？让我们回想一下您手机上的那个应用程序。最近更新了吗？看看应用程序创建者所说的他们添加的新功能。它是否破坏了以前有效的功能？如果是这样，请向他们报告。他们可能已经意识到这一点，但如果没有，您已经帮助改善了某人的体验。
另外，请阅读以下有关回归测试的文章：

Cem Kaner 和 James Bach 写了关于回归测试的非常详细的文章。
思考如何获得 Patrick Prill 设置的良好回归测试。
与 Karen Johnson 一起进行回归测试的启发式方法。
Leanne Howard了解回归测试的价值。

（任务 19）敏捷测试

如果您是软件领域的新手，您将不会听说过Waterfall、Agile或DevOps等开发实践。这些是软件开发的方法或方法。在下图中需要注意的一个关键点是测试适合每种方法的位置。DevOps 相对较新。我们将从敏捷开始，让您轻松上手，稍后您可以研究 DevOps。

图片参考：http ://blog.spec-india.com/wp-content/uploads/Project-Execution.jpg

我将带您回到我在任务 8 中提到的书籍，特别是Lisa Crispin 和 Janet Gregory的那本书。Elizabeth Hendrickson对敏捷测试有一个有用的概述，可以帮助您感受它。Augusto Evangelisti 在这次采访中谈到了敏捷如何改变了测试人员的角色。

你今天的任务：

开始阅读丽莎和珍妮特的书。
观看 Lisa 和 Janet 的演讲，他们揭穿了敏捷测试的神话。
阅读 Esther Derby 的七个敏捷最佳实践。
阅读 Huib Schoots 的《是什么让敏捷测试与众不同》？
Elizabeth Hendrickson 的敏捷测试也可能对您有用。
Huib 有更多您可能想要探索的敏捷测试资源。
奖金任务，如果您想更多地探索敏捷测试，为什么不尝试30 天的敏捷测试？

（任务 20）配对

结对测试涉及两个人在同一台机器上使用单个键盘一起工作来测试一个软件。一个人拿着键盘，而另一个人则提出想法或测试、注意并做笔记、倾听、提问、获取参考资料等。这种方法应该有一个共同的目标，两个人将不断沟通以确保实现目标。沟通是这种测试方法的关键。涉及的双方都应该对他们在做什么以及为什么这样做有共同的理解。

这很容易，也很有趣。你只需要你和另外一个人。Katrina Clokie从头到尾都有一些优秀的材料。我尽量在工作中做到这一点。这是从不同的角度看待您的工作甚至学习新技能的好方法。

接下来做什么：

阅读卡特里娜飓风的文章并找到配对伙伴。如果您不在软件公司，请咨询您参加过的聚会或 Twitter 或 Slack 上的人，您甚至可以尝试远程配对，就像 Elisabeth Hocke 在她的测试之旅中所做的那样。
阅读Lisa Crispin 撰写的关于配对测试的优秀文章
与这个人配对并反思你的经历。
你从中学到了什么？
下次有什么更好的？
你会再做吗？
你教了别人什么？
卡特里娜飓风还在TestBash Brighton 2016上谈到了这一点，如果可以的话请观看。

（任务 21）暴徒测试

Mob 测试（Mob Programming 或 Mobbing）不是你可以自己做的事情，但你应该在Mob Programming Guidebook中阅读它。如果可以，请尝试在工作中这样做，或者让几个人一起尝试一下。执行此操作的好机会是在冲刺演示会话结束时。从与整个团队的 15-30 分钟时段开始。让他们作为一个团队开始提问和测试产品。这是让非测试人员参与测试并可能有助于产生一些新想法或方法的好方法。

如果幸运的话，你参加的聚会可能会试试这个。如果他们不尝试，请问他们！我认识的任何聚会组织者都急切地希望从社区中得到他们希望看到的内容的反馈。Maaret 经常在博客上讨论这个问题。这可能不是您目前可以做的事情，但绝对是您需要注意的事情。

今天：

下载并阅读 Mob 编程指南。
如果可以，请尝试进行暴民测试。
Maaret 写了一篇很棒的文章，讲述了她的经历以及如何开始使用 Mob 测试。
Maaret 还在 Ministry of Testing大师班、TestBash Philadelphia和TestBash Australia发表过演讲。
看看Jasmin Smith 关于她的 Mobbing 经历的精彩演讲。

（任务 22）深色图案

暗模式是一种用户界面，旨在诱使人们做他们不打算做的事情，例如订阅或购买某些东西。这些都是经过深思熟虑的技巧，旨在使企业受益，但很少考虑用户。您是否曾在结账时在购物篮中发现一件偷偷摸摸的附加商品，或者点击了伪装成另一种导航的广告？这些是深色图案。

回想一下您的用户体验任务。黑暗模式是一种反模式。一段时间以来，它们一直是新闻网站关注的话题。

您是否曾尝试注册免费试用某些东西，却只要求您提供付款信息？直到读完The Sinister Side of UX之后，我才意识到我已经成为了它的牺牲品。

Emma Keaveny 有一段关于此的精彩视频！另一个有用的链接是Dark Patterns。梅丽莎·伊登 (Melissa Eaden) 也发表了有关探索黑暗图案的博客。

继续任务 5 的主题，我强烈推荐这本书 Evil by Design -- Chris Nodder。还有一个链接到本书的网站，可以让您大致了解书中的内容。我自己还没有读完这本书，但每次拿起它我都会学到一些新东西。

你今天的任务：

观看 Emma 的演讲视频。
阅读链接的内容并开始思考黑暗模式。
您能想出您已经接受为生活常态的任何黑暗模式吗？您可以使用 Melissa 的示例作为指南，但我敢肯定，一旦您开始真正考虑这个问题，您就会有一个很长的清单。
(任务 23) 会议
有许多软件测试会议可供选择。有些人甚至会在会谈后发布视频，这真是太棒了，但老实说，这并不是完整的体验。当你参加会议时，你就开始建立人际网络，这听起来很糟糕，但说真的，这可能是参加会议最好的部分。实际出席的另一个好处是有机会在演讲结束时向演讲者提问，或者事后找到他们进行更详细的讨论。演讲者通常欢迎有机会更详细地讨论他们的演讲，有时甚至可以让他们想到他们将来如何改变他们的演讲。

Eric Jacobson和Rob Lambert都写过关于如何享受和充分利用测试会议的文章。一旦您选择了目标会议，这些将对您很有价值。

我的第一个软件测试会议是 TestBash Brighton 2016。我从Is it just for testers ? Beren Van Daele 觉得这是一次归乡。我们都根据当天的经验采取了不同的角度。Cassandra Leung 将 TestBash 曼彻斯特作为测试人员的第一个 TestBash发表在博客上。Danny Dainton 写过关于在 TestBash Brighton做志愿者的文章。Dan Billing 还写了关于他的TestBash 2014体验，他从作为与会者体验它到演讲。

TestBash 并不是唯一的会议。Erik Brickarp 好心地给我链接了他在Let's Test 2013 的博客，我喜欢里面的那句话“你永远不会孤单”。Helena Jeret-Mäe 还写了关于她参加Let's Test 2014的经历。Chris Kenst 深入了解了 CAST 2015。最后，Keith Klain 写了关于他在敏捷测试日的经历。那里还有更多的会议，这些是少数人的一些第一手经验，可帮助您了解会发生什么。

回到 Danny 的志愿者博客，如果您愿意付出艰辛的努力，许多会议都有某种形式的志愿者选择。这可能会帮助您实现目标，所以请亲自到场看看。

接下来做什么：

查找要参加的测试会议。
与已经或将要参加会议的人在线交流。
搜索以前测试会议的现有在线视频。

（任务 24）探索性测试

探索性测试是我个人的最爱之一。您可以探索您很可能没有用其他测试方法覆盖或覆盖的应用程序区域，但您觉得您可以调查更多。为此，我建议您阅读一些非常有趣的文章。他们中的大多数都是最近的！

James Bach 写下了他对什么是探索性测试的看法。Simon Tomes 撰写了一篇出色的文章，其中他提供了三个易于理解的图表来描述探索性测试，最近还有一篇文章提供了30 个探索性测试技巧。我还想强调这本书Explore It! 我之前提到过。这本书绝对是探索性测试的好书。Maaret Pyhäjärvi 有一篇关于如何用意图探索的有用文章。这可以帮助您在探索过程中保持指导，并在您取得的成果结束时有一个更清晰的画面。

接下来做什么：

阅读链接的文章并开始阅读伊丽莎白的书。
当你读完它们后，选择你想探索的东西，也许是你坐火车上班时手机上的一个应用程序。
用心探索这一天！
你有没有发现什么异常？
你觉得你探索得够多了吗？
下次你会以不同的方式处理它吗？
阅读增强探索性测试工作的 30 个技巧。

（任务 25）移动测试

我会称之为专业化。我把它放在这里是为了让你有资源了解专业化。也许您想专注于移动测试，或者您的工作需要这方面的知识。测试平台部在移动测试部分有一些资源。Ministry of Testing Slack上有一个用于移动测试的频道，如果您愿意，可以在其中寻求指导。

想想你手机上的应用程序。如果您进入他们的“关于”部分，它会说明他们支持的操作系统吗？鉴于您现在对移动测试的了解，这会让您感到惊讶吗？

当您掌握了移动测试后，您可能想尝试30 天的移动测试挑战。由丹尼尔·诺特 (Daniel Knott)设计，如果您打算这样做，他绝对是您想在 Twitter 上关注的人。

接下来做什么：

查看测试部平台的移动测试资源页面。
完成30 天的移动测试挑战。
查看 Daniel Knott关于移动测试的书。
在 Ministry of Testing 平台上尝试移动测试 101和移动测试初学者指南。
调查Katrina Clokie 的移动测试路径。
(Task 26) 安全测试
Dan Billing发布了一个名为 Ticket Magpie 的沙箱来练习安全测试。他还为 Ministry of Testing 平台上的许多安全资源做出了贡献，以帮助您入门。在过去的一年或更长时间里，我们都看到了大黑客：TalkTalk、Ashley Madison、3pay、Tesco。安全测试变得比以往任何时候都更加重要。

随着我们周围的世界发生变化，我们开始（有时是在不知不觉中）发布更多关于我们自己的信息。

此任务只是获得安全测试风格的开始。同样，这可能是那些不会只是一天的任务之一。

你今天的任务是：

查看 Ministry of Testing 平台上的一些安全测试资源，看看您是否愿意进一步探索。
去阅读Troy Hunt的一些作品。
查看OWASP及其拥有的令人难以置信的资源。
查看30 天安全测试挑战。

（任务 27）自动化

自动化是软件测试社区中争论和讨论的一个巨大话题。当您深入研究这个主题时，请准备好听到诸如“自动化修复一切”之类的话。像这样的陈述可能会导致误解和滥用自动化。您可能还会阅读有关“测试与检查”的内容，请不要被使用的语言推迟，我知道一开始我觉得它不知所措。Richard Bradshaw 在 TestBash 上发表了一篇关于测试自动化的精彩演讲，我强烈建议您从那里开始。测试部平台还与 Richard 一起举办了自动化测试 AMA，社区向他提出了问题和播客与他讨论如何开始自动化。也许还有更多与此主题相关的播客是您从 16 中偶然发现的。

自动化的优点之一是它是一种增强应用程序覆盖范围的方法。你只是一个人，在重新检查功能时你可能会错过一些东西，你是人。计算机可以非常擅长做一些人们经常失败的事情，Angie Jones 写了一篇博客，介绍如果直接从测试用例编写脚本，自动化可能会遗漏的事情。

关注自动化是自动化最重要的部分。设置框架并添加其他因素（例如团队目标、技术、时间和团队技能）应该可以帮助您确定适合您的环境的工具。那里有很多工具，如果您不设置框架，它会变得不知所措。

如果您想尝试自动化，我建议您查看Richard Bradshaw或Alan Richardson的课程以帮助您入门。当然，Selenium 并不是唯一的自动化工具，但我亲自参加了这两门课程，强烈推荐它们。Mark Winteringham 还有一个由三部分组成的博客系列和关于构建自动化 API 测试框架的视频课程。你找到其他人了吗？你觉得它们有用吗？为什么不在 The Club 的自动化线程或 Slack 的自动化频道中与其他人分享它们。

您的自动化任务是：

开始上面推荐的自动化课程之一。
查看测试平台部的自动化资源。
探索The Club上的自动化线程。
奖励任务，尝试30 天测试自动化挑战！
(Task 28) 性能测试
测试部平台上有很多关于性能测试的资源，但是，学习性能测试快速入门指南是一个很好的起点。

回想一下您手机上的那个应用程序和任务 1 中正在运行的软件包。据估计，普通用户会对4 秒后未加载的网页失去耐心。现在想想黑色星期五的销售或那些在 2 分钟内售罄的音乐会。您是否曾经在线排队等待其中任何一个？负载和性能测试可以帮助整个团队在产品发布给客户之前估计产品中可能存在的弱点。

在Dojo 的性能测试 101在线课程中，Simon Knight 在性能测试模式课程中对这些术语进行了有用的分解。我将在此处提供简短的上下文摘要，但我建议观看课程课程以获得更详细的解释。我省略了西蒙在视频中介绍的浸泡/耐力、压力、尖峰和容量测试。

性能测试旨在确定应用程序在正常负载条件下的响应能力。性能测试试图回答的问题示例包括完成事务需要多长时间或加载页面需要多长时间。它可以帮助团队了解站点是否可以处理预计的用户数量。在像 Jmeter 这样的工具中进行性能测试将使用户数量保持在正常水平，其中正常将基于系统的要求。

进行负载测试以确定系统在重负载条件下的响应方式。它将测量这种重负载下的响应时间和资源利用率。负载测试还有助于确定系统何时中断以及中断时是否正常。当我们进行负载测试时，我们可能想回答的一个问题是，当系统处于高负载下时，我们实际上能够处理多少事务。运行负载测试时，用户级别保持较高，以了解系统在使用级别下将如何响应。

接下来做什么：

查看PerfBytes播客。
阅读测试平台部上的这篇PerfBytes 文章。
Mark Tomlinson 也出现在 Test Talks 中，他遇到了很多瓶颈。
参加Ministry of Testing 平台上的性能测试 101课程。
调查 JMeter用户手册。
奖励任务，完成30 天的性能测试挑战。