关于QA的一些Open Question

最近有一些机会和业界的同行交流，接下来也还会有这样的机会，于是在想，也许带着问题去交流会更有收获。下面列出了一些想到的一些问题，应该只是一部分，还有很多遇到过但是一下子可能没想到的。先就列在这里吧，也欢迎大家补充。

Automation
说起QA，就离不开automation。关于这个问题，也有很多话题。比如
  你觉得automation rate多少比较合适?  (假设你认同100%的automation不可能也不合理。)
  automation的ROI如何？因为通常做的好的automation要付出很大的人力物力，也要经常很长的一段时间的积累。
  如果automation rate很高，是不是就不需要QA或者只需要很少的QA？
  关于UI automation。这其实是一个很大的topic，虽然业界讨伐声不断，但是现实中很多公司还是在用，而且相关的工具似乎也卖得不错，甚至连招聘QA的简历上也常有相关的要求。


QA需要阅读源代码吗？
关于这个问题有正反两面的观点。正方认为需要，因为很多问题通过黑盒难以发现，或者效率很低，直接读源代码是一个很直接的了解产品的机会，也可以更快的发 现问题。反方的观点认为这样可能会局限QA的思维，只是按照代码的逻辑来测试，而不是从外面，按照用户的使用角度和习惯来测试。当然还有别的很多的理由。
如果你是一个QA，你会去读你们产品的源代码吗？为什么去读或者不读？抑或不想读但读了或者想读而没有读？


QA需要编程的技能吗？
这个问题其实业界也争论了很久。MS的做法是把QA的名字称为Software Develop Engineer in Test，SDET, 所以他们有很多时候是在写代码，自动化或者测试工具。
如果你是QA, 你写代码吗？或者你觉得应该写或者不应该写？


如何衡量QA的performance？
找到的bug应该算是QA测试工作的一个重要的产出？ 那么是否可以通过找到的bug的数量和优先级等特性来衡量一个QA的工作表现呢？
正方可能觉得这样很好，可以激励QA去找到更多的更严重的bug，这样可以帮助产品提高质量，减少将来support的cost。
反方觉得这种做法会误导，而且不一定科学。关于这个问题，How we test software at microsft里面也谈到了。
且不论别人怎么看，你的看法和实际的经验是怎么样的？


关于the ratio of QA vs Dev的问题
这个问题已经成了一个业界经典的问题了。不光是我们这些入行不算太长的，连Alan Page和James Whittaker这些人也在blog里面讨论这样的问题。大家常举的例子是MS是1:1, 而Google是1:7甚至更高，到底哪个更合适？也许有些人觉得这是个伪命题，管别人多少呢，自己觉得多少合适就行了。这样讲也没错，如果这样想的人说 了算就不会有人常去想这个问题。但是现实中，特别是resource比较紧张的时候，老大们很容易自上而下的问一个问题：“为什么我们需要这么多QA？”
你可以想想你会怎么回答？其实这是一个很不错的讨论的主题，讨论出三十个point问题都不大。


关于组织架构的问题
如果只是把QA的任务限定在软件测试，那么QA的组织方式可以有好几种，比如：
a. 每个产品的项目组有自己的专职的QA。 这些QA属于某一个项目组，专注在某一个产品（线）的测试工作上。
b. 公司或者部门有一个独立的QA部门，QA同时给很多产品提供测试，每个QA没有专属的项目组。当然也可以一段时间focus在一个项目上面。
c. 混合模式，基于a和b。有些测试工作是team内部的QA来完成的，有些测试，例如集成测试、性能测试等交给b中所说的独立的QA部门完成。
d. 把测试工作外包给别的公司。当然，d也可以和a或者b混合，就是把部分工作外包，比如本地语言版本的测试等。
到底哪一种好？你所在的公司或者项目采用的是哪一种方式？
这个问题就像是一个灌水的坑，大家有空可以自己试着挖一挖。不过探讨一个各种架构的特点应该还是很有意义的。


关于测试外包的问题
现在又很多的软件外包公司提供测试的服务，无论是直接把产品全部交给他们去测，或者他们派人过来参与测试。
关于这个问题你是怎么看待的？可能也取决于你的role。
你没有采用测试外包，原因或者你觉得的障碍是什么？
你们采用了测试外包，原始是什么？觉得好的地方和不好的地方是什么，会继续用下去吗？

。。。。。。

 

也许你还有更多，欢迎补充...