本书讲述了如何构建测试，以便不仅捕获错误，而且避免它们的发生。 我们真的很喜欢它，因此，我们作为老朋友决定支持Habré上的摘要传统，并列出最有趣的论文。
测试组织方法的方式已发生变化：
瀑布一切始于使用Waterfall方法进行测试。 此阶段的特征是测试仅是一个团队成员（猜测谁）的活动。 除测试人员外，没有人对测试策略一无所知，并且无权访问测试用例和检查清单。 任务像乒乓球中的球一样按命令飞行。 这个时期的特点是释放时间长。
敏捷的在有关敏捷方法论的工作中，测试已成为整个团队的责任。 这意味着不仅测试人员，开发人员也可以发现并解决问题。 此阶段的特点是频繁发布和快速反馈。
开发者现在，测试受支持，分析，基础结构和监视的影响。 测试的边界和性质正在改变。 现在，可以通过各种渠道向团队提供信息：监视，来自支持服务的请求，分析报告。 同时，测试应该可靠，但不应干扰快速发布。
在DevOps和CI时代进行测试
作者声称DevOps比CI大得多。 CI专注于加快代码编写速度（例如版本控制系统，单元测试，频繁提交）和DevOps的技术实践-组织变更（尤其是支持软件交付人员类型之间更紧密协作的支持）：分析师，支持，开发团队）。
没有敏捷，就不会有DevOps文化。 人们必须灵活思考才能进入DevOps，DevOps的主要目标是可靠性和发布频率。 同时，DevOps的报告中经常遗漏测试主题。
卡特里娜飓风（Katrina）的主要论点是，您需要始终进行测试，并在每个阶段都进行测试-从开始执行任务到最后一次发布落实。
工作量很大。 问题是如何组织所有测试而不发疯。
从哪里开始测试
- 了解现在如何安排项目的测试过程。
- 为整个团队组织一次测试策略回顾会议，并回答我们现在正在测试什么以及为什么进行测试的问题。 事实证明，一个团队的参与者会以不同的方式回答有关该过程的问题，这是错误的。
DevOps不仅仅是灵活的测试。 DevOps的意识形态意味着一个经过完美调试的过程，不仅可以在生产中快速部署新版本或回滚到以前的版本，还可以在开发和操作命令之间进行同样调试的通信。
帮助您测试敏捷性的10条标准：
- 整个团队清楚地知道在处理特定用户故事时需要测试什么。
- 每个人对业务需求都有共同的理解。
- 在讨论用户故事时，您将获得以下问题的答案：“我们将如何测试？”
- 团队中的每个人都知道如何运行自动测试以及在哪里可以看到结果。
- 您预先讨论了将要执行的自动化操作以及在什么级别进行自动化，以免重复不同级别的测试。 （在我们看来，这一项目最为重要）。
- 由于测试是软件的一部分，因此测试脚本将进行版本控制并与源代码一起存储。
- 积压中没有错误，因为您将在发现错误后立即修复它们，而不仅仅是注册它们。
- CI服务器的工作无停机时间。
- 在集会期间，尚不清楚谁是开发人员，谁是测试人员。
- 您的团队可以评估产品的质量。 每个人都了解项目的测试过程如何工作。
您可以使用
链接进行检查-作者在这里说明了为什么突出显示这些点以及为什么它们很重要。
DevOps的协作实践
人们交流的频率越高，就越了解同事在做什么以及如何获得帮助。 因此，卡特里娜飓风为他们提供了更多讨论测试的机会。 有几种方法可以做到这一点：
- 分析人员和支持者检查清单。 进行早期测试可以提高发布质量。
- 成对测试：测试人员和分析师，支持人员和开发人员。
- 开发团队和支持之间的员工轮换。
- Dojo（作为软件开发的一部分）是一个人们可以一起学习和实践其开发技能的环境：大师班，知识共享。
生产测试
以下工具将有助于促进生产中的测试：
- 配置了监视功能，以便您可以轻松找到并确定问题，
- 使用各种通信渠道发出警报：例如，如果服务器崩溃，则向Messenger发送消息，或者当内存用尽时通过电子邮件发送通知，
- Analytics（分析）（例如Google Analytics（分析）），它显示有多少用户使用该功能，
- 记录变得可读。
- 客户的反馈-商店中的评论，Web应用程序中的反馈表。
聚苯乙烯
此摘要未包含很多有趣的内容。 这本书写得很好，我们推荐给正在考虑对DevOps项目进行测试的测试人员。
最后，几个有用的链接：- 这本书可以在这里买。
- 链接到2017年敏捷测试日的卡特里娜飓风表演视频 。
- 链接到Katrina Kloki的博客 。