《敏捷软件测试》的读书笔记（六）

第四部分 总结

1. 团队整体参与

2. 使用敏捷的测试思维

3. 自动化回归测试

4. 提供并获取反馈

5. 构建核心实践的基础 [持续集成、测试环境、管理技术债务、增量工作、编码和测试是同一个过程的重要组成部分、实践之间的协作]

6. 与客户合作

7. 保持大局观

 

------------------------自我反思--------------------------------------------------------

1. 敏捷测试中，文档到底重不重要？

目前的项目中，是非常缺失文档的。敏捷测试注重投资回报率，认为没有意义的事情就可以不进行。但是我还是任务文档是很有意义的，一个是对当前人员是一个梳理过程，在写文档中加入更多的思考，保证项目的正确性，另一个是促进彼此间沟通的正确性和有依据性，再则写文档对于后期项目的维护都是很有帮助的，减少后面人员的熟悉成本。

不能理解当前的项目，为什么没有文档，连一点点文档都没有，怀疑是前面的人没有在公共区域记录文档，交接工作又没有做好。

2. 和产品经理的关系到底是怎样的？我们接触不到真实的客户

敏捷测试要求测试要按照用户的角度去保证产品质量，可是现实工作中往往有产品经理去直接去客户交流，我们很难直接与客户交流。那么我们作为的用户也就只有我们自己了。产品经理也往往会误解客户的需求。这些矛盾的存在，是不是应该测试应该参与到项目的整个过程，从需求到项目的最终发布，甚至到线上反馈。如果真的覆盖了全过程，可能测试真的就能够保证产品的有效性和质量了。但真实情况呢？项目团队忽略测试，测试只作为开发团队不愿意做的事情而存在，测试工作因为项目中的不平等对待更是没有做好，工作没有做好更是得不到团队的认可，如此恶性循环。测试是个尴尬的职位，从上到下的不重视，大环境的认为测试是退而求其次的工作。

3. 我认识的敏捷测试？

敏捷测试，是面向价值的，以高效的产出价值为导向的。敏捷测试，换言之，是在敏捷开发的团队，测试应该如何的工作。

方法：测试提前，使用TDD去保证代码的质量和减少自己无用的工作，把时间应用在有价值的事情上；积极的沟通，融于团队中去，鼓励大家都支持敏捷测试的工作；持续的改进项目中的问题，记录生产中的问题；使用自动化去减少重复工作，提高工作效率；

说个我一直理解错误的观点，在和x同学讨论后，我同意了他的观点。以前我认为：敏捷测试是一种类似于现在公司的混乱模式，不断的迭代产品，不断的上线。现在来看，其实不是这样子的，敏捷不等于“混乱”，更不是“需求不明确”。敏捷只是缩短产品周期，采用迭代的方式快速的开发产品，提前获得用户的反馈来提高产品质量。而目前公司的“混乱”开发，是因为需求不明确，没有考虑清楚，一味的追求产品的上线速度。另外，我认为敏捷开发不代表最终的产品速度一定有大步的提升，但其产品质量一定是更满足用户要求的，和与时代相符合的。再说说现在公司的混乱模式，速度一定是快的，但是质量就不敢恭维了，最终承受的只能是用户了。

4. 质量由谁来认证？

其实不管是不是敏捷的测试，质量最终都应该由用户来认证，因为用户是最终产品的承受者，产品和用户是最息息相关的。好质量的产品，用户收益，反之，用户是坏质量的消耗者。不管产品最终实现的是个什么样子，用户觉得好，就是好，觉得不好，也就是烂产品。

也存在“主导用户，改变用户习惯一说”，如果从长期来看，这件事情是对用户有益，一时的让用户难受其实也是可以接受的。

5. 如何和开发搞好关系？

书里面讲的糖果的故事还是很有意思的，一些糖果就能换来关系的融洽，地位的平等。另外还有一个观点，测试人员要做一个合作人员，而不是强制的实施者；所以，可以看出作者还是更认可团队中的人员都是helper的角色，都是在帮助团队和产品的成长。

个人觉得可以从以下几点来促进和开发的关系：1). 人与人相处一定是“情”的融洽，平时的多交流和分享可以让其它人以“朋友”和合作伙伴去认识到你；2). 多给与他们帮助，哪怕是简单的搭建一个环境，产出你能够产出的价值；3). 承诺的事情一定要做到，小事情也要尽可能的做到最好，认可你的工作就是认可你。

6. 测试真的能够成为TDD的驱动者吗？

我觉得显然是不能的，或者如果要做到这个肯定是有条件的。

不能的原因：1). 最直接的，需求的不断变化，导致testcase的太早完成可能是无用功；2). 地位的不平等，测试人员不可能能够作为一个驱动者存在；3). 测试人员的能力和水平有限，不能让人信服；

能够作为驱动者的前提：测试人员的能力，相当于一个架构师的水平，产品是能够在最初就完全确定的；

7. 什么时候应该进行自动化？

进行自动化前一定要多思考。