敏捷软件测试常见的七个误区(2)

　　至于关于自动化测试维护成本的顾虑，敏捷项目也确实存在变化比较多的特点，但通常变的都是比较接近用户的部分，所以应该尽量减少用户级别的依赖界面的自动化测试，而多增加一些不容易变化的底层的单元测试接口测试等。

　　推荐敏捷测试以自动化测试为主，手动测试为辅。

　　敏捷QA = 敏捷Tester

　　在很多刚接触敏捷实践的团队中，大家对敏捷QA的认识还停留在Tester的阶段，认为只要用户故事开发完成之后，QA去专职地做测试，发现缺陷就够了。

　　这是一个很大的误解，首先QA(Quality Assurance/Analyst)，不是单纯意义的测试人员，通过这个角色的名称我们可以看的出来敏捷QA强调的是质量保障和分析，而不单纯是测试产品。

　　在实际的项目中，敏捷QA通常会从需求分析阶段就开始参与整个软件开发过程，通过在不同阶段和团队中的不同角色合作，帮助整个团队对质量达成共识，并通过在不同阶段的确认和验证做到缺陷预防，而不是等到软件开发完成后再去发现缺陷，所以对于敏捷QA来说，其目标是软件开发完成后能够发现的缺陷越少越好，而对于Tester来说，发现越多的缺陷证明工作做得越优秀。

　　非功能性测试不重要

　　非功能性测试指的是针对非功能性需求(软件本身满足用户需求所必需的功能性需求以外的一些特性，比如安全，性能，可用性，兼容性等)的测试，通常包括安全测试，性能测试，可用性测试，兼容性测试等。

　　在敏捷软件项目中，需求被切割成了很小的单元，在切割的过程中，非功能性需求是最容易被人忽略的一部分，而这导致的问题就是非功能性测试经常被团队忽略，久而久之，就会形成这样一个误解，认为非功能性测试是不重要的。

　　这个观点非常不对，首先非功能性测试的重要性并不会因为软件开发模式的不同而有所不同，尤其安全测试和性能测试的重要性正越来越多地被重视起来，因为很多产品必须考虑到用户敏感信息的安全以及性能导致的用户满意度，在敏捷项目中由于软件会尽早发布，如果这些非功能性需求出现问题，就会更早地造成影响，很可能在软件刚步入市场就损失掉大多数的用户。

　　所以非功能性的测试和功能性测试同等重要，在实际的项目中，比较好的做法是将这些非功能性需求也加入到用户故事的验收条件中，在整个敏捷开发流程中对这些非功能性需求进行验证。

　　质量是QA的事儿

　　受传统观念的影响，很多人还是会认为质量是QA的事儿，如果产品发布后质量不好是QA的问题，其他角色和质量没有太大的关系。

　　首先这种认识太高估了QA对质量的作用，软件的质量是在软件开发过程中逐步形成的， 从需求分析阶段是否真正的了解到了客户想要的功能，到开发阶段是否增加了足够多的自动化测试保障，是否写了足够健壮的产品代码，到最后测试阶段是否测试了功能引入后整个系统的可用性，不同用户路径是否能正常工作等等，这些都是软件质量的组成部分。

　　可以看得出来，在整个过程中，软件的质量离不开敏捷团队各种角色的付出，其中有业务分析人员对需求的准确把握，有开发人员对产品代码的高标准实现，对自动化测试覆盖率的保障，还有QA在整个过程中对质量相关活动的实施和保障，包括需求分析阶段从QA的视角对业务的补充，开发阶段对自动化测试的审查，以及探索性测试可用性测试等对产品质量的进一步保障。

　　所以在敏捷测试中更多时候我们会淡化角色的概念，强调团队人人都为质量负责，这样更有助于团队的每一位成员都把质量作为非常重要的一部分，而不是依赖于某个人或者某个角色。

　　开发可以写测试，不再需要QA了

　　因为敏捷团队强调人人都为质量负责，开发人员会采用TDD等方式写大量的自动化测试，那么是不是就不需要QA了?

原文转自：http://insights.thoughtworkers.org/agile-testing-misunderstanding/?utm_source=tuicool&utm_medium=referral