RD:QA到底幾比幾好? 看看Microsoft的講法
google v. microsoft, and the dev:test ratio debate
http://blogs.msdn.com/james_whittaker/archive/2008/12/09/google-v-microsoft-and-the-dev-test-ratio-debate.aspx
RD和QA的比例到底要多少才好呢? 始終沒有定論, 並且也一直在做調整. 像微軟大部分是1:1, 我們公司也大約是1:1. 前年曾聽我們公司美國部門的人說, 那時候流行是3:1. 那國內呢?可能是無限大比一, 因為很多公司根本沒有QA.
作者提到大部分微軟是1:1, 有些team是 2或3 : 1, 可是Google的狀況剛好相反, 他們是一個tester負責很多developers. (作者還戲稱是bug-writing的developers, 這點上Microsoft和Google倒是有共識)
所以那個比較好呢? 以下是作者的看法
A. 1:1
1. 優點
- It shows the importance we place on the test profession and frees developers to think about development tasks and getting the in-the-small programming right.
- It maximizes the number of people on a project actively thinking about quality.
- It speeds feature development because much of the last minute perfecting of a program can be done by testers.
- And it emphasizes tester independence, minimizing the bias that keeps developers from effectively testing their own code.
2. 缺點
- It’s an excuse for developers to drop all thoughts of quality because that is someone else’s job.
- Devs can just build the mainline functionality and leave the error checking and boring parts to the testers.
B. Many: 1
1. 優點
- When testers are scarce, it forces developers to take a more active role in quality and increases the testability and initial quality of the code they write.
- We can have fewer testers because we our need is less.
2. 缺點
- It stretches testers too thin.
- Developers are creators by nature and you need a certain number of people to take the negative viewpoint or you’re going to miss things.
- Testing is simply too complicated for such a small number of testers.
- Developers approach testing with the wrong, creationist attitude and are doomed to be ineffective.
作者也觀察到一個有趣的現象: 在微軟的QA都想扮演RD的角色, 因為在發現 bug的時候, 通常都有能力把它解掉. 但是作者也說, 這樣的行為對RD來說並沒有好處, 因為他並沒有幫RD從錯誤中學到經驗. 同時也可能造成RD偷懶的主要原因.
在我們公司, 也有不少RD提出這樣的見解, 認為1:1的狀況下, 造成RD被寵壞了. 有些RD常常只要收集不到debug log, 就宣稱他們無法解這個bug. 或許真的是太幸福了.
那什麼是理想的比例呢? 作者認為有些複雜的系統, 自然需要比較多的QA, 或是專門的QA測試專門的項目. 當然也有些地方或是方法, 可以將unit testin, automation 和manual testing混合著進行. 但是最重要的是, 作者認為要注意到的是你的工作中, 有多少比例的內容是在做quality assurance.
這句話在我的解讀是: 像是RD不應該只是寫寫code而已, 也需要有unit testing, code review, design review等工作項目. QA的工作也不是因為你在做testing, 你就都是在做quality assurance, 那test case review, design review, bug report inspection, test result inspection等等, 你有沒有在處理. 所以不在於你扮演什麼角色, 而是在於你有沒有任何工作項目, 是來檢查你工作的內容好不好.
否則你只是bug creator而已, 當然啦不是只有RD會這樣, QA若是沒有這種認知, 同樣也是幫兇.
google v. microsoft, and the dev:test ratio debate
http://blogs.msdn.com/james_whittaker/archive/2008/12/09/google-v-microsoft-and-the-dev-test-ratio-debate.aspx
RD和QA的比例到底要多少才好呢? 始終沒有定論, 並且也一直在做調整. 像微軟大部分是1:1, 我們公司也大約是1:1. 前年曾聽我們公司美國部門的人說, 那時候流行是3:1. 那國內呢?可能是無限大比一, 因為很多公司根本沒有QA.
作者提到大部分微軟是1:1, 有些team是 2或3 : 1, 可是Google的狀況剛好相反, 他們是一個tester負責很多developers. (作者還戲稱是bug-writing的developers, 這點上Microsoft和Google倒是有共識)
所以那個比較好呢? 以下是作者的看法
A. 1:1
1. 優點
- It shows the importance we place on the test profession and frees developers to think about development tasks and getting the in-the-small programming right.
- It maximizes the number of people on a project actively thinking about quality.
- It speeds feature development because much of the last minute perfecting of a program can be done by testers.
- And it emphasizes tester independence, minimizing the bias that keeps developers from effectively testing their own code.
2. 缺點
- It’s an excuse for developers to drop all thoughts of quality because that is someone else’s job.
- Devs can just build the mainline functionality and leave the error checking and boring parts to the testers.
B. Many: 1
1. 優點
- When testers are scarce, it forces developers to take a more active role in quality and increases the testability and initial quality of the code they write.
- We can have fewer testers because we our need is less.
2. 缺點
- It stretches testers too thin.
- Developers are creators by nature and you need a certain number of people to take the negative viewpoint or you’re going to miss things.
- Testing is simply too complicated for such a small number of testers.
- Developers approach testing with the wrong, creationist attitude and are doomed to be ineffective.
作者也觀察到一個有趣的現象: 在微軟的QA都想扮演RD的角色, 因為在發現 bug的時候, 通常都有能力把它解掉. 但是作者也說, 這樣的行為對RD來說並沒有好處, 因為他並沒有幫RD從錯誤中學到經驗. 同時也可能造成RD偷懶的主要原因.
在我們公司, 也有不少RD提出這樣的見解, 認為1:1的狀況下, 造成RD被寵壞了. 有些RD常常只要收集不到debug log, 就宣稱他們無法解這個bug. 或許真的是太幸福了.
那什麼是理想的比例呢? 作者認為有些複雜的系統, 自然需要比較多的QA, 或是專門的QA測試專門的項目. 當然也有些地方或是方法, 可以將unit testin, automation 和manual testing混合著進行. 但是最重要的是, 作者認為要注意到的是你的工作中, 有多少比例的內容是在做quality assurance.
這句話在我的解讀是: 像是RD不應該只是寫寫code而已, 也需要有unit testing, code review, design review等工作項目. QA的工作也不是因為你在做testing, 你就都是在做quality assurance, 那test case review, design review, bug report inspection, test result inspection等等, 你有沒有在處理. 所以不在於你扮演什麼角色, 而是在於你有沒有任何工作項目, 是來檢查你工作的內容好不好.
否則你只是bug creator而已, 當然啦不是只有RD會這樣, QA若是沒有這種認知, 同樣也是幫兇.
全站熱搜
留言列表
