在开始自动化前，你需要改变的几个观念

改变团队文化而不是流程

因为这个话题在我参与的许多项目中一次又一次地出现，所以决定写这篇文章。有人抱怨，“自动化是QA流程出问题的根本原因”，这是一个很大的误解。但是，我认为，自动化测试离不开团队文化。为了流程顺利进行，积极的团队文化是自动化发展和繁荣的基础。

本文详细介绍了一些可以根据团队的成熟度和自治程度进行调整的举措。

常听到这样的抱怨：

“只要有自动化我们就可以把事情做得更好，” “我们需要自动化的解决方案。” “只要多创建一些UI测试就可以了”。

必要的QA技能

那么，让我们先反思下面这几个问题:

你的团队会在需要的时候相互帮助吗?

质量是大家的共同责任吗?

测试是流程中的一部分吗?

如果测试人员生病了，团队知道要怎么做吗?

如果这些问题中存在否定回答，那么团队文化可能是有问题的。

在此基础上，我将列出一些要点，来说明让每个团队成员参与测试的重要性。

团队文化

如果你以前曾碰到过这个话题，那么你可能还听说过相关“流程的失效”是由公司的文化所引起的。意识到这个问题很好，那为什么没有主动改变它呢？或者为什么以前的尝试都失败了？

因为维持现状比尝试改变更轻松。

就本文开头提到的那些问题而言，我列了一些可能导致问题的常见原因：

QA人员就是质量的负责人

团队不理解项目上线前QA在做什么（已经9102年了）

团队将QA视为问题制造者，而不是提供解决方案的人

没有理解质量要求也是开发工作中的一部分。

改变思维方式

最大的挑战可能是改变原有的思维方式。你必须学习如何处理不同的情况，以及如何与不同背景和特征的人打交道。

下面我列举了一些小的举措，你可以在此基础上尝试。

1. 团队对于质量的理解

有时，你的团队成员或经理不是很了解 QA 工作中包含的内容，以及你在每次上线前作出的实际贡献。作为 QA ，我们有责任明确列出和定义我们的工作。为了解决这个问题，你可以组织一些小型会议来讨论你一直在做什么以及怎样可以帮助团队满足质量要求 。

2. 尽早测试

是否总在项目最后才测试？测试仅仅是流程中的一个节点，这种情况非常普遍：按照传统的思维方式，测试仅在项目快结束的时候进行。事实是，你应该尽早进行测试，而不是到最后才去做。这样，你测试的目标也会发生变化：从最开始就避免bug，而不是最后不停的去修。

3. 质量不是一个人的事

共同责任应该是你的目标，因为你不应该是唯一关心质量的人。这可能是一个挑战，因为它可能需要你和团队的思考和思维方式发生初步转变。大家达成共识了，共同责任才能开始发挥作用。以下是基于我以前尝试和经验的一些建议：

共同责任并不意味着你会失业。这意味着你将有更多的时间来探索重要的事情，而不是一直执行重复无聊的测试工作。

你的团队必须将你视为流程的关键部分，换句话说，你应该成为他们请教测试知识的人。

与团队组织探索性会议，来帮助他们建立相同的责任感，并更多地了解产品的工作原理和使用体验。

通常情况下，我们会倾向于将测试作为产品工作的一小部分，但如果想把质量放在首位，没有全局观是不行的。

4. 不再找bug，而是在最开始就避免它们

这听起来可能有点奇怪……但你会习惯它的；）

我们已经不再是那个唯一关注质量的人，那么为什么我们还要找bug而不是避免bug？

但是在敏捷计划会议期间，务必确保每个人的理解是一致的，这一点很重要。也许这听起来不像我们 QA的职责，根据我的经验，在开发过程中，如果对某个功能的最终定义有误解，就会需要反复的讨论。

确认一下这些问题可能会有所帮助：

所有人的观点一致吗？

大家对功能的定义是否有疑问？

我们对验收标准感到满意吗？

由测试工程师提这些问题听起来有些奇怪，对吧？但就像我前面说的，共同责任不仅关系到质量，它关系到整个项目！

应该从哪里开始呢？

从自己开始。你需要先习惯这种工作方式，然后再将其传播给团队的其他成员。以这种方式进行操作的好处是，你能提高自己的熟练程度，在将其推广给其他团队成员时，被认同的可能性更大。

积极主动并在项目早期进行测试。检查其它团队成员在做的功能点并做一些早期验证。

不要等到开发人员将流程发到“等待最后测试 ”节点下。

做多方面的探索性测试，而不是单调的手动脚本测试。

没有万能的方法，你需要根据自己的环境做进行一些小的调整。很快你就会明白，分步执行相比所有事情放在一起做是非常有效率的。为了做好这件事，你需要同伴对你的理解和信任，而不仅仅是帮你做一些执行。

自动化

现在你可以自动化测试你的项目了。在这里，你可能想知道为什么自动化不是本文的第一主题。让我解释一下原因：

自动化只是很小的一部分。如果你没有良好的团队文化，甚至没有人支持你，那么很难完成工作。

你应该仔细选择自动化框架，并调查了解什么样的适合你和你的团队。

你需要考虑哪些？

框架是否能得到持续维护和更新

是否适合你的需求

如果你和后台一起工作，那么创建一个孤立的测试项目没有任何意义，只会增加你和后台工程师之间的隔阂。

考虑用与团队编程语言相同的语言来编写测试用例，可以消除语言障碍并降低维护成本。

在移动设备上，使用黑盒测试框架（例如Appium，Robot）甚至白盒测试框架（例如Espresso，EarlGrey，XCTest）都可以有不同的选择。但要注意拆分测试，否则过多的测试会使UI层超载。

如果你考虑使用行为驱动（BDD）框架编写规范，最好先与你的团队一起做些验证。这样对项目是非常有利的，但前提是整个团队意见一致，并且会合作把这件事做好。

你需要会写有用的单元测试，并在必要时帮助团队进行开发。牢记质量测试覆盖范围，与你的团队一起了解并探索变异测试；然后你们可能会惊讶的发现有如此多的“不会有问题”。

有了以上的考虑，那么在自动工具选取上也应该选取能够满足上述要求的工具。也就是说，能够支持行为驱动框架，方便团队之间的交流，能够很好的维护自动化测试用例，最好能用自然语言描述，能结合开源框架，支持各类应用自动化，能够跨平台，在Windows、Mac、Linux上运行......

如果你在为找这样的工具犯愁，我不妨推荐一款我们也在用的工具，CukeTest，这款自动化测试的开发工具，结合了Cucumber框架和JavaScript语言，提供了编辑自动化测试的功能。例如自动生成框架代码，代码与自然语言之间定位的跳转等。具体功能自己去了解吧，说多了变成广告了......

持续集成（CI）

这里我说的一些可能是基础知识。不要误会我的意思，但如果自动化没有以一个好的策略在CI上运行，就没有任何价值。它应该快速运行，并在每个集成阶段提供反馈。尝试多个测试同时执行，可以考虑将一个测试分成一些较小的测试，以便更好地控制每个测试点的执行。

测试报告

你还应该找一种可以使你的测试工作可视化的方法。正确的方向是选一个适合自己的自动化框架。几乎所有自动化工具都有生成报告的功能。这种模式便于使用dashboard在大屏幕上解析和呈现。

CukeTest也有测试报告和分析功能，多种开箱即用的可视化报告和视频录制，并可自行定制。

CukeTest 测试报告总结

参与的团队成员比自动化流程更重要。

从小处着手，获得支持，然后再做大。

并不是上了自动化就能有好的质量。

与其选择让你干活的工具，不如选择为你干活的工具。

QA一直是人们没有完全理解的角色，确保所有人都知道你的重要性是你的职责。

希望这篇文章可以帮助你改善团队，或者至少可以促进一点变化。